| Human Note | Missing re-export shouldn't require a plan-set --gaps and execute-set --gaps but that is what is recommended right now |
| Version | 6.0.0 |
| Skill | execute-set |
Problem Statement
When post-execution verification identifies trivial gaps (e.g., a single missing re-export in a barrel file), the execute-set skill recommends the full gap-closure ceremony: /rapid:plan-set N --gaps followed by /rapid:execute-set N --gaps. This is disproportionate overhead for a one-line fix. The user ends up just doing it manually, which means the gap-closure workflow is effectively bypassed for the most common class of gaps.
The current gap reporting in execute-set always suggests the same next step regardless of gap severity:
To close gaps: /rapid:plan-set {SET_INDEX} --gaps then /rapid:execute-set {SET_INDEX} --gaps
There is no distinction between a gap that requires architectural rework and one that needs a single line change.
Proposed Solution
Classify gaps by complexity during verification and offer tiered resolution paths:
- Trivial gaps (missing exports, typos, minor config additions): Offer an inline
/rapid:quick-style fix directly from the execute-set skill, or let the verifier agent fix them on the spot before writing GAPS.md.
- Non-trivial gaps (missing functionality, behavioral mismatches): Continue recommending the full plan-set --gaps / execute-set --gaps ceremony.
The verifier agent already has enough context to judge severity. It could return a severity: "trivial" | "non-trivial" field per gap in its RAPID:RETURN, and the execute-set orchestrator could act accordingly.
Current Workaround
Fix trivial gaps manually (read the file, make the one-line edit, commit) instead of running the gap-closure workflow.
Related Issues
None identified.
Co-Authored-By: Claude Opus 4.6
Problem Statement
When post-execution verification identifies trivial gaps (e.g., a single missing re-export in a barrel file), the execute-set skill recommends the full gap-closure ceremony:
/rapid:plan-set N --gapsfollowed by/rapid:execute-set N --gaps. This is disproportionate overhead for a one-line fix. The user ends up just doing it manually, which means the gap-closure workflow is effectively bypassed for the most common class of gaps.The current gap reporting in execute-set always suggests the same next step regardless of gap severity:
There is no distinction between a gap that requires architectural rework and one that needs a single line change.
Proposed Solution
Classify gaps by complexity during verification and offer tiered resolution paths:
/rapid:quick-style fix directly from the execute-set skill, or let the verifier agent fix them on the spot before writing GAPS.md.The verifier agent already has enough context to judge severity. It could return a
severity: "trivial" | "non-trivial"field per gap in its RAPID:RETURN, and the execute-set orchestrator could act accordingly.Current Workaround
Fix trivial gaps manually (read the file, make the one-line edit, commit) instead of running the gap-closure workflow.
Related Issues
None identified.
Co-Authored-By: Claude Opus 4.6