strategy-gate

name	strategy-gate
description	Strategy Gate Skill: Validates demand, assesses alternatives, scores impact before tickets enter planning. MANDATORY TRIGGERS: strategy, validate, should we build, worth building, prioritize, demand, gate, go no-go, evaluate.
argument-hint	<ticket ID to evaluate, or omit for batch backlog evaluation>

Bobby Strategy Skill

Pre-planning gate that validates whether a ticket is worth building. Evaluates demand evidence, status quo alternatives, scope optimization, and impact scoring. Makes autonomous approve/defer/kill decisions.

Before Starting

1. Check learnings — Read .claude/skills/bobby-strategy/learnings.md + .claude/skills/bobby-strategy/learnings.local.md
2. Read the ticket — title, description, acceptance criteria, priority, type, area
3. Survey the backlog — bobby ticket list backlog --sort priority to understand relative positioning
4. Check in-flight work — bobby ticket list planning, bobby ticket list building to see current capacity

Investigation First

<investigation_rules> Before forming any strategic opinion:

• Read the ticket's full description, not just the title
• Check for existing tickets that overlap or duplicate this one: scan the backlog and in-flight stages
• If the ticket references a user need, look for evidence (bug reports, comments, related tickets)
• If the ticket has a parent epic, read the epic's ticket.md and any existing plan.md
• Read the project's README.md or CLAUDE.md to understand the product's current state and priorities
• Do not evaluate implementation feasibility — that's bobby-plan's job
• Do not design solutions — evaluate the problem's worthiness </investigation_rules>

Evaluation Framework

Run these six assessments sequentially. Each builds on the prior.

1. Demand Validation

<demand_validation> Core question: Is there real evidence someone needs this?

Evaluate:

• Behavioral evidence: Bug reports, support requests, workaround usage, repeated asks in comments
• Specificity test: Can you name a specific user or scenario that needs this? "Users want" is vague; "Users who try to export CSVs with >1000 rows get a timeout" is specific
• Interest vs. demand: Hypothetical interest ("it would be nice") is NOT demand. Demand requires evidence of pain or blocked workflows
• Frequency: Is this a daily problem, weekly annoyance, or rare edge case?

Score 1-5:

• 5: Multiple pieces of behavioral evidence, specific users/scenarios, frequent occurrence
• 4: Clear evidence of one specific pain point, moderate frequency
• 3: Reasonable inference of need but no direct evidence
• 2: Speculative — "users might want this"
• 1: No evidence of demand, hypothetical only </demand_validation>

2. Status Quo Analysis

<status_quo> Core question: What happens if we do nothing?

Evaluate:

• Current workaround: How do users solve this today? Manual process? Third-party tool? They just don't?
• Workaround cost: How painful is the workaround? (Time, error-prone, requires expertise?)
• Degradation trajectory: Is the problem getting worse over time, stable, or improving?
• "Do nothing" outcome: If we wait 6 months, what happens? Users leave? Nothing? Problem solves itself?

Score 1-5:

• 5: No workaround exists, problem is actively worsening, users are blocked
• 4: Workaround exists but is painful, problem is growing
• 3: Workaround is tolerable, problem is stable
• 2: Good workaround exists, problem is minor
• 1: Problem is trivial or self-resolving </status_quo>

3. Scope Assessment

<scope_assessment> Core question: What is the narrowest version that delivers value?

Evaluate:

• Current scope: What does the ticket as written propose?
• Minimal viable version: What is the absolute smallest thing that solves the core problem? Can we cut 50% of the scope and still deliver value?
• Scope creep signals: Does the ticket mix multiple concerns? Does it say "and also" more than once?
• Wedge opportunity: Is there a tiny entry point that validates the approach before investing fully?

If the ticket's scope is too broad, note the recommended reduction in the strategy brief.

Score 1-5:

• 5: Ticket is already narrowly scoped, single concern, clear boundaries
• 4: Minor scope trimming possible, generally focused
• 3: Moderate scope reduction needed, mixed concerns
• 2: Significant scope creep, multiple features in one ticket
• 1: Sprawling scope, needs epic breakdown before evaluation </scope_assessment>

4. Alternative Exploration

**Core question:** Are there simpler ways to achieve the same outcome?

Generate 2-3 alternatives (one MUST be "minimal viable"):

#	Approach	Effort	Value	Trade-off
1	As proposed	[est]	[what it delivers]	[what it costs]
2	Minimal viable	[est]	[subset of value]	[what's lost]
3	Alternative	[est]	[different angle]	[different trade-off]

If the minimal viable alternative delivers 80%+ of the value at 30% or less effort, recommend scope reduction rather than full implementation.

5. Impact Scoring

<impact_scoring> Weighted scorecard:

Dimension	Weight	Score (1-5)	Weighted
Demand	3x	{from step 1}	{score x 3}
Urgency (Status Quo)	2x	{from step 2}	{score x 2}
Effort-to-Value	2x	{derived}	{score x 2}
Risk	1x	{assessed}	{score x 1}
Total			{sum}/40

Effort-to-Value scoring:

• 5: Low effort, high value (quick win)
• 4: Moderate effort, high value
• 3: Proportional effort to value
• 2: High effort, moderate value
• 1: High effort, low value

Risk scoring (inverted — lower risk = higher score):

• 5: Low risk — well-understood domain, clear implementation path
• 4: Minor risk — some unknowns but manageable
• 3: Moderate risk — significant unknowns or dependencies
• 2: High risk — major unknowns, external dependencies
• 1: Very high risk — speculative, architectural changes, data migration

Thresholds:

• 28-40: Strong approve — move to planning
• 20-27: Conditional — approve with scope notes, or defer if backlog is full
• 12-19: Weak — defer with specific revisit conditions
• 8-11: Kill — archive with explanation </impact_scoring>

6. Go/No-Go Decision

Based on the total score and the qualitative analysis, make ONE of three decisions:

APPROVE (score 28+, or 20-27 with strong demand): Strategy brief format:

## Strategy Brief — {ticket ID}

**Decision:** APPROVED
**Score:** {total}/40 (Demand: {d}/5, Urgency: {u}/5, Effort-Value: {ev}/5, Risk: {r}/5)

### Why Build This
{1-2 sentences on the core justification}

### Recommended Scope
{If scope reduction recommended, describe the narrower version. Otherwise: "As proposed."}

### Key Risks
{Top 1-2 risks the planning agent should address}

### Alternatives Considered
{Brief summary of alternatives and why the recommended approach won}

DEFER (score 12-27 without strong demand, or when backlog priorities are higher):

• The ticket has some merit but isn't ready or isn't the highest priority right now
• Include specific conditions for revisiting (e.g., "Revisit when X feature ships" or "Revisit if 3+ users report this")

KILL (score 8-11, or ticket is duplicate/obsolete):

• The ticket does not justify the effort, has no demand evidence, or is obsolete
• Archive with clear explanation so it can be resurrected if conditions change

Confidence Gate

<confidence_gate> Only make decisions with 7/10 or higher confidence. For each evaluation:

1. State the decision (approve/defer/kill)
2. Show the complete scorecard
3. Rate your confidence 1-10
4. If confidence is below 7: DEFER (not kill) and note what information would raise confidence

Do NOT:

• Approve tickets with vague descriptions just because the title sounds good
• Kill tickets because you can't find demand evidence — absence of evidence is not evidence of absence. Defer instead.
• Let a single high score override multiple low scores — the weighted total is the decision, not any single dimension
• Evaluate implementation feasibility — that's bobby-plan's job </confidence_gate>

Batch Mode

When evaluating multiple backlog tickets (no specific ID provided):

1. Run bobby ticket list backlog --sort priority to get all backlog tickets
2. Evaluate each ticket through the full framework above
3. Rank all tickets by total score
4. Apply decisions based on thresholds
5. Produce a batch summary:

## Strategy Review — Batch

| Ticket | Title | Score | Decision | Key Reason |
|--------|-------|-------|----------|------------|
| {ID} | {title} | {n}/40 | APPROVE/DEFER/KILL | {one-line reason} |

### Approved ({n} tickets)
{Recommended planning order based on dependencies and priority}

### Deferred ({n} tickets)
{Revisit conditions for each}

### Killed ({n} tickets)
{Archived with reasons}

Bobby Commands Reference

# Read ticket
cat .bobby/tickets/{ID}*/ticket.md

# View backlog
bobby ticket list backlog --sort priority

# View in-flight work
bobby ticket list planning
bobby ticket list building

# Approve to planning
bobby ticket move {ID} plan

# Add strategy comment
bobby ticket comment {ID} --by bobby-strategy "STRATEGY: {brief}"

# Archive (kill)
bobby ticket archive {ID}

# Record learning
bobby learn bobby-strategy "pattern" "description"

Feature Areas

targets | dashboard | audit | tickets | packs | templates | cli

---

Project overrides

If .claude/skills/bobby-strategy/SKILL.local.md exists, read it and follow it. It holds this project's own instructions for this skill and wins wherever it conflicts with anything above.

SKILL.md is shipped by Bobby and is replaced on every upgrade — edits here are lost. SKILL.local.md is yours and is never overwritten.