vibe-quality-loop
npx machina-cli add skill ash1794/vibe-engineering/quality-loop --openclawvibe-quality-loop
The quality loop prevents premature "done" declarations. You keep iterating until the work is actually clean.
When to Use This Skill
- After any implementation that touches more than 3 files
- After implementing a feature with tests
- When you've made changes and want to verify quality
- Before creating a commit on completed work
When NOT to Use This Skill
- Single-line fixes or typo corrections
- Documentation-only changes
- When the user says "just get it working, we'll clean up later"
The Loop
┌─────────────┐
│ Implement │
└──────┬──────┘
v
┌─────────────┐
│ Self-Review │ ← Read your own diff. Would you approve this PR?
└──────┬──────┘
v
┌─────────────┐
│ Run Tests │ ← ALL tests, not just the ones you wrote
└──────┬──────┘
│
├── Tests pass + Review clean → EXIT (done!)
│
v
┌─────────────┐
│ Fix Issues │ ← Fix what broke, don't add new features
└──────┬──────┘
│
└── Go back to Self-Review
Steps
-
Self-Review — Read your entire diff. Check for:
- Unused imports/variables
- Hardcoded values that should be constants
- Missing error handling at system boundaries
- Functions over 50 lines
- Any TODO without an issue reference
-
Run Tests — Run the full test suite, not just affected tests:
- If Go:
go test ./...andgo test -race ./... - If JS/TS:
npm testor equivalent - If Python:
pytest - Note any failures
- If Go:
-
Fix Issues — Address ONLY the issues found. Don't add features.
-
Loop — Go back to step 1. Track iteration count.
-
Exit — When tests pass AND review is clean. Report iteration count.
Output Format
Quality Loop: [Feature Name]
Iterations: X Final Status: CLEAN / KNOWN_ISSUES
| Iteration | Issues Found | Issues Fixed |
|---|---|---|
| 1 | [list] | [list] |
| 2 | [list] | [list] |
Remaining Known Issues (if any):
- [Issue that was deliberately deferred, with justification]
Source
git clone https://github.com/ash1794/vibe-engineering/blob/master/skills/quality-loop/SKILL.mdView on GitHub Overview
Enforce the cycle Implement → Review → Test → Fix → Loop until the work is clean. It prevents premature 'done' exits after non-trivial changes by ensuring thorough review and full test verification before commit.
How This Skill Works
When a change is non-trivial, you implement, read your diff in Self-Review, run the full test suite, and fix issues. If tests pass and the review is clean, you exit; otherwise you loop back to Self-Review.
When to Use It
- After any implementation that touches more than 3 files
- After implementing a feature with tests
- When you've made changes and want to verify quality
- Before creating a commit on completed work
Quick Start
- Step 1: Self-Review the diff for issues (unused imports, hardcoded values, missing error handling, long functions, TODOs)
- Step 2: Run the full test suite and note failures or flaky tests
- Step 3: If issues exist, fix them and loop back; if tests pass and review is clean, exit
Best Practices
- Only invoke after non-trivial changes; avoid single-line fixes or docs-only edits
- Read and critique your entire diff during Self-Review for unused imports, constants, error handling, long functions, and todos with issue refs
- Run the full test suite, not just the tests you touched
- Fix issues without introducing new features during the loop
- Track iteration count and document the final status when exiting
Example Use Cases
- Feature touches more than three files and has unit tests; you iterate until all tests pass and the diff is clean
- A bug fix that breaks multiple modules; you perform a full test pass and refine the code until green
- Refactoring that touches public interfaces; you review, test, and adjust until no behavioral changes are detected
- An integration change requiring end-to-end verification across components; you loop until integration tests pass
- A performance optimization with tests where you re-verify correctness and code quality through the loop
