---
name: gofer:diagnose
description: "Run a reproduce-minimize-instrument-fix loop for bugs and failing tests."
---

# Gofer Diagnose

## Token And Cost Policy
<!-- gofer:token-cost-policy:start -->

Before spawning agents, calling tools, or loading large files:

1. Treat `.specify/memory/gofer-model-policy.yaml` as the repo-owned source of truth for simple, medium, hard, and arbiter model routing. If it is missing, run `/gofer:bootstrap-workspace` before continuing.
2. Use the cheapest capable model first.
   - Claude: Haiku for scouting/extraction; Sonnet for normal implementation, synthesis, validation, and security; Opus for high-risk arbitration or release-critical failures.
   - Codex/OpenAI: GPT mini for simple coding; GPT nano only for locate/classify/summarize/mechanical work; GPT-5.3-Codex or flagship GPT for tool-heavy coding, architecture, and release-critical validation.
   - Gemini: Flash-Lite for cheap large-context scan/summarize; Flash for default research synthesis; Pro for large-context architecture or high-risk arbitration.
   - Copilot: prefer Auto for simple and default work; ask the user before choosing a paid/high-tier picker model for hard security, architecture, or release gates.
3. Keep raw tool output out of the main conversation context. Save stable findings to `.specify/specs/{feature}/context-bundle.md`, then work from summaries.
4. Use provider prompt/context caching only for stable, non-secret prefixes: Gofer scaffold, AGENTS/CLAUDE/Copilot instructions, constitution, repo map, stage contracts, and validation rubric.
5. Before continuing after large research, planning, implementation, or validation bursts, checkpoint the durable artifacts and compact/clear/resume context when the host supports it.
6. Escalate model tier only when a cheaper pass is low-confidence, contradictory, security-sensitive, or blocking release quality.
<!-- gofer:token-cost-policy:end -->

Run a structured reproduce-minimize-instrument-fix investigation and write the
results to `.specify/specs/{feature}/diagnose-report.md`.

Use this when an implementation, test, or integration is failing and you need a
portable, evidence-backed debugging record that stays inside the feature
directory.

When you run this helper:

1. Start from the actual failure evidence already present in the session:
   failing output, stack traces, logs, screenshots, or a concrete bug report.
2. Reproduce the failure as directly as possible.
3. Minimize the problem to the smallest reliable failing slice.
4. Instrument the likely fault boundaries to prove or disprove hypotheses.
5. Record the recommended fix path without inventing evidence.
6. Write the artifact only to
   `.specify/specs/{feature}/diagnose-report.md`.
7. If the target file already exists, replace it and prepend a regeneration note
   such as `<!-- regenerated at [ISO timestamp] -->`.
8. Include the minimum provenance schema:
   - `GeneratedAt`
   - `SourceCommandId`
   - `SourceInputs`
   - `OverwriteNoticeWhenApplicable`

The generated diagnose report must contain these sections:

- `## Provenance`
- `## Reproduce`
- `## Minimize`
- `## Instrument`
- `## Fix`

Keep the content Gofer-owned. Do not copy upstream Matt Pocock skill text
verbatim.
