ワンクリックで
fix
Meta-skill workflow orchestrator for bug investigation and resolution. Routes to debug, implement, test, and commit based on scope.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Meta-skill workflow orchestrator for bug investigation and resolution. Routes to debug, implement, test, and commit based on scope.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
The Code reporting discipline AND the reporting-system operations command. Discipline half — the "one spine" rule (every reportable unit of work lands one Weekly Work Tracker row, Source-tagged), field mapping, Bridge auto-mirror tie-in. Operations half (proposal 07) — /reporting status (registry tail, trust metrics, drift, next scheduled runs, log locations), /reporting run <pipeline>, /reporting heal. Use when finishing reportable work, when asked "how should I report this" / "log this for the report", at session end to capture unreported work, or for pipeline ops — "/reporting", "reporting status", "is reporting healthy", "run the health check", "why is a report row missing/stale".
Generate the weekly FourthOS sponsor update package for Carly (VP) and Christian (CTO). Pulls live portfolio data from the FourthOS Notion cockpit, refreshes the Notion Update Package page, renders a progressive-disclosure HTML artifact set (Tier 1 briefing dashboard, Tier 2 teaching deep-dive), stages it UNLISTED to the ai-enablement-decks GitHub Pages site, and notifies Dave to review before promoting it live. Use when asked to generate, build, preview, or promote the FourthOS weekly sponsor update, or when the CCv3-FourthOS-Weekly scheduled task runs. Triggers on "fourthos weekly", "sponsor update", "Carly update", "Christian update", "weekly portfolio update".
Run a feature through the full tri-model Game Plan pipeline — rostered roles (Claude hub, Grok builder/researcher, Codex reviewer/fixer), a workroom disk bus, and human gates. Use when the user types /game-plan [feature], says "run the game plan on X", "full crew on this", "roster this feature", or wants a multi-milestone feature built with cross-model build/review separation. Opt-in orchestrator on top of /workroom; for one-shot tasks use /grok or /codex directly, for trivial edits use neither.
Audit and curate the memory system -- identify signal vs noise, score entries, and archive low-quality learnings.
Detect drift between the continuous-claude repo and the active ~/.claude/ directory
Initialize Continuous Claude v3 for a new project with full toolset activation. Creates project CLAUDE.md (interview-driven, 8 sections), ROADMAP.md, knowledge tree, Serena code intelligence, and project registry entry. Use when opening a new project folder for the first time, starting a new project, setting up CCv3 in an existing repo, or the user says "init project", "setup project", "new project", "initialize", "start new project".
| name | fix |
| description | Meta-skill workflow orchestrator for bug investigation and resolution. Routes to debug, implement, test, and commit based on scope. |
| allowed-tools | ["Bash","Read","Grep","Write","Edit","Task"] |
Workflow orchestrator for bug investigation and resolution. Chains specialized agents based on issue scope.
References:
references/agents.mdreferences/debugging-procedures.md/fix <scope> [options] [description]
If the user types just /fix with no or partial arguments, guide them through this question flow.
question: "What would you like to fix?"
header: "Fix type"
options:
- label: "Help me choose (Recommended)"
description: "I'll ask questions to pick the right fix workflow"
- label: "Bug - something is broken"
description: "Chain: investigate → diagnose → implement → test → commit"
- label: "Hook - Claude Code hook issue"
description: "Chain: debug-hooks → hook-developer → implement → test"
- label: "Dependencies - import/package errors"
description: "Chain: preflight → research → plan → implement → qlty-check"
- label: "PR Comments - address reviewer feedback"
description: "Chain: github-search → research → plan → implement → commit"
Mapping:
question: "What kind of issue are you dealing with?"
options:
- label: "Something is broken/not working" → bug scope
- label: "Claude Code hook not firing" → hook scope
- label: "Import/dependency errors" → deps scope
- label: "Need to address PR feedback" → pr-comments scope
Free text — capture the error message, unexpected behavior, or PR link.
options:
- label: "Diagnose and fix" → full workflow
- label: "Diagnose only (dry run)" → --dry-run
- label: "Quick fix" → skip investigation, go straight to spark
multiSelect: true
options:
- label: "Write a regression test" → include regression phase
- label: "Commit the fix" → include commit phase
- label: "Just fix, nothing else" → --no-test --no-commit
Based on your answers, I'll run:
**Scope:** bug
**Issue:** "Login button not responding on Safari"
**Chain:** sleuth (investigate) → spark (fix) → arbiter (test) → commit
**Options:** (none)
Proceed? [Yes / Adjust settings]
| Scope | Chain |
|---|---|
bug | sleuth → diagnose → premortem → kraken (TDD) → kraken (test) → commit |
hook | debug-hooks → diagnose → premortem → kraken (hook-dev) → test → commit |
deps | dependency-preflight → oracle → plan-agent → premortem → kraken → qlty-check → commit |
pr-comments | github-search → research-codebase → plan-agent → premortem → kraken → commit |
See references/agents.md for full per-scope flow diagrams.
The bug and hook chains shown above default to sleuth for the investigation phase. Both agents load the systematic-debugging skill, so the methodology is identical — the split is about where you point the agent:
Both have model: opus and overlapping toolsets; the agent frontmatter description fields encode this split (see .claude/agents/sleuth.md and .claude/agents/debug-agent.md). When a /fix invocation passes a multi-file or intermittent symptom, prefer sleuth. When the symptom is one error message in one file or the user is unsure where it lives, prefer debug-agent.
| Option | Effect |
|---|---|
--no-test | Skip regression test creation |
--dry-run | Diagnose only, don't implement fix |
--no-commit | Don't auto-commit the fix |
SCOPE="${1:-bug}"
NO_TEST=false; DRY_RUN=false; NO_COMMIT=false
for arg in "$@"; do
case $arg in
--no-test) NO_TEST=true ;;
--dry-run) DRY_RUN=true ;;
--no-commit) NO_COMMIT=true ;;
esac
done
Spawn sleuth (bug/hook) or scope-appropriate agents (deps/pr-comments).
See references/debugging-procedures.md for the full sleuth investigation prompt.
Present structured findings: logs, database state, git state, runtime state, root cause hypothesis, proposed fix, risk rating.
See references/debugging-procedures.md for the full diagnosis report template.
REQUIRED — never skip.
AskUserQuestion(
question="Proceed with the proposed fix?",
options=["yes", "no", "modify"]
)
If "modify" → gather new requirements and update approach.
If "no" → create diagnostic handoff and exit.
If --dry-run → create diagnostic handoff and exit here.
Run /premortem quick after diagnosis approval.
See references/debugging-procedures.md for premortem context template.
Risk decision:
Route to kraken with scope-appropriate prompt.
See references/agents.md for per-scope kraken prompts.
Spawn kraken to write a focused regression test.
See references/agents.md for the regression test prompt.
AskUserQuestion(
question="Fix implemented. Please verify and confirm.",
options=["looks good", "needs adjustment", "revert"]
)
If "needs adjustment" → return to Phase 5. If "revert" → run rollback and exit.
Spawn general-purpose agent following the commit skill: git diff review → descriptive message → await confirmation → execute.
Always create a handoff, even with --dry-run.
See references/debugging-procedures.md for the full YAML schema.
Location: thoughts/shared/handoffs/fix/{scope}/{timestamp}_{description}.yaml
/fix bug # Investigate → diagnose → implement → test → commit
/fix bug --dry-run # Diagnose only, no code changes
/fix hook --no-commit # Fix hook, skip auto-commit
/fix bug --no-test # Fix and commit, no regression test
/fix pr-comments # Fetch PR, plan, implement, commit
| Checkpoint | Purpose | Skip Condition |
|---|---|---|
| After diagnosis | Confirm root cause | Never skip |
| After premortem | Accept or mitigate risks | No HIGH tigers |
| After fix | Verify resolution | Never skip |
| Before commit | Review changes | --no-commit |
Human checkpoints prevent wrong fixes, ensure user understands changes, and catch edge cases.