@rayburst/cc 1.0.25 → 1.0.26

package/commands/rb/implement.md

@@ -5,8 +5,7 @@ allowed-tools:
   - Glob
   - Grep
   - Bash
-  - EnterPlanMode
-  - ExitPlanMode
+  - Agent
   - mcp__playwright__browser_navigate
   - mcp__playwright__browser_snapshot
   - mcp__playwright__browser_click
@@ -24,7 +23,7 @@ allowed-tools:
 
 # rb:implement — Card Implementation
 
-Implement a Rayburst board card: load the card and its linked features + criteria, detect conflicts with other active features, enter plan mode for approval, execute the implementation, and move the card to `validation` when done. QA validation is a separate step (`/rb:validate-card`).
+Implement a Rayburst board card end-to-end: load the card + linked features, plan with a subagent, execute with a subagent, then move to `validation`. Works like `/gsd:quick` — spawns a planner agent then an executor agent with no interactive plan approval pause.
 
 ## Reference Data
 
@@ -48,7 +47,7 @@ Examples:
 
 ## Workflow
 
-### Step 0b: Resolve MCP Prefix
+### Step 1: Resolve MCP Prefix
 
 Read `.claude/rb-config.md` and parse the `## MCP Role Assignments` table. Find the row where `Role` is `engineer` and read its `MCP Server Name`.
 
@@ -58,25 +57,25 @@ Read `.claude/rb-config.md` and parse the `## MCP Role Assignments` table. Find
   ```
   Example: if the server name is `rayburst-rb-engineer-780086`, then `MCP_PREFIX = mcp__rayburst-rb-engineer-780086__`.
 
-- If `.claude/rb-config.md` does not exist or the role is `unassigned`, set `MCP_PREFIX = ""` and use the curl fallback for all MCP calls (see "MCP Curl Fallback" section below). Read the API key from `.mcp.json` under the first HTTP MCP server entry.
+- If `.claude/rb-config.md` does not exist or the role is `unassigned`, set `MCP_PREFIX = ""` and use the curl fallback for all MCP calls (see "MCP Curl Fallback" section). Read the API key from `.mcp.json` under the first HTTP MCP server entry.
 
 All MCP tool calls below use `<MCP_PREFIX>` as a stand-in for the resolved prefix.
 
 ---
 
-### Step 1: Verify MCP Connection
+### Step 2: Verify MCP Connection
 
 ```
 <MCP_PREFIX>ping()
 ```
 
-**If the MCP tool is not found** (error: "No such tool available"), the MCP server did not load in this session. Fall back to curl JSON-RPC for the entire workflow (see "MCP Curl Fallback" section).
+If ping fails (tool not found), fall back to curl JSON-RPC for the entire workflow. If ping via curl also fails, stop and report the error.
 
-If ping via curl also fails (network error), stop and report the error.
+---
 
-### Step 2: Resolve the Card
+### Step 3: Resolve the Card
 
-**If the input looks like a UUID** (contains hyphens in UUID format):
+**If the input looks like a UUID:**
 
 ```
 <MCP_PREFIX>get_card({ cardId: "<input>" })
@@ -88,207 +87,160 @@ If ping via curl also fails (network error), stop and report the error.
 <MCP_PREFIX>list_cards({ boardId: "23578fa2-49c1-475c-b398-6d7080a676bc" })
 ```
 
-Find the card whose title best matches the input. If multiple close matches exist, pick the closest and note it. Then call:
+Find the closest title match, then call `get_card` on it.
 
-```
-<MCP_PREFIX>get_card({ cardId: "<resolved-id>" })
-```
+Collect: `card.id`, `card.title`, `card.description`, `card.status`, `card.todos[]`.
 
-Collect from the `get_card` response:
-- `card.id`, `card.title`, `card.description`, `card.status`
-- `card.todos[]` — implementation checklist items
-- `card.columnId` / current board context
-
-**If card status is not `ready` or `in-progress`**, warn the user:
+**If card status is not `ready` or `in-progress`**, warn and ask:
 ```
-⚠️ Card "<title>" is currently in status "<status>". Expected status is "ready".
-Proceed anyway? (yes / no)
+⚠️ Card "<title>" is currently "<status>". Expected "ready". Proceed anyway? (yes / no)
 ```
 Stop if the user says no.
 
-### Step 3: Load Linked Features & Criteria
+---
+
+### Step 4: Load Linked Features & Criteria
 
 ```
 <MCP_PREFIX>list_card_features({ cardId: "<cardId>" })
 ```
 
-For each linked feature, call:
-
+For each linked feature:
 ```
 <MCP_PREFIX>get_feature({ featureId: "<featureId>" })
 ```
 
-Build a **test plan** from all acceptance criteria across all linked features. Each criterion becomes a target behavior the implementation must satisfy.
-
-Also fetch prior validation reports for this card:
-
+Also load prior validation reports:
 ```
 <MCP_PREFIX>list_validations({ cardId: "<cardId>" })
 ```
 
-Review the reports to understand which criteria have previously passed or failed. Use this context when building the test plan — criteria that have previously failed should receive extra implementation attention.
-
-If no features are linked, warn the user:
-```
-⚠️ No features are linked to this card. Implementation will proceed without acceptance criteria.
-```
-
-#### Step 3b: Load Prior Validation Context (if card was returned from validation)
-
-If the card's current status is `in-progress` (indicating it may have been returned from validation after a QA failure), fetch prior failure context:
-
+If the card is `in-progress` (possible QA return), also check for prior failures:
 ```
 <MCP_PREFIX>list_comments({ cardId: "<cardId>" })
-<MCP_PREFIX>list_validations({ cardId: "<cardId>" })
-```
-
-Inspect the comments for a recent QA failure comment (look for "QA: Validation Failed" in the content). Inspect the latest validation report for criteria with status `"fail"`.
-
-If a prior failure is detected, display it prominently before proceeding:
-
 ```
-## Prior QA Failure Detected
-
-The card was previously returned from validation with the following failures:
+Look for a "QA: Validation Failed" comment and note any failing criteria — these get extra attention in the plan.
 
-<QA failure comment content>
-
-The implementation plan will specifically address these failing criteria.
-```
+If no features are linked, warn the user but continue.
 
-Then in Step 6 (Enter Plan Mode), prepend a **"Fixing QA Failures"** section to the plan that explicitly lists the failing criteria and what needs to change, above the general implementation approach.
-
-If no prior failure comment or validation report is found, proceed normally.
-
-### Step 4: Move Card to `in-progress`
+---
 
-Before entering plan mode, move the card so the board reflects active work:
+### Step 5: Move Card to `in-progress`
 
 ```
 <MCP_PREFIX>move_card({ cardId: "<cardId>", status: "in-progress" })
 ```
 
-### Step 5: Conflict Detection
-
-Before planning, detect criteria in *other* active features that this implementation might break.
-
-**Detection process:**
+---
 
-1. Read the card title, description, and linked feature titles to understand the scope of change (which files, components, routes, API endpoints will be touched)
-2. Use `Glob` and `Grep` to identify which source files will need to change
-3. Load the full feature atlas:
-   ```
-   <MCP_PREFIX>list_features({ limit: 100 })
-   ```
-4. For each *other* active feature (status `active`, not linked to this card), check if its criteria describe behavior in the same files/components/routes the implementation will touch
-5. Assess risk level: HIGH if the same component/route is directly modified, MEDIUM if a shared utility is changed, LOW if only indirect overlap
+### Step 6: Spawn Planner Agent
 
-**If conflicts are found**, STOP and prompt the user before proceeding:
+Spawn a `Plan` subagent to design the implementation. Pass it all the card context you've collected (title, description, todos, criteria, prior failures if any). The planner writes the plan as output — it does NOT write files.
 
 ```
-⚠️ Conflict detected before planning.
+Agent(
+  subagent_type="Plan",
+  prompt="
+You are planning the implementation of a Rayburst board card.
 
-Implementing "<card title>" will modify:
-- <file or component>
-- <file or component>
+## Card
+Title: <card title>
+Description: <card description>
+Status: in-progress
+Card ID: <cardId>
 
-The following criteria from other features may be affected:
-- Feature: "<other feature title>"
-  Criterion: "<criterion description>" (ID: <full-uuid>)
-  Risk: <why this implementation could break it>
+## Acceptance Criteria
+<list all criteria from linked features, with criterionId and Given/When/Then description>
 
-Options:
-1. Proceed anyway (I'll accept the regression risk)
-2. Adjust the plan to preserve these criteria
-3. Cancel
+## Todo List (implement in this order)
+<list card todos in order>
 
-Please reply with 1, 2, or 3.
-```
+## Prior QA Failures (if any)
+<list any criteria that previously failed — these must be fixed>
 
-- **Option 1 (Proceed)**: Note the at-risk criteria in the plan, continue to Step 6
-- **Option 2 (Adjust)**: Include criteria preservation in the plan requirements, continue to Step 6
-- **Option 3 (Cancel)**: Move the card back to `ready`:
-  ```
-  <MCP_PREFIX>move_card({ cardId: "<cardId>", status: "ready" })
-  ```
-  Then stop.
+## Codebase Context
+App URL: http://www.rayburst.app
+Frontend: rayburst/ (React, TanStack Router, Tailwind v4)
+Backend: rayburst-api/ (Hono, Drizzle ORM, PostgreSQL)
 
-If no conflicts are found, proceed directly to Step 6.
+## Your Task
+Produce a complete implementation plan:
+1. List every file to create or modify (exact paths)
+2. Describe the approach for each acceptance criterion
+3. Cover any DB migrations, API changes, env vars needed
+4. Note edge cases and error handling
+5. If prior QA failures exist, add a 'Fixing QA Failures' section at the top
 
-### Step 6: Enter Plan Mode
-
-Enter plan mode (`EnterPlanMode`) to design the full implementation approach.
+Output the plan as structured markdown. Be specific — the executor will follow this plan without asking questions.
+  ",
+  description="Plan: <card title>"
+)
+```
 
-The plan must cover:
-- Files to create or modify (with exact paths)
-- Implementation approach for each acceptance criterion from the test plan
-- Any database migrations, API changes, or environment variable additions needed
-- Edge cases and error handling
-- How at-risk criteria from Step 5 (if any) will be preserved
+Store the plan output as `$PLAN`.
 
-The plan is presented to the user for approval before any code is written. Use `AskUserQuestion` in plan mode if architectural choices need clarification before finalizing.
+---
 
-### Step 7: Write Plan as Card Comment
+### Step 7: Post Plan as Card Comment
 
-After the user approves the plan (via `ExitPlanMode`), post a concise summary to the card:
+Post the plan to the card before execution starts:
 
 ```
 <MCP_PREFIX>add_comment({
   cardId: "<cardId>",
-  content: "## Implementation Plan\n\n<plan summary in 2-3 sentences>\n\n### Files to Modify\n- <file path>\n- <file path>\n\n### Approach\n<prose description of the approach>\n\n### Acceptance Criteria Coverage\n- Criterion: <description> — <how it will be satisfied>\n- Criterion: <description> — <how it will be satisfied>"
+  content: "## Implementation Plan\n\n<$PLAN summary — 2-3 sentences>\n\n### Files to Modify\n- <file>\n\n### Approach\n<prose>\n\n### Criteria Coverage\n- <criterion>: <how satisfied>"
 })
 ```
 
-Keep the comment under 5000 characters. Use plain markdown prose — no raw code snippets or code fences with actual code (describe the approach, don't paste it).
-
-### Step 8: Execute Implementation
+Keep under 5000 characters. Describe the approach — no raw code blocks.
 
-Switch to execute mode. Work through the implementation:
-
-1. **Work the todo list in order** — use `list_card_todos` to get the ordered checklist, implement each item before moving to the next
-2. **Make atomic changes** — one logical unit at a time (e.g., backend schema first, then service, then routes, then frontend)
-3. **Run tests after significant changes**:
-   ```bash
-   cd rayburst && npm run test -- <relevant-test-file>
-   cd rayburst-api && npm run type-check
-   ```
-4. **Run lint/type check before moving on**:
-   ```bash
-   cd rayburst && npm run check
-   cd rayburst-api && npm run check
-   ```
+---
 
-**At-risk criteria preservation**: If Step 5 flagged criteria from other features, verify after each relevant change that the behavior described in those criteria is still correct.
+### Step 8: Spawn Executor Agent
 
-### Step 9: Verify Criteria
+Spawn a `general-purpose` subagent to execute the plan. Pass it the full plan and all card context.
 
-After implementation is complete, do a self-check pass for each acceptance criterion:
+```
+Agent(
+  subagent_type="general-purpose",
+  prompt="
+You are implementing a Rayburst board card. Execute the plan below completely. Do not ask questions — make decisions and write the code.
 
-For each criterion in the test plan:
-- Does the implemented code satisfy the criterion's described behavior?
-- Are there relevant tests that cover this behavior? If yes, do they pass?
-- Use `Grep` to confirm the key logic is in place
+## Card
+Title: <card title>
+Card ID: <cardId>
+MCP Prefix: <MCP_PREFIX>
 
-If any criterion is clearly not satisfied, loop back to Step 8 and fix it before continuing. Do not proceed to Step 10 with known gaps.
+## Implementation Plan
+<full $PLAN>
 
-### Step 10: Move Card to `validation` and Print Summary
+## Acceptance Criteria (verify each before finishing)
+<list all criteria with criterionId>
 
-Move the card to `validation` status:
+## Todo List (work in this order)
+<list card todos>
 
-```
-<MCP_PREFIX>move_card({ cardId: "<cardId>", status: "validation" })
+## Execution Rules
+- Work through todos in order
+- Make atomic changes (backend schema → service → routes → frontend)
+- After backend changes: run `cd rayburst-api && npm run type-check`
+- After frontend changes: run `cd rayburst && npx biome check <changed files>`
+- After implementation: do a self-check — does each criterion have code that satisfies it?
+- When all todos are complete and criteria are satisfied, call:
+  <MCP_PREFIX>move_card({ cardId: '<cardId>', status: 'validation' })
+- Then post a summary comment:
+  <MCP_PREFIX>add_comment({ cardId: '<cardId>', content: '## Implementation Complete\n\n### What was built\n<summary>\n\n### Files changed\n- <file>\n\n### Criteria coverage\n- <criterion>: satisfied via <explanation>' })
+- Return a completion message listing files changed and criteria satisfied.
+  ",
+  description="Implement: <card title>"
+)
 ```
 
-Post a brief implementation summary comment:
+---
 
-```
-<MCP_PREFIX>add_comment({
-  cardId: "<cardId>",
-  content: "## Implementation Complete\n\nReady for QA validation.\n\n### What was built\n<brief prose summary of what was implemented>\n\n### Files changed\n- <file path>\n- <file path>\n\n### Criteria coverage\n- <criterion description>: satisfied via <brief explanation>"
-})
-```
+### Step 9: Print Summary
 
-Then print:
+After the executor returns, print:
 
 ```
 ## Implementation Complete: <Card Title>
@@ -299,7 +251,6 @@ Then print:
 
 ### Files Changed
 - <file path>
-- <file path>
 
 Run `/rb:validate-card <cardId>` to run QA validation.
 ```
@@ -308,9 +259,16 @@ Run `/rb:validate-card <cardId>` to run QA validation.
 
 ## MCP Curl Fallback
 
-When MCP tools are unavailable, use this curl pattern for all operations. Read the API key from `.mcp.json` under the server assigned to the `engineer` role (or the first HTTP server entry if config is missing).
+When MCP tools are unavailable, use curl JSON-RPC. Read the API key from `.mcp.json` under the server assigned to the `engineer` role (or the first HTTP server entry).
 
 ```bash
+# Ping
+curl -s -X POST "https://api.rayburst.app/api/v1/mcp" \
+  -H "Authorization: Bearer <KEY>" \
+  -H "Content-Type: application/json" \
+  -H "Accept: application/json, text/event-stream" \
+  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"ping","arguments":{}}}'
+
 # Get card
 curl -s -X POST "https://api.rayburst.app/api/v1/mcp" \
   -H "Authorization: Bearer <KEY>" \
@@ -331,34 +289,6 @@ curl -s -X POST "https://api.rayburst.app/api/v1/mcp" \
   -H "Content-Type: application/json" \
   -H "Accept: application/json, text/event-stream" \
   -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"add_comment","arguments":{"cardId":"<cardId>","content":"<comment>"}}}'
-
-# List comments (used in Step 3b to detect prior QA failures)
-curl -s -X POST "https://api.rayburst.app/api/v1/mcp" \
-  -H "Authorization: Bearer <KEY>" \
-  -H "Content-Type: application/json" \
-  -H "Accept: application/json, text/event-stream" \
-  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_comments","arguments":{"cardId":"<cardId>"}}}'
-
-# List validations (used in Step 3b to identify failing criteria)
-curl -s -X POST "https://api.rayburst.app/api/v1/mcp" \
-  -H "Authorization: Bearer <KEY>" \
-  -H "Content-Type: application/json" \
-  -H "Accept: application/json, text/event-stream" \
-  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_validations","arguments":{"cardId":"<cardId>"}}}'
-
-# Submit validation report (Steps 13)
-curl -s -X POST "https://api.rayburst.app/api/v1/mcp" \
-  -H "Authorization: Bearer <KEY>" \
-  -H "Content-Type: application/json" \
-  -H "Accept: application/json, text/event-stream" \
-  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"submit_validation","arguments":{"cardId":"<cardId>","results":[{"criterionId":"<id>","status":"pass","comment":"<evidence>"}],"overallComment":"N of total criteria passing."}}}'
-
-# Move card to done (Step 14 — only after submit_validation passes)
-curl -s -X POST "https://api.rayburst.app/api/v1/mcp" \
-  -H "Authorization: Bearer <KEY>" \
-  -H "Content-Type: application/json" \
-  -H "Accept: application/json, text/event-stream" \
-  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"move_card","arguments":{"cardId":"<cardId>","status":"done"}}}'
 ```
 
 Parse the `data:` line from the SSE response to extract the JSON result.
@@ -369,15 +299,9 @@ Parse the `data:` line from the SSE response to extract the JSON result.
 
 - **Full UUIDs only** — short hashes return NOT_FOUND
 - **Rate limit: 60 req/min** — batch MCP calls in groups of 4-5
-- **Move card to `in-progress` before plan mode** (Step 4) — board must reflect active work
+- **No interactive plan approval** — planner agent produces the plan, executor runs it immediately
+- **Move card to `in-progress` before planning** (Step 5) — board must reflect active work
 - **Post plan as comment before executing** (Step 7) — creates a paper trail
-- **Move card to `validation` before QA** (Step 10) — required before running browser tests
-- **Always run QA validation after implementation** (Steps 11–13) — never stop at `validation` status
-- **Only move card to `done` after `submit_validation` passes** (Step 14) — the MCP gate is mandatory
-- **On QA failure: post comment then move to `in-progress`** — never leave a failed card in `validation`
-- **Do NOT fix failing criteria during QA** — report them, return the card, and stop
-- **If conflict detection finds at-risk criteria, STOP and prompt** — do not silently proceed
-- **If user cancels after conflict detection, move card back to `ready`** before stopping
+- **Executor moves card to `validation`** — do not move it manually after spawning
 - **Implementation comments under 5000 characters** — no raw code in comment content
-- **Validation criterion comments under 500 characters** — plain prose only, no backticks
 - **Run `/rb:init` first** if `.claude/rb-config.md` is missing

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rayburst/cc",
-  "version": "1.0.25",
+  "version": "1.0.26",
   "description": "Rayburst slash commands for Claude Code — /rb:init, /rb:plan, /rb:sync, /rb:status, /rb:validate-feature, /rb:validate-card, /rb:implement, /rb:discover",
   "bin": {
     "rayburst-cc": "bin/install.js"