Scores feature worthiness and enforces branch-size limits against overengineering. Use when evaluating whether a feature belongs in the current scope or branch.
Scores feature worthiness and enforces branch-size limits against overengineering. Use when evaluating whether a feature belongs in the current scope or branch.
The cheapest feature is the one you never build.
Scope-guard weighs each proposed feature against its value,
its cost, and the branch budget, so only what is earned ships.
Prevents overengineering by both Claude and human during the
brainstorm, plan, and 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.
Create Discussion - See
github-integration.md
Step 4.
Prompt: "Creating a Discussion with full reasoning context. [Y/n]"
Publishing is the default. If the user explicitly declines,
skip Discussion creation. If publishing fails, continue.
Optionally add to docs/backlog/queue.md with 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
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:executing-plans
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-scored
scope-guard:backlog-compared
scope-guard:budget-checked
scope-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 guards
superpowers:writing-plans - Planning workflow this validates
Every proposed feature has a Worthiness Score computed from the
formula (Business Value + Time Criticality + Risk Reduction) / (Complexity + Token Cost + Scope Drift) and a disposition:
implement (>2.0), discuss (1.0-2.0), or defer (<1.0)
Deferred items have a GitHub issue created before
scope-guard:decision-documented is marked complete; the issue
URL is recorded in the todo
Branch budget checked: if at 3 major features, a new feature
requires dropping an existing one, splitting to a new branch, or
an explicit written override with justification
Branch threshold zones checked (lines 1000/1500/2000, commits
15/25/30, days 3/7/7+); Yellow zone triggers a warning, Red zone
blocks without justification
