/fix
Called by team.md router when action is `fix`.
$ npx -y skills add coco-research/coco --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/fix
Context preview
What this command does when you run it.
Called by team.md router when action is `fix`.
Command definition
fix.md/team fix — Fix Pipeline
> Called by team.md router when action is `fix`.
Role Selection Bias
| Layer | Preferred Roles | Count | |-------|----------------|-------| | L1 | technical-analyst, security-analyst | 2 | | L2 | (domain-dependent engineers) + qa-test-architect, performance-eng (if perf-related) | 2-4 | | L3 | domain-accuracy | 2 | | L4 | principal-architect | 1 |
Issue Detection
L1 agents identify issues from:
- Conversation context (user described bugs, review findings, error logs)
- `.planning/` review documents (if GSD active)
- Test failure output
Group issues by file ownership — no two L2 agents touch the same files.
Pipeline Customization
Layer 1: Diagnosis
L1 agents focus on:
- Root cause analysis for each reported issue
- File mapping — which files need changes
- Impact assessment — what else might break
- **Component triage.** When `.arch/index.json` exists and is CURRENT, name the component
each issue falls inside, from `.arch/INDEX.md`. This is a triage and communication aid: it groups related issues and tells a reviewer which boundary is under repair. It is not a constraint on which files the fix may touch — a legitimate fix routinely spans several components, and the index is at a coarser altitude than the change. Do not escalate a cross-component fix as a boundary violation.
- If a fix genuinely deletes or relocates a component's primary paths, note it so
`/team arch drift` can reconcile the index afterwards.
Layer 2: Execution
- **Mode:** `bypassPermissions`
- Each agent gets a specific issue set with file ownership
- Agents write a failing test first that reproduces the bug (prove it is RED for the right reason), then fix, then prove it is GREEN. A regression test that was never red does not prove the fix.
- Run the authoritative gate per the Test Evidence Protocol (`team:evidence.md`): CI-pinned tool versions, integration dependencies provisioned, any skip treated as `UNVERIFIED` (never a pass), and capture command + exit code + summary to `EVIDENCE.md`. "Fixed + tested" is not a valid claim without that evidence.
- Atomic commits per fix: `fix({scope}): {description}`
**Toolkit integration:**
- Check team:toolkit.md for "Systematic Debugging" entry
- Apply systematic-debugging methodology for complex bugs
Layer 3: Fix Verification
L3 agents verify:
- Root cause actually addressed (not just symptom masked)
- No new issues introduced
- Test coverage for the fixed code path, confirmed against `EVIDENCE.md` (the bug-reproducing test actually ran and is now green) — not by reading test descriptions
Regression Tests
Run after all Layer 2 agents complete, per the Test Evidence Protocol (`team:evidence.md`): run the CI-equivalent authoritative gate with integration dependencies provisioned, capture the parsed summary + coverage to `EVIDENCE.md`, and surface skips/`UNVERIFIED` explicitly. Any failing test BLOCKS — loop back to fix (max 3 rounds); do not merely note it in REVIEW-PACKAGE.md.
GSD Integration
When `.planning/` exists, L2 agents follow GSD commit conventions. Include fix context in STATE.md.
Read more
/team fix — Fix Pipeline
> Called by team.md router when action is `fix`.
Role Selection Bias
| Layer | Preferred Roles | Count | |-------|----------------|-------| | L1 | technical-analyst, security-analyst | 2 | | L2 | (domain-dependent engineers) + qa-test-architect, performance-eng (if perf-related) | 2-4 | | L3 | domain-accuracy | 2 | | L4 | principal-architect | 1 |
Issue Detection
L1 agents identify issues from:
- Conversation context (user described bugs, review findings, error logs)
- `.planning/` review documents (if GSD active)
- Test failure output
Group issues by file ownership — no two L2 agents touch the same files.
Pipeline Customization
Layer 1: Diagnosis
L1 agents focus on:
- Root cause analysis for each reported issue
- File mapping — which files need changes
- Impact assessment — what else might break
- **Component triage.** When `.arch/index.json` exists and is CURRENT, name the component
each issue falls inside, from `.arch/INDEX.md`. This is a triage and communication aid: it groups related issues and tells a reviewer which boundary is under repair. It is not a constraint on which files the fix may touch — a legitimate fix routinely spans several components, and the index is at a coarser altitude than the change. Do not escalate a cross-component fix as a boundary violation.
- If a fix genuinely deletes or relocates a component's primary paths, note it so
`/team arch drift` can reconcile the index afterwards.
Layer 2: Execution
- **Mode:** `bypassPermissions`
- Each agent gets a specific issue set with file ownership
- Agents write a failing test first that reproduces the bug (prove it is RED for the right reason), then fix, then prove it is GREEN. A regression test that was never red does not prove the fix.
- Run the authoritative gate per the Test Evidence Protocol (`team:evidence.md`): CI-pinned tool versions, integration dependencies provisioned, any skip treated as `UNVERIFIED` (never a pass), and capture command + exit code + summary to `EVIDENCE.md`. "Fixed + tested" is not a valid claim without that evidence.
- Atomic commits per fix: `fix({scope}): {description}`
**Toolkit integration:**
- Check team:toolkit.md for "Systematic Debugging" entry
- Apply systematic-debugging methodology for complex bugs
Layer 3: Fix Verification
L3 agents verify:
- Root cause actually addressed (not just symptom masked)
- No new issues introduced
- Test coverage for the fixed code path, confirmed against `EVIDENCE.md` (the bug-reproducing test actually ran and is now green) — not by reading test descriptions
Regression Tests
Run after all Layer 2 agents complete, per the Test Evidence Protocol (`team:evidence.md`): run the CI-equivalent authoritative gate with integration dependencies provisioned, capture the parsed summary + coverage to `EVIDENCE.md`, and surface skips/`UNVERIFIED` explicitly. Any failing test BLOCKS — loop back to fix (max 3 rounds); do not merely note it in REVIEW-PACKAGE.md.
GSD Integration
When `.planning/` exists, L2 agents follow GSD commit conventions. Include fix context in STATE.md.
Meet Coco. A superintelligent agent framework powered by an advisory board of 389 world-class minds. Scale your AI assistant into a complete engineering department with 142 skills, 277 commands, and persistent state. Universal compatibility. Local privacy. Free and open source.
Repo: coco-research/coco
Other commands on coco.
- /mermaid
Build beautiful Mermaid diagrams using beautiful-mermaid. Covers all 6 diagram types, theming, SVG/ASCII output, and CoCo Platform integration.
Open command - /read
Show latest emails from a specific person. Usage: /email-read alice
Open command - /reply
Draft a reply to a specific email. Usage: /email-reply Project Phase 2 Contract Data
Open command - /save
Save matching emails to a project folder for sync processing. Usage: /email-save alice to emails/
Open command - /search
Search emails by subject keywords. Usage: /email-search github webhook
Open command - /summary
AI summary of today's emails — key decisions, action items, meetings. No arguments needed.
Open command

