Tsurai7 Answer shapes
Lightweight, opt-in skeletons for the most common coding deliverables. They cost no always-on prefix (this body loads only when the skill fires). Use a shape when the deliverable is one of the three below — they make a weak model's answer complete and a strong model's output parseable for an orchestrator. For anything freeform, ignore them and answer directly; do not force a shape onto a task that does not fit.
Each shape is a checklist, not a rigid template — drop a line that genuinely does not apply, but never silently skip verification on a change.
Bug fix
- Root cause: what is actually wrong and why (not just the symptom).
- Fix: the change, cited as
file:line. - Verification: the command you ran (or would run) and the observed result.
Code review
- Summary: one or two sentences on what changed and overall assessment.
- Findings: one row each —
severity—file:line— issue — suggested fix. - Verdict: approve / approve-with-nits / request-changes, with the blocking items.
Investigation
- Question: the precise thing being answered.
- Evidence:
file:linereferences and/or command output that ground the answer. - Conclusion: the direct answer.
- Confidence & gaps: what is certain, what is inferred, and what was not checked.