| name | megacode-debug-hypotheses |
| description | Generate competing debug hypotheses and scoped worker prompts for ambiguous bugs. Use before parallel investigation or debug-hypotheses workflows. |
| disable-model-invocation | true |
MegaCode Debug Hypotheses
When a bug is ambiguous, produce competing hypotheses and isolated worker prompts instead of jumping to a single fix.
Inputs
- Symptom description (expected vs actual).
- Reproduction steps or failing test output.
- Recent changes, environment, and frequency (always / flaky).
- Optional: logs, stack traces, context map artifact.
Output format
1. Symptom summary
One paragraph: what fails, where, and impact.
2. Hypothesis table
| ID | Hypothesis | Likelihood | Discriminating evidence | Falsify if |
|---|
| H1 | ... | high/med/low | What to check | Observation that rules it out |
Produce 3–5 hypotheses covering different subsystems (logic, config, race, dependency, test bug).
3. Worker prompts (one per hypothesis)
Each prompt is self-contained for an explorer or implementer worker in read-only or worktree mode:
### Worker: H2 — <short title>
**Goal:** Confirm or falsify H2.
**Read-only paths:** ...
**Commands to run:** ...
**Stop when:** ...
**Artifact:** `.megacode/runs/<run_id>/hypothesis-H2.md`
4. Synthesis plan
- Order of execution (parallel safe vs sequential).
- Which hypothesis gets a worktree (only if a fix attempt is authorized).
- Stop conditions: all falsified, one confirmed, or escalate to user.
Rules
- Do not assign the same file ownership to parallel hypothesis workers.
- Prefer read-only exploration first; implementation only after a hypothesis is confirmed.
- Local reproduction only — no GitHub Actions log mining.
- Use
megacode-ci-fix only after a hypothesis points to a specific local failure.
