vibe-scope-guard
SkillDev toolsDetects and redirects scope creep during implementation, unrequested features, drive-by refactors, premature abstraction, and over-engineering. Use while implementing, especially when a change is growing beyond the original request.
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-scope-guard skill
What this skill tells your AI
The instructions your AI receives, as published by ash1794/vibe-engineering in plugins/vibe-engineering/skills/vibe-scope-guard/SKILL.md and read by ahel’s review.
The best code is the code you don't write. Frontier coding models tend to over-build: extra configurability, defensive layers, helpers "for later." Stay on what was asked.
When to Use This Skill
- During any implementation task
- When you notice you're "improving" code that wasn't in the request
- When the diff is noticeably larger than the request implies
- When you're about to create an abstraction "for later"
When NOT to Use This Skill
- During brainstorming (ideas should be unconstrained)
- When the user explicitly asks for broad improvements
- When the extra work is necessary for correctness (a bug in the code path you're changing)
Scope Creep Signals
| Signal | Example | Response |
|---|---|---|
| Unrequested features | "While I'm here, let me add caching" | Was caching requested? |
| Premature abstraction | "Let me create a generic helper for this" | Is there a second caller today? |
| Gold plating | "Comprehensive error messages for every case" | Only at system boundaries |
| Drive-by refactor | "This function could be cleaner" | Not in this change |
| Over-engineering | "Let me make this configurable" | Does anyone need to configure it? |
| Defensive sprawl | Validation and fallbacks for states that can't occur | Trust internal invariants; validate at the boundary |
| Documentation creep | "Docstrings on all these functions" | Only on what you changed |
| Test over-expansion | "Test every possible input" | Test boundaries and behaviors, not permutations |
The Rule
Three similar lines of code are better than a premature abstraction.
Before adding anything not explicitly requested:
- Was it requested? → No →
- Is it required for the requested change to be correct? → No →
- Don't add it. Mention it as a suggestion in the summary if it's worth the user's attention.
Steps
When you detect scope creep:
- Stop — Don't commit the extra work
- Revert it if it's already written
- Note it: "Also noticed: [X]. Not changed; want a follow-up?"
- If the user accepts — do it as a separate, clearly labeled change
Output
This skill mostly changes behavior rather than producing output. When invoked explicitly:
Scope Audit
Original request: [what was asked] Scope additions detected: X
| Addition | Requested? | Needed for correctness? | Action |
|---|---|---|---|
| [extra work] | No | No | Removed; suggested as follow-up |
Signals
- GitHub stars
- 85
- Forks
- 20
- Last commit
- Oct 2026
Advanced
- Item type
- skill
- Key
vibe-scope-guard- Source
- github.com/ash1794/vibe-engineering
github.com/ash1794/vibe-engineering