feat: add 15 commands from fuji — cart, index, issue, pass, receive, recall, remember, search, status, summary, plan, work, why, insight, ask

ask.md

@@ -0,0 +1 @@
+Ask user interactive questions you need answered to continue

cart.md

@@ -0,0 +1,29 @@
+---
+description: List carts, show the active one, or switch carts in-process
+---
+
+The user invoked `/cart` with argument: `$ARGUMENTS`
+
+Handle it as follows, calling tools directly and reporting back tersely:
+
+- **Empty / `list` / `ls`** → call `cart_list` and `cart_info`. Render a compact
+  table with columns: `slug`, `name`, `voice` (or `-`), `version`, `★` (mark the current one).
+  Append a one-line totals summary.
+
+- **`current` / `active` / `?`** → call `cart_info` and report just `slug` + `name`
+  (and `voice` if set). One line.
+
+- **`main` / `eems` / `base`** → call `cart_load` with no `slug` argument. Confirm
+  the swap by echoing the returned `slug`, `name`, and `path`. One line.
+
+- **Anything else** → treat as a cart slug. Call `cart_load` with `tag="$ARGUMENTS"`.
+  On success, echo the new active `slug` + `name` + `path` (one line). On error (typo, cart
+  not found), surface the error string verbatim and suggest `/cart list`.
+
+Rules:
+- Don't narrate ("I'll now..."). Just call tools and report.
+- No more than 6 lines of output total (table can exceed if many carts).
+- Don't call any other tools — cart ops only.
+- Remember: this is an **in-process** swap. opencode chat history is shared across carts;
+  only EEMS data is isolated. Don't restate this every time — only mention it if the user
+  switches into a different cart for the first time in this session.

index.md

@@ -0,0 +1,25 @@
+---
+description: Bulk-index code or docs into the active EEMS
+---
+
+The user invoked `/index` with arguments: `$ARGUMENTS`
+
+Expected forms:
+- `/index status [project]` → call `index_status` (with optional project
+  filter). Paste the returned string verbatim.
+- `/index clear <code|docs|all> [project]` → call `index_clear` with the given
+  kind + optional project. Report one line: `cleared: code=<N>, docs=<N>`.
+- `/index code <root_path> [project] [extensions]` → call `index_code`. If
+  `project` is omitted, derive it from the basename of `root_path`. If `extensions` is
+  omitted, leave it unset (sane defaults kick in). Report two lines:
+  ```
+  indexed <files_indexed>/<files_seen> files (skipped <files_skipped>)
+  chunks: <chunks_inserted> inserted, <chunks_embedded> embedded, <embed_failures> embed failures
+  ```
+- `/index docs <root_path> [project]` → call `index_docs`. Project derivation
+  same as above. Same two-line report shape.
+
+Rules:
+- If you derived `project` from the path, echo it as `(project=<name>)` on its own line.
+- No narration. No "I will...".
+- If `$ARGUMENTS` is empty or starts with `help`, list the four forms above and stop.

insight.md

@@ -0,0 +1,14 @@
+---
+description: Capture durable knowledge — architecture decisions, debugging patterns, procedures — to the docs repo with EEMS indexing.
+---
+
+The user invoked `/insight` with argument: `$ARGUMENTS`
+
+If `$ARGUMENTS` is empty, ask the user what insight to capture — category and topic.
+
+Otherwise, parse `$ARGUMENTS` as free text describing the insight. Derive:
+- category: infer from content (e.g. "architecture", "debugging", "procedures", "reference")
+- slug: kebab-case from the topic
+- content: synthesize from the current session context and the user's description
+
+Store the insight to EEMS with subject `insight.<category>.<slug>` and the markdown content. Report the result.

issue.md

@@ -0,0 +1,59 @@
+---
+description: Interactive issue creation for the current project board. Gathers context, checks code, builds wireframes or code examples, then files the issue.
+---
+
+The user invoked `/issue` with argument: `$ARGUMENTS`
+
+You are collecting issues for a project board related to the repo and work in the current session. Follow this workflow:
+
+## 1. Gather the idea
+
+If `$ARGUMENTS` is empty, ask the user what they want to file — use the Question tool with a text input.
+
+Otherwise, use `$ARGUMENTS` as the starting point.
+
+## 2. Clarify with interactive questions
+
+Ask the user clarifying questions using the Question tool:
+- Which repo does this belong to?
+- What type? (Bug / Feature / Task)
+- Priority? (P0 critical / P1 high / P2 normal)
+- Size estimate? (XS / S / M / L / XL)
+- Which board? (Madcat / Campus OS) — default to whichever board matches the current project context.
+
+Skip questions where the answer is obvious from context or user input.
+
+## 3. Check the code
+
+Search the relevant codebase to understand the current state:
+- Find the files, controllers, views, services, or components related to the issue.
+- Note file paths and line numbers for reference in the issue body.
+- Understand what exists vs what needs to change.
+
+## 4. Follow-up questions
+
+If the code review reveals ambiguity or design choices, ask the user using the Question tool before proceeding.
+
+## 5. Build visual or code context
+
+### Frontend work
+- Use the Browse tool to navigate to the relevant page/view.
+- Take a screenshot of the current state.
+- If useful, create a simple wireframe sketch (HTML page rendered in browser) showing the proposed change, screenshot it.
+- Upload screenshots to CDN and embed the markdown URL in the issue body.
+
+### Backend work
+- Write a concise code example (pseudocode or real) showing the proposed change — keep it short, 5-15 lines max.
+- Include in the issue body as a fenced code block.
+
+## 6. Compose and file the issue
+
+Use appropriate issue templates and fill them in with the gathered context.
+
+Follow the title convention: plain descriptive language, NO prefixes like `[BUG]`, `P1`, `M1`.
+
+Write the full issue body to a temp file and use `gh issue create --body-file <path>` via Bash to preserve markdown formatting.
+
+## 7. Confirm
+
+Present the created issue URL and a one-line summary to the user.

pass.md

@@ -0,0 +1,20 @@
+Save current session state as an EEMS handover for the next session to pick up. Execute in order:
+
+1. INVENTORY: List what was worked on this session — features built, configs changed, files modified, decisions made, ideas captured. Be exhaustive.
+
+2. ARTIFACTS: List every file created or modified this session with full paths. Include configs, scripts, plugins, docs, plists — anything touched.
+
+3. OPEN ITEMS: List unfinished work, next steps, blocked items, and pending decisions. Be specific — "write science agent prompt" not "finish agent work".
+
+4. STORE: Write a single comprehensive memory to EEMS with subject `handover.session.YYYY-MM-DD` containing:
+   - Numbered sections matching the session's work areas
+   - Every artifact path
+   - Every open item as a clear action
+   - Session metadata (host, user, session ID if available)
+   - Cross-references to other EEMS entries created this session (by ID)
+
+5. VERIFY: Read back the stored handover memory. Confirm it contains enough context for a fresh session with no prior context to resume work.
+
+6. SIGNAL: Tell Pilot the handover is stored and which EEMS ID to reference. Remind them to run `/receive` in the next session.
+
+Optimize for agentic retrieval — the consumer is another AI session, not a human. Use structured formats, explicit paths, concrete next-step verbs. No prose padding.

plan.md

@@ -0,0 +1,14 @@
+---
+description: Create or revise a .madcat/PLAN.md work plan with cadence, chunks, and success criteria.
+---
+
+The user invoked `/plan` with argument: `$ARGUMENTS`
+
+If `$ARGUMENTS` is empty, ask the user what they want to work on — use the Question tool with a text input.
+
+Otherwise, use `$ARGUMENTS` as the goal. Create a PLAN.md with:
+- goal: the provided argument text
+- cadence: ask via Question tool (options: auto-on-green, supervisor, manual) if not obvious from context
+- chunks: break the goal into ordered work chunks with success criteria for each
+
+After the plan is created, read `.madcat/PLAN.md` and present it to the user for approval before any execution starts.

recall.md

@@ -0,0 +1,8 @@
+---
+description: Semantic + keyword recall from EEMS (hybrid RRF)
+---
+
+Call `memory_recall` with `query="$ARGUMENTS"` and `limit=5`.
+Paste the returned string verbatim — do not reformat, do not add narration, do not summarize.
+
+If `$ARGUMENTS` is empty, ask once for a query and stop.

receive.md

@@ -0,0 +1,25 @@
+Resume from the most recent session handover. Execute in order:
+
+1. SEARCH: Run memory_recall for subject `handover.session` to find all handover entries. Sort by date (newest first from created_at). Also run memory_recall with query "session handover open items next steps" to catch any handovers stored with variant subject names.
+
+2. FOUND PATH — if a handover exists:
+   a. Fetch the full handover memory via memory_get (no truncation).
+   b. Present a summary to Pilot:
+      - What was worked on last session (numbered list, one line each)
+      - Key artifacts modified (file paths)
+      - Open items / next steps (numbered, actionable)
+      - How old the handover is (date + days ago)
+   c. Ask Pilot via Question tool:
+      - "Accept this handover?" with options: "Accept all", "Accept and review open items", "Show full handover", "Skip — start fresh"
+   d. If accepted: load the handover context, state which open items you're ready to work on, ask Pilot which to tackle first.
+   e. If "show full": display the complete handover memory content, then re-ask acceptance.
+   f. If skipped: proceed as a normal session with no inherited context.
+
+3. NOT FOUND PATH — if no handover exists:
+   a. State: "No session handover found in EEMS."
+   b. Ask Pilot via Question tool:
+      - "How would you like to start?" with options: "Search EEMS for recent work", "Start fresh — tell me what to do", "Run /summary to audit EEMS first"
+   c. If "search EEMS": run memory_recall for recent entries (last 24h via created_at), summarize what's in memory, ask what to continue.
+   d. Otherwise: proceed per selection.
+
+4. BOOT: Regardless of path, complete standard identity boot (memory_recall for core.* subjects) before starting work. The handover provides task context, not identity context.

remember.md

@@ -0,0 +1,18 @@
+---
+description: Store a memory in EEMS (with sane defaults)
+---
+
+The user invoked `/remember` with argument: `$ARGUMENTS`
+
+Parse the argument:
+- If it contains a `:` separator, take everything before the first `:` as `subject` (trim
+  whitespace, lowercase, replace spaces with `.`) and everything after as `content`.
+- If no `:` is present, use `note.<unix-seconds>` as the synthetic subject and treat the
+  entire argument as content.
+- If `$ARGUMENTS` is empty, stop and ask the user to pass `subject: content`.
+
+Then call `memory_store` with:
+- `subject` = the parsed subject
+- `content` = the parsed content (trimmed)
+
+Report the result as one line: `stored #<id> as <subject>` and nothing else.

search.md

@@ -0,0 +1,12 @@
+---
+description: Hybrid search over indexed code or doc chunks
+---
+
+The user invoked `/search` with arguments: `$ARGUMENTS`
+
+The first whitespace-delimited token selects the kind:
+- `code <query...>` → call `index_search` with `query=<rest>`.
+- `docs <query...>` → call `index_search` with `query=<rest>`.
+- Anything else (or empty) → default to `code` and use the entire `$ARGUMENTS` as the query.
+
+Paste the returned string verbatim — do not reformat, do not add narration.

status.md

@@ -0,0 +1,19 @@
+---
+description: Show status of coordinator-spawned tasks from EEMS.
+---
+
+The user invoked `/status` with argument: `$ARGUMENTS`
+
+Behavior depends on `$ARGUMENTS`:
+
+- **Empty** → list all recent task status rows. Call `memory_recall` with `query="task. status state"` and `limit=15`. Render a compact table with columns: `session` (last 8 chars of the id), `state`, `coordinator`, `language` (or `-`), `last_update` (HH:MM only). One row per matched memory. Append a one-line total.
+
+- **`ses_*` pattern** (starts with `ses_`) → that's a specific session id. Call `memory_recall` with `query="task.<full-id>.status"` and `limit=1`. Paste the returned content verbatim.
+
+- **Any other token** → treat as a state filter. Call `memory_recall` with `query="task. state: <token>"` and `limit=15`. Render the same compact table as the empty case.
+
+If no matches: report `no tasks found` (or `no tasks in state '<token>'` for the filter case) on one line and stop.
+
+Rules:
+- No narration ("I'll now..."). Just call the tool and render.
+- Don't summarize the row content for the specific-id case — verbatim paste.

summary.md

@@ -0,0 +1,9 @@
+Audit the current session's research flow. Execute in order:
+
+1. CONTEXT CHECK: memory_recall for subjects matching the current session topics. List what EEMS knows.
+2. AGGREGATE: Identify duplicate or overlapping memories on the same topic. If multiples exist, consolidate into one authoritative entry — keep the best, link or supersede the rest with memory_link(relation="supersedes").
+3. CORRECT: If any stored memory contradicts findings from this session, update it. Use memory_link(relation="contradicts") to mark the old one, store the corrected version.
+4. PRUNE: Memories that exist only because of an abandoned research direction (pivot happened, conclusion changed) — delete them with memory_forget. State what you're deleting and why.
+5. REPORT: Output a summary table — kept, merged, corrected, deleted. One line each.
+
+Be aggressive. Research flows generate speculative memories that don't survive the final conclusion. Kill them.

why.md

@@ -0,0 +1,9 @@
+---
+description: Show the audit log for a specific memory (why does it look like this?)
+---
+
+The user invoked `/why` with argument: `$ARGUMENTS`
+
+Treat `$ARGUMENTS` as a memory ID. If empty, ask once for an id and stop.
+
+Call `memory_get` with the ID and paste the returned content verbatim — do not reformat, do not add narration.

work.md

@@ -0,0 +1,7 @@
+---
+description: Start or resume work from a .madcat/PLAN.md. Shows plan status, cadence, and next chunk.
+---
+
+The user invoked `/work`.
+
+Read `.madcat/PLAN.md` and present the status to the user in a concise summary. If status is "in_progress", state the next chunk and cadence. If "all_done", congratulate. If no PLAN.md found, suggest `/plan`.