Menü
Read-only diagnosis phase for SWE-bench instances. Reproduce the failure, identify the code that needs to change, and print a concise handoff for /craft. No edits, no external access.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Read-only diagnosis phase for SWE-bench instances. Walks the codebase, reproduces the failure, and produces a structured handoff for /craft. Single diagnostician; correction comes from the audit→recon outer loop, not a parallel blind. No edits, no external access.
Read-only diagnosis phase for SWE-bench instances -- the STATIC ablation arm for recon (prereg-pro-v1-feynman). Identical to recon in goal, typing, process, and handoff; it removes ONLY scoped diagnostic perturbation -- it may not run experiments during diagnosis. It may REASON about what an experiment would show, but it cannot execute one. "Write down the problem, think real hard, write down the solution." No edits, no external access.
Read-only diagnosis phase for SWE-bench instances. Walks the codebase, reproduces the failure, and produces a fix-plan handoff for /craft. Single diagnostician; correction comes from the audit->ask outer loop, not a parallel blind. No edits, no external access.
Implementation phase for SWE-bench instances. You generate the patch from the recon handoff; a codex subagent challenges it; the gate arbitrates. Loops until FAIL_TO_PASS tests pass. On audit re-entry, narrows a fix that regressed. Stops when gate is green or the attempt budget is exhausted.
| name | minimal |
| description | Read-only diagnosis phase for SWE-bench instances. Reproduce the failure, identify the code that needs to change, and print a concise handoff for /craft. No edits, no external access. |
| argument-hint | <instance-id> |
| allowed-tools | Read, Grep, Glob, Bash |
Work in the container, run the failing tests, find the code path that causes the failure, and hand off the most likely fix area. Do not edit files. Use the helper commands named by the adapter, and run from the repo root.
Print your result to stdout as a markdown block starting with # Recon: so /craft can consume it. Keep the handoff concrete: what fails, where it fails, what code is responsible, and what files need to change.
Use this structure:
# Recon: <instance-id>
## Failure summary
<what the tests check, how they fail, error message>
## Suspect set
- `path/file.py` lines 10-40: <why suspect>
## Root cause
<what is wrong and why>
## Edit sites
- `path/file.py` lines 10-20: <what needs to change>
## Open questions
- <anything unresolved>
If audit reports that the prior patch failed, re-run the diagnosis from the new failure output and update the handoff. Keep it read-only, grounded in the code, and specific enough that craft can implement the fix.