本文へ移動
cccskills
無料GitHub で公開

vibe-gap-closure-loop

Closes 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. Use after a gap analysis, audit, or review produces 10+ findings, or to burn down a large bug or tech-debt backlog.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md5.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

vibe-gap-closure-loop

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-analysis produced a gap report
  • After any audit, review, or vibe-spec-sync audit 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-design first)
  • 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: latest docs/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:

  1. Integrate the stream branches (vibe-cherry-pick-integration if they were isolated)
  2. Run the full test suite and linters
  3. Fix failures directly (often interactions between streams)
  4. 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

WavePriorityFindingsStatus
0P03Complete
1P112In progress (8/12)
2P225Pending
3P310Deferred to backlog
StreamFindingsCommitsTests after
SecurityC-1, C-2, H-1abc123PASS

Escalated to Human Review

  • [finding] — [why it didn't close]

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Validates completed work against defined acceptance criteria. Use after completing a task that has specific success criteria defined in issues, specs, or task descriptions.

日本語の概要は準備中です。原文の説明を表示しています。

ash1794/vibe-engineering1642026年10月8日 更新

Generates edge case, failure mode, and spec-driven test cases. Covers boundary values, nil inputs, concurrency, resource exhaustion, malformed data, and requirement-linked traceability tests. Use after happy-path tests exist and before claiming coverage is complete, when requirements lack tests, or before a security review.

日本語の概要は準備中です。原文の説明を表示しています。

ash1794/vibe-engineering1642026年10月8日 更新

Catches shortcuts and reward hacking — weakening or deleting tests to make them pass, hard-coding expected outputs, silently dropping requirements, or claiming work is done without running it. Use before declaring a task complete and whenever a test or requirement feels like it's in the way.

日本語の概要は準備中です。原文の説明を表示しています。

ash1794/vibe-engineering1642026年10月8日 更新

Safely integrates commits from parallel agent branches using sequential cherry-pick. Use after parallel work completes in isolated branches or worktrees.

日本語の概要は準備中です。原文の説明を表示しています。

ash1794/vibe-engineering1642026年10月8日 更新

Audits tests for concurrency safety — race conditions, shared mock state, cleanup ordering. Use when writing tests that involve goroutines, async operations, or shared mutable state.

日本語の概要は準備中です。原文の説明を表示しています。

ash1794/vibe-engineering1642026年10月8日 更新

Enforces tiered test coverage standards with three dimensions — line coverage by tier, spec-to-test traceability, and spec-to-code implementation mapping. Use before claiming code is complete.

日本語の概要は準備中です。原文の説明を表示しています。

ash1794/vibe-engineering1642026年10月8日 更新

ash1794 のスキルをすべて見る

このスキルの問題を報告する