vibe-gap-closure-loop
SkillDev toolsCloses a large backlog of findings (a gap analysis, an audit, or 10+ bugs) in prioritized waves. Loops through triage, dependency analysis, parallel fix streams, a test gate, and re-audit until the target is met.
Instructions available. Your AI can read the instructions. Execution depends on the setup they require.
Account requirements not reviewed. Check the skill instructions before use; ahel provides instructions and does not run this skill.
Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.
Then ask your AI: use the vibe-gap-closure-loop skill
What this skill tells your AI
The instructions your AI receives, as published by ash1794/vibe-engineering in plugins/vibe-engineering/skills/vibe-gap-closure-loop/SKILL.md and read by ahel’s review.
When you have 50 findings, don't fix them in random order. Triage them into priority waves, fix each wave in parallel streams where dependencies allow, and don't start the next wave until tests pass.
When to Use This Skill
- After
vibe-gap-analysisproduced a gap report - After any audit, review, or
vibe-spec-syncaudit that produced 10+ findings - A backlog of 10+ bugs or tech-debt items
- Production readiness sprints
When NOT to Use This Skill
- Fewer than 5 findings (just fix them directly)
- Findings that need architectural redesign (use
vibe-research-before-designfirst) - All findings are in one file (a single focused pass is simpler)
Arguments
/vibe-gap-closure-loop [dimensions] [--target N] [--gap-file PATH]
dimensions: Which gap-analysis dimensions to close (default: all with open findings)--target: Target score per dimension (default:95)--gap-file: Path to the findings (default: latestdocs/plans/gap-analysis-*.md, or ask)
Autonomy
Follow the harness's permission mode. Under an autonomous or auto-approve mode, run the loop without stopping between phases. Otherwise, confirm the wave plan once before Step 3, then continue. Always stop and ask before destructive operations (migrations on real data, force-pushes, deleting files outside the findings' scope).
Step 1: Triage into Waves
Assign every finding a priority:
- P0 — Blocker: security vulnerability, data-loss risk, breaks core functionality
- P1 — High: wrong behavior, significant UX issue, missing critical feature
- P2 — Medium: incomplete implementation, minor bugs, documentation gaps
- P3 — Low: polish, optimization (candidates for deferral to the backlog)
Wave 0 = all P0, Wave 1 = P1, and so on. Don't start wave N+1 until wave N passes the test gate.
Step 2: Dependency Analysis & Streams
Within the current wave, build a dependency graph:
- Security findings block everything else
- Schema/migration changes block feature work on those tables
- "Add X to Y" depends on Y existing
- Test-infrastructure changes block test-dependent findings
- Trivial fixes have no dependencies, so batch them together
Group into parallel streams (use vibe-parallel-task-decomposition for large waves):
- 3–7 related findings per stream, sized for one agent session
- No two streams touch the same files (the main source of integration conflicts)
- A stream that depends on another stream's output moves to the next iteration
Step 3: Dispatch Streams
If the harness supports subagents, dispatch one per stream in parallel, ideally in isolated worktrees. Otherwise, run the streams sequentially yourself. Let the subagents inherit the session's model unless the user specified one.
Stream prompt:
You are closing findings for [project].
Stream: [name]
Findings: [IDs with full descriptions]
For each finding:
1. Read the relevant source files
2. Implement the fix described
3. Add or adjust a test that fails before the fix and passes after
4. Run the project's test command
Commit with: fix([area]): close [finding IDs]
Do NOT commit if tests fail. Do NOT weaken or delete existing tests to make them pass.
Return: findings closed, findings not closed (with reason), commit hashes.
Step 4: Test Gate
After all streams return:
- Integrate the stream branches (
vibe-cherry-pick-integrationif they were isolated) - Run the full test suite and linters
- Fix failures directly (often interactions between streams)
- Commit any remaining fixes
Step 5: Iteration Summary
Write docs/plans/closure/iteration-N-summary.md: streams, findings closed, commit hashes, cumulative progress, remaining open findings, and test results.
Step 6: Check Target
- Re-audit the target dimensions (
vibe-gap-analysis --dim N) or re-check the findings list - All targets met → DONE: commit and report
- Otherwise → next wave or next iteration, back to Step 2
Limits
- Max iterations: 5 per invocation
- Max parallel streams: whatever the harness handles well; 3–5 is a sensible default
- Max findings per stream: 7
- Escalate: a finding that fails to close after 2 iterations gets flagged for human review, not retried indefinitely
Output Format
Gap Closure: [project]
Findings: X total · Closed: Y · Deferred: Z · Escalated: W
| Wave | Priority | Findings | Status |
|---|---|---|---|
| 0 | P0 | 3 | Complete |
| 1 | P1 | 12 | In progress (8/12) |
| 2 | P2 | 25 | Pending |
| 3 | P3 | 10 | Deferred to backlog |
| Stream | Findings | Commits | Tests after |
|---|---|---|---|
| Security | C-1, C-2, H-1 | abc123 | PASS |
Escalated to Human Review
- [finding] — [why it didn't close]
Signals
- GitHub stars
- 85
- Forks
- 20
- Last commit
- Oct 2026
Advanced
- Item type
- skill
- Key
vibe-gap-closure-loop- Source
- github.com/ash1794/vibe-engineering
github.com/ash1794/vibe-engineering