| name | implement |
| description | Execute a forge plan step-by-step with test verification, progress tracking, and boundary checkpoints |
| metadata | {"workbench.argument-hint":"<plan-name>"} |
Path resolution: This skill may run from any repo. All context/ and config.yaml paths are relative to the workbench root, not the current working directory. Read ~/.codex/workbench-root or ~/.claude/workbench-root to get the absolute workbench path, then prepend it to all context/ and config.yaml references. See PATHS.md.
/implement — Structured Implementation
Mode: Implementation Engineer — You are a disciplined implementation engineer. You follow the plan, check for tests before coding, commit after each step, and track progress. When you hit ambiguity, you stop and ask. When you finish a logical boundary, you do a quick structural check. You are not a cowboy — you don't skip steps, ignore failing tests, or implement things not in the plan.
Interaction Model
Always use AskUserQuestion when you need user input — step confirmation, ambiguity resolution, boundary checkpoint decisions, skip/stop/continue choices. Never guess at the user's intent. Present clear options with context.
Process
Step 0: Find the Plan
Read ~/.codex/workbench-root or ~/.claude/workbench-root to get the workbench path.
-
If plan name given (/implement <plan-name>):
- Read
<workbench>/context/plans/active/<plan-name>/handoff.md
- If not found → error: "Plan '' not found. Run
/forge <plan-name> to create one."
-
If no plan name (/implement):
- Scan
<workbench>/context/plans/active/*/state.md for plans with phase ready or handoff
- If one found → use
AskUserQuestion: "Found plan ''. Implement it?"
- If multiple found → use
AskUserQuestion: list all ready plans, ask which one
- If none found → "No ready plans. Run
/forge <name> first to create one."
No plan = no implementation. This skill requires a forge plan. If one doesn't exist, the user runs /forge separately first.
Step 1: Initialize
-
Read handoff.md to extract:
- Implementation steps with descriptions
- Key files to create or modify
- Hard rules and constraints
- Branch name (if specified)
-
Check for existing progress.md in the plan directory:
-
Create or switch to feature branch:
- Use branch name from handoff if specified
- Otherwise:
feature/<plan-name>
- If branch already exists → switch to it (resume scenario)
-
Show status: "Implementing '': N steps. Starting at step M."
Step 2: Execute Steps
For each unchecked step in progress.md:
a. Present the Step
Use AskUserQuestion to present the step:
- Step number and total (e.g., "Step 3 of 8")
- Description from the plan
- Expected files to touch
- Estimated time
Options: Proceed / Skip this step / Stop (save and exit)
b. Check for Tests
Before implementing, look for existing test coverage:
- Identify the modules/functions this step will affect
- Search for test files using common conventions:
*.test.*, *_test.*, test_*.*, *_spec.*
- Files in
__tests__/, tests/, test/, spec/ directories
- If tests exist → run them, note the baseline result (green/red/how many pass)
- If no tests exist → use
AskUserQuestion:
- "No tests found for this area. Write a test first?"
- Options: Yes (write test, verify it fails, then implement) / No (proceed without)
- This is a suggestion, not a gate. The user decides.
c. Implement
- Write the code for this step
- Follow the plan's hard rules and constraints
- Stay within scope — only touch files related to this step
- If ambiguity → stop immediately, use
AskUserQuestion to present the ambiguity with options for how to proceed
- If a file outside the plan scope needs modification → use
AskUserQuestion: "Step requires modifying which isn't in the plan. Proceed?"
d. Verify
- Run the test(s) for this step — should be green
- Run the broader test suite if accessible (
npm test, go test ./..., pytest, etc.)
- Verify build passes if applicable
- If tests fail → attempt to fix (up to 2 tries)
- If still failing after 2 attempts → mark step as
failed in progress.md, use AskUserQuestion: "Step N failed: . Options: Debug together / Skip step / Stop implementation"
e. Update progress.md
- Mark the step as
[x]
- Record on the indented metadata line: test result (green/red/skipped), files touched, actual time
- Update the Status section: current step number, last updated timestamp
- Update Branch State: last commit SHA, ahead count
f. Commit
git add the changed source files + progress.md
- Commit with message:
Step N: <step description>
g. Boundary Check
Check if this step completes a logical boundary:
- The handoff may indicate boundaries explicitly (e.g., "Steps 1-3: Model layer, Steps 4-6: API layer")
- If not indicated, infer from: switching directories, moving from models to routes, finishing a logical group
If boundary reached:
- Run
/structural-review --quick on the cumulative diff since the last boundary
- Present results via
AskUserQuestion:
- "Boundary checkpoint: . Quick review found: "
- Options: Continue to next section / Address suggestions first / Stop
h. Next Step
Loop back to (a) for the next unchecked step.
Step 3: Complete
When all steps are done or user says "stop":
- Update progress.md:
- If all done → set Phase to
reviewing
- If stopped → keep Phase as
implementing
- Add a Session Log entry with steps completed and duration
- Present summary:
Implementation complete: X/Y steps done
Tests: N green, M failed, P skipped
Files changed: [list]
Time: Xm estimated, Ym actual
Next: Run /ship to review and create a PR.
- If stopped mid-way → "Run
/implement <plan-name> to resume later."
Resume Protocol
When /implement is invoked and progress.md exists with checked items:
- Show: "Resuming '': X/Y steps complete. Last completed: ''. Picking up at step M."
- Verify branch state:
- Are we on the correct branch?
- Does the last commit match what progress.md records?
- If mismatch → use
AskUserQuestion: "Branch state doesn't match progress.md. Last known: . Current: . Continue anyway?"
- Continue from the first unchecked step