| name | gate-miss-to-issue |
| description | Promote a late-caught defect — one an earlier gate should have caught — into a development-skills issue proposing a fix to that gate's procedure. |
Gate-Miss-to-Issue
A gate's failure is invisible to the gates downstream of it — they judge the product, not which earlier step should have caught the defect. This skill captures that gap as a development-skills issue.
Do
- Propose which gate should have caught it — skill + step, or no existing gate if none owns the class. This is a hypothesis the issue confirms or redirects, not a blame verdict.
- State the blind spot as a general class, not the one token that slipped.
- File the proposal as an issue against
ultimatile/development-skills, via file-issue, with the four points below.
- On recurrence of a class that already has an open issue, comment on it instead of filing a duplicate.
Don't
- Don't edit the gate's
SKILL.md inline. File an issue; the fix is deliberated async so the work-repo PR that surfaced the miss is not blocked.
- Don't file for a one-off execution lapse the gate already covers — only for a generalizable procedure gap.
- Don't propose a code change here.
- Don't recurse: this skill has no gate of its own to postmortem.
Issue content
Hand file-issue these four points:
- Gate (proposed) — the skill + step you argue should have caught it, or none yet; the gate-owner confirms or redirects.
- Miss — the defect, and where it was finally caught; link the work-repo PR / issue for provenance.
- Blind spot — the generalizable procedure gap.
- Proposed improvement — a concrete procedure change (a new sweep, a tightened definition, an added probe class). A proposal; the fix is settled in the issue.
Toolchain names (skills, gates, review tools) are in-context for this repo — it is that toolchain — so the issue may reference them freely, unlike work-repo artifacts.
