scope-guard
Scannednpx machina-cli add skill athola/claude-night-market/scope-guard --openclawTable of Contents
- Philosophy
- When to Use
- When NOT to Use
- Quick Start
- 1. Score the Feature
- 2. Check Against Backlog
- 3. Verify Branch Budget
- 4. Monitor Thresholds
- Core Workflow
- Step 1: Calculate Worthiness (
scope-guard:worthiness-scored) - Step 2: Compare Against Backlog (
scope-guard:backlog-compared) - Step 3: Check Branch Budget (
scope-guard:budget-checked) - Step 4: Document Decision (
scope-guard:decision-documented) - Anti-Overengineering Rules
- Backlog Management
- Directory Structure
- Queue Rules
- Adding to Queue
- Integration Points
- With superpowers:brainstorming
- With superpowers:writing-plans
- During superpowers:execute-plan
- Required TodoWrite Items
- Related Skills
- Module Reference
Scope Guard
Prevents overengineering by both Claude and human during the brainstorm→plan→execute workflow. Forces explicit evaluation of every proposed feature against business value, opportunity cost, and branch constraints.
Philosophy
Core Belief: Not all features deserve implementation. Most ideas should be deferred to backlog until proven necessary.
Three Pillars:
- Worthiness Scoring - Quantify value vs cost before building
- Opportunity Cost - Compare against existing backlog
- Branch Discipline - Respect size thresholds
When To Use
- During brainstorming sessions before documenting designs
- During planning sessions before finalizing implementation plans
- When evaluating "should we add this?" decisions
- Automatically via hooks when branches approach thresholds
- When proposing new features, abstractions, or patterns
When NOT To Use
- Bug fixes with clear, bounded scope
- Documentation-only changes
- Trivial single-file edits (< 50 lines)
- Emergency production fixes
Quick Start
1. Score the Feature
Use the Worthiness formula:
(Business Value + Time Criticality + Risk Reduction) / (Complexity + Token Cost + Scope Drift)
Verification: Run the command with --help flag to verify availability.
See decision-framework.md for details.
Thresholds:
- > 2.0 → Implement now
- 1.0 - 2.0 → Discuss first
- < 1.0 → Defer to backlog
2. Check Against Backlog
Compare against docs/backlog/queue.md:
- Does it beat top queued items?
- Is there room in branch budget?
3. Verify Branch Budget
Default: 3 major features per branch
If at capacity, must drop existing feature, split to new branch, or justify override.
4. Monitor Thresholds
Watch for Yellow/Red zones:
- Lines: 1000/1500/2000
- Commits: 15/25/30
- Days: 3/7/7+
See branch-management.md for monitoring.
Core Workflow
Step 1: Calculate Worthiness (scope-guard:worthiness-scored)
Score each factor (1, 2, 3, 5, 8, 13):
- Value Factors: Business Value, Time Criticality, Risk Reduction
- Cost Factors: Complexity, Token Cost, Scope Drift
Details: decision-framework.md
Step 2: Compare Against Backlog (scope-guard:backlog-compared)
- Check
docs/backlog/queue.mdfor existing items - Compare Worthiness Scores
- New item must beat top queued item OR fit within branch budget
Step 3: Check Branch Budget (scope-guard:budget-checked)
Count current features in branch. If at budget (default: 3), new feature requires:
- Dropping an existing feature, OR
- Splitting to new branch, OR
- Explicit override with justification
Step 4: Document Decision (scope-guard:decision-documented)
Record outcome:
- Implementing: Note Worthiness Score and budget slot
- Deferring (MANDATORY STEPS):
- Create GitHub issue immediately - See github-integration.md
- Mark
scope-guard:github-issue-createdcomplete - Optionally add to
docs/backlog/queue.mdwith issue link
- Rejecting: Document why (low value, out of scope)
IMPORTANT: Deferral is NOT complete until a GitHub issue exists. This prevents context loss when branches are merged or abandoned.
Anti-Overengineering Rules
Key Principles:
- Ask clarifying questions BEFORE proposing solutions
- No abstraction until 3rd use case
- Defer "nice to have" features
- Stay within branch budget
See anti-overengineering.md for full rules and red flags.
Backlog Management
Directory Structure
**Verification:** Run the command with `--help` flag to verify availability.
docs/backlog/
├── queue.md # Active ranked queue
└── archive/
├── ideas.md # Deferred feature ideas
├── optimizations.md # Deferred performance work
├── refactors.md # Deferred cleanup
└── abstractions.md # Deferred patterns
Verification: Run the command with --help flag to verify availability.
Queue Rules
- Max 10 items in active queue
- Items older than 30 days without pickup → move to archive
- Re-score monthly or when project context changes
Adding to Queue
When deferring, add to docs/backlog/queue.md:
| Rank | Item | Worthiness | Added | Branch/Epic | Category |
|------|------|------------|-------|-------------|----------|
| 1 | [New item description] | 1.8 | 2025-12-08 | current-branch | idea |
Verification: Run the command with --help flag to verify availability.
Re-rank by Worthiness Score after adding.
Integration Points
With superpowers:brainstorming
At end of brainstorming, before documenting design:
- List all proposed features/components
- Score each with Worthiness formula
- Defer items scoring < 1.0 to backlog
- Check branch budget for remaining items
Self-invoke prompt: "Before documenting this design, let me evaluate the proposed features with scope-guard."
With superpowers:writing-plans
Before finalizing implementation plan:
- Verify all planned items have Worthiness > 1.0
- Compare against backlog queue
- Confirm within branch budget
- Document any deferrals
Self-invoke prompt: "Before finalizing this plan, let me verify scope with scope-guard."
During superpowers:execute-plan
Periodically during execution:
- Run threshold check: lines, files, commits, days
- Warn if Yellow zone reached
- Require justification if Red zone reached
Self-invoke prompt: "This branch has grown significantly. Let me check scope-guard thresholds."
Required TodoWrite Items
When evaluating a feature, create these todos:
scope-guard:worthiness-scoredscope-guard:backlog-comparedscope-guard:budget-checkedscope-guard:github-issue-created(MANDATORY if deferring - blocks step 5)scope-guard:decision-documented
Note: Step 4 (github-issue-created) is REQUIRED when deferring items. You cannot mark decision-documented complete without first completing github-issue-created for deferrals.
Related Skills
superpowers:brainstorming- Ideation workflow this guardssuperpowers:writing-plans- Planning workflow this validatesimbue:review-core- Review methodology pattern
Module Reference
- decision-framework.md - Worthiness formula, scoring, thresholds
- github-integration.md - MANDATORY issue creation for deferrals
- anti-overengineering.md - Rules, patterns, red flags
- branch-management.md - Thresholds, monitoring, zones
- baseline-scenarios.md - Testing scenarios and validation
Troubleshooting
Common Issues
Command not found Ensure all dependencies are installed and in PATH
Permission errors Check file permissions and run with appropriate privileges
Unexpected behavior
Enable verbose logging with --verbose flag
Source
git clone https://github.com/athola/claude-night-market/blob/master/plugins/imbue/skills/scope-guard/SKILL.mdView on GitHub Overview
Scope Guard is a pre-implementation workflow that prevents overengineering by enforcing explicit evaluation of every proposed feature. It relies on Worthiness Scoring, opportunity costs, and branch discipline to keep changes scoped and valuable. It can run during brainstorming, planning, or automatically when branches approach size limits.
How This Skill Works
It computes Worthiness as (Business Value + Time Criticality + Risk Reduction) / (Complexity + Token Cost + Scope Drift). The score is then checked against the backlog and current branch budget, and a formal decision is documented before proceeding.
When to Use It
- During brainstorming sessions before documenting designs.
- During planning sessions before finalizing implementation plans.
- When evaluating whether to add a feature, abstraction, or pattern.
- Automatically via hooks when a branch nears size thresholds (lines or commits).
- When proposing new functionality to ensure it truly delivers business value.
Quick Start
- Step 1: Score the Feature using the Worthiness formula (Business Value + Time Criticality + Risk Reduction) / (Complexity + Token Cost + Scope Drift) and verify with --help.
- Step 2: Check Against Backlog by comparing to docs/backlog/queue.md and ensuring space in the branch budget.
- Step 3: Verify Branch Budget and Document Decision if needed; prepare changes accordingly.
Best Practices
- Run Worthiness Scoring for every new feature idea.
- Cross-check with the backlog (docs/backlog/queue.md) for priority.
- Verify branch budget against line and commit thresholds (1000/1500/2000 lines; 15/25/30 commits).
- Document the decision with rationale and next steps.
- Use auto-hooks to enforce thresholds and prevent scope drift during development.
Example Use Cases
- Idea for a heavy analytics module is scored and deferred to backlog due to high cost.
- A new API endpoint is split into smaller changes after scoring to fit budget.
- A proposed UI refactor is rejected for now because it would exceed line limits.
- An optimization pattern is approved only after comparing opportunity cost against backlog.
- A trivial bug fix is excluded by scope-guard due to bounded scope.
Frequently Asked Questions
Related Skills
rigorous-reasoning
athola/claude-night-market
'Prevents sycophantic reasoning through checklist-based analysis, categorical
proof-of-work
athola/claude-night-market
'Enforces "prove before claim" discipline - validation, testing, and
workflow-monitor
athola/claude-night-market
automatically create GitHub issues for workflow improvements via /fix-workflow.
feature-review
athola/claude-night-market
'Feature review and prioritization with RICE/WSJF/Kano scoring. Creates