Nm Imbue Scope Guard

Pre-implementation scope control: evaluate feature necessity and enforce branch size limits

Security Scan

The skill's instructions broadly match its stated purpose (scoring features, checking branch size, and creating deferral records), but there are several coherence issues and operational risks—notably undocumented external tools/credentials, references to scripts that aren't bundled, and default auto-publishing of GitHub Discussions—that the user should review before installing or allowing autonomous use.

Purpose & Capability

The name/description (pre-implementation scope control, branch size limits) align with the SKILL.md: it scores features, checks backlog, enforces branch budgets, and documents deferrals via GitHub. Expectation to read repo files and run git checks is coherent. However, the skill's metadata declares no required binaries or credentials while the instructions clearly assume availability of git, gh (GitHub CLI), and python3 (and repository scripts). That mismatch is a design inconsistency to be aware of.

Instruction Scope

Instructions direct the agent to run git commands, inspect docs/backlog/queue.md, and create GitHub issues and Discussions (using gh CLI and GraphQL). They also call a local helper: python3 scripts/deferred_capture.py. Those actions are within the skill's purpose, but they will read repo contents and post potentially sensitive decision context to the remote GitHub repo by default (Discussion publishing is the default). The SKILL.md does not bundle the referenced script(s) nor declare the need for gh/gh auth: the agent may attempt operations that fail or (if credentials exist) create posts without clear prompts. The instructions are prescriptive about creating persistent external records (issues/discussions), which raises privacy/operational considerations.

Install Mechanism

This is an instruction-only skill with no install spec and no code files included in the bundle—low install risk. No network downloads or archive extraction are performed by the skill package itself.

Credentials

Manifest lists no required environment variables or credentials, yet the runtime instructions assume authenticated GitHub access (gh auth) and write permissions to create issues/discussions, plus local access to git and python. The lack of declared primary credential or required env variables is disproportionate to the operations described. If the agent has access to a GH token or gh CLI authenticated session, the skill can create persistent public artifacts in repos—this capability should be explicitly documented and constrained.

Persistence & Privilege

The skill is not marked always:true, which is appropriate. However, it instructs creating GitHub issues and publishing Discussions by default; because model invocation is allowed (disable-model-invocation: false), an autonomously-invoking agent with GH credentials could post content without explicit user approval. This combination increases blast radius and should be managed (e.g., require manual confirmation before issuing network writes).

What to consider before installing

Before installing or enabling this skill, check the following: 1) Ensure you run it in a repository context where creating GitHub issues/discussions is intended. The skill assumes git, gh (GitHub CLI), and python3 are available and that an authenticated gh session (or GH token) exists—yet none are declared. 2) Confirm the referenced helper script (scripts/deferred_capture.py) exists in your repo; if not, the automation will fail or behave unexpectedly. 3) Review the default behavior to publish Discussions (it's the default action); if you don't want automated public posting, change the workflow to require explicit confirmation or disable Discussion creation. 4) Limit the GitHub token scopes used by the agent (least privilege) and consider using a test/fork repo first to observe behavior. 5) If you plan to allow autonomous agent invocation, restrict or require approval for actions that create remote artifacts (issues/discussions). If these issues are acceptable and you run the skill interactively in a controlled repo with appropriate credentials and scripts present, the skill appears coherent with its purpose; if not, treat with caution.

Night Market Skill — ported from claude-night-market/imbue. For the full experience with agents, hooks, and commands, install the Claude Code plugin.

Building more than what is needed takes choices away from those who work here next. Scope-guard is humility and foresight: preserving freedom by building only what is earned.

Table 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:executing-plans
• 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:

1. Worthiness Scoring - Quantify value vs cost before building
2. Opportunity Cost - Compare against existing backlog
3. 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)

1. Check docs/backlog/queue.md for existing items
2. Compare Worthiness Scores
3. 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):
  1. Create GitHub issue immediately - See github-integration.md Steps 1-3
  2. Mark scope-guard:github-issue-created complete
  3. 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.
  4. 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
• 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:

1. List all proposed features/components
2. Score each with Worthiness formula
3. Defer items scoring < 1.0 to backlog
4. 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:

1. Verify all planned items have Worthiness > 1.0
2. Compare against backlog queue
3. Confirm within branch budget
4. Document any deferrals

Self-invoke prompt: "Before finalizing this plan, let me verify scope with scope-guard."

During superpowers:executing-plans

Periodically during execution:

1. Run threshold check: lines, files, commits, days
2. Warn if Yellow zone reached
3. 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:

1. scope-guard:worthiness-scored
2. scope-guard:backlog-compared
3. scope-guard:budget-checked
4. scope-guard:github-issue-created (MANDATORY if deferring - blocks step 5)
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
• imbue: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