frame

---

name: frame argument-hint: '["idea" | --issue ]' description: Problem framing — capture problem, constraints, scope, tier. Triggers: "frame" | "frame this" | "what's the problem" | "define the problem" | "scope this out" | "define the scope" | "what are we solving" | "help me think through this problem" | "problem statement". version: 0.4.0 allowed-tools: Bash, Read, Write, Edit, Glob, Grep, ToolSearch

Frame

Success

I := φ written ∧ status: approved V := cat artifacts/frames/{N}-{slug}-frame.md | head -10 | grep "status: approved"

Let: φ := artifacts/frames/{N}-{slug}-frame.md (∃N) ∨ artifacts/frames/{slug}-frame.md (frame-only) N := issue number (∅ if free text) τ := tier ∈ {S, F-lite, F-full} AQ := present choice, wait for user reply

idea | issue → approved frame doc. Interview → detect τ → write φ → user approves. Standalone-safe: callable without /dev. Output consumed by /analyze, /spec, /dev.

Entry

/frame "text"       → seed from free text
/frame --issue N    → seed from GitHub issue title + body

Pipeline

Step	ID	Required	Verifies via	Notes
0	parse	✓	gh issue view N → JSON	—
1	interview	—	—	3–5 Q max
1b	premise	✓	3 fields non-empty	gate — blocks Step 2
2	tier	✓	τ ∈ frontmatter	—
3	write	✓	φ ∃	—
4	approval	✓	status: approved	gate

Pre-flight

Success: φ written ∧ status: approved Evidence: ls artifacts/frames/ after execution Steps: parse → interview → premise-gate → tier → write → approval ¬clear → STOP + ask: "What problem are you solving?"

Step 0 — Parse + Seed

--issue N →

gh issue view N --json number,title,body,labels

Extract: title, body, labels → seed context (S/M/L/XL label → τ hint). Free text → use verbatim as seed.

Derive slug: lowercase, kebab-case, ≤5 words.

Check ∃ φ:

# glob artifacts/frames/*{slug}*

∃ φ ∧ status: approved → AQ: Use existing (→ Step 4) | Re-frame (→ Step 1, fresh). ∃ φ ∧ status: draft → AQ: Continue draft (→ Step 3) | Start fresh (→ Step 1).

Step 1 — Interview

3–5 questions max. Skip answers clear from seed. Group into 1–2 AQ calls.

#	Question	Skip if
1	What is the problem/pain? What triggers this?	Issue body has clear problem
2	Who is affected? Primary + secondary users.	Issue body names users
3	What constraints apply? (time, tech, dependencies)	Labels or body imply these
4	What is explicitly out of scope?	Scope already narrow
5	Related work, prior attempts, adjacent issues?	∅ context → optional

¬ask all 5 if seed is rich — ask only what's missing.

Step 1b — Premise-Validity Gate

Gate: cannot proceed to Step 2 without all 3 fields answered.

Capture in a single AQ (present all 3 together):

Field	Prompt	Requirement
success_in_6mo	"What does success look like in 6 months?"	Concrete, observable outcome — ¬vague ("things are better")
failure_in_6mo	"What does failure look like in 6 months?"	Must be falsifiable — a condition you could actually observe ∧ decide to abort
simplest_alternative	"What's the simplest version that would meet the goal — and why isn't it enough?"	Forces explicit comparison; the "why not" is required, ¬optional

Evaluation rules:

• failure_in_6mo falsifiability rule: must reference a measurable outcome (number, threshold, or boolean state) AND a time horizon. Vibes-only failure modes are rejected.
• failure_in_6mo ¬falsifiable (e.g. "people aren't happy") → reject, re-ask. Example of falsifiable: "DEBT count stays flat or rises despite 3 sprint cycles." Example of non-falsifiable: "the team doesn't feel better."
• simplest_alternative answer omits the "why not" half → re-ask: "You described the simpler version — why won't it be enough?"
• Any field empty or answered with ≤5 words → treat as unanswered, re-ask.

Abort signal: if the user answers failure_in_6mo with a description that matches "we'd still have the problem but with extra bookkeeping" (i.e. the initiative measures proxy metrics, ¬the underlying issue) → surface: "This failure mode suggests the premise may be invalid. Do you want to reframe the problem or abort?" AQ: Reframe | Abort.

Canonical proxy-metric patterns (LLM anchors — any of these triggers the abort signal):

• "compliance count stays the same / unchanged"
• "annotation density doesn't move"
• "ticket-close rate doesn't improve"
• "dashboard stays red / metric won't budge"
• "we'd still have the underlying problem but with extra bookkeeping"

Origin: pattern surfaced by Roxabi/lyra#1162 — quality-debt annotation infrastructure (~1100 LOC + 6 registry files) where the ratchet measured bookkeeping compliance, not code quality. A falsification check at /frame would have caught this.

Step 2 — Tier Detection

Auto-detect τ from complexity signals:

Signal	Infers
≤3 files, single domain, ¬new arch	S
Clear scope, single domain, ¬unknowns	F-lite
Multiple domains ∨ new patterns ∨ unknowns ∨ XL label	F-full
Issue label S ∨ XS	S
Issue label M	F-lite
Issue label L ∨ XL	F-full

See tier-classification.md for canonical rules.

AQ: Confirm {τ} | Override → S | Override → F-lite | Override → F-full

Step 3 — Write Frame Doc

Write φ with status: draft:

---
title: {title}
issue: {N | null}
status: draft
tier: {τ}
date: {YYYY-MM-DD}
---

## Problem

{1–3 paragraphs: what, why now, observable impact}

## Who

- **Primary:** {user + their workflow}
- **Secondary:** {other affected parties if ∃}

## Constraints

- {technical / time / dependency constraints as bullets}

## Out of Scope

- {explicit non-goals as bullets}

## Premise Validity

**Required — populated from Step 1b. ¬leave blank.**

**Success in 6 months:** {concrete, observable outcome}

**Failure in 6 months:** {falsifiable condition — observable ∧ actionable}

**Simplest alternative:** {minimal version that meets the goal}
**Why not simplest:** {explicit reason the simpler path is insufficient}

## Complexity

**Tier: {τ}** — {1-sentence rationale}

{Signals observed: bullets from Step 2 detection}

Step 4 — User Approval

Present summary: problem statement, τ, key constraints, scope boundary. AQ: Approve | Revise (specify what to change).

Revise → apply edits inline → re-present → loop until Approve. Approve → update frontmatter status: approved via Edit.

Completion

φ written with status: approved.

Commit: git add artifacts/frames/{N}-{slug}-frame.md + commit per CLAUDE.md Rule 5.

∃ N →

bun ${CLAUDE_PLUGIN_ROOT}/skills/issue-triage/triage.ts set N --status Analysis

Inform: "Frame approved. Run /dev #N to continue, or /analyze --issue N for deep technical exploration."

Edge Cases

• Free text ∧ ¬clear slug → derive from first 4 nouns/verbs. AQ to confirm if ambiguous.
• Issue ¬exists (gh 404) → proceed in free-text mode using title as seed.
• Tier contested (signals split evenly) → default to higher τ; note: "Defaulted to {τ} — downgrade if scope narrows."
• User approves then requests major change → reset status: draft, revise, re-approve.

Chain Position

• Phase: Frame
• Predecessor: /issue-triage (or free-text entry)
• Successor: /analyze (F-full) ∨ /spec (F-lite)
• Class: gate (user approval of frame artifact required)

Task Integration

• /dev owns the dev-pipeline task lifecycle externally
• This skill does NOT update its own dev-pipeline task
• Sub-tasks created: none

Exit

• Approved via /dev: write artifact with status: approved, commit, return silently. ¬ask "proceed to /analyze?". /dev re-scans and auto-chains to successor in the same turn.
• Approved standalone: print one line: Approved. Next: /analyze --issue N (F-full) or /spec --issue N (F-lite). Stop.
• Modify requested: loop in-skill, re-present.
• Rejected/aborted: return → /dev marks task cancelled.

$ARGUMENTS