new command: /gh-issue-driven:propose — phase-0 issue capture from session context

[JFK]

Motivation

Today the workflow assumes the issue already exists: start → implement → ship. But the moment you most want to file a well-shaped issue is mid-session, when the model already has the richest context — recently touched files, failing tests, design dead-ends, the conversation that led here. That context is currently wasted: either the user task-switches to file an issue manually, or the insight is lost.

A new phase-0 command — propose — would close this loop. The plugin's name is "issue-driven", and right now we can only consume issues, not capture them.

Proposed shape

/gh-issue-driven:propose [--from-session | --from-failure | <free text>]

  1. Collect context: recent file edits, git diff, last test failure, conversation summary
  2. Dedup check (MANDATORY, not optional):
       - gh issue list --search "<keywords>" --state all
       - kagura-memory recall for similar past issues
       - if a near-duplicate exists, surface it and abort unless --force
  3. Single review pass via /claude-c-suite:ask (auto-router)
       - cheap, single-lens, picks the right CxO automatically
       - NOT a full /ceo cascade — issue drafts are lightweight
  4. Enrichment via /claude-c-suite:pm
       - suggests priority, milestone, labels (NOT a pass/fail gate)
  5. Print draft to terminal — user edits — explicit confirmation required
  6. gh issue create → return issue number
       - issue number can then be passed straight to /gh-issue-driven:start

The flow becomes a clean three-act: propose → start → ship, with the plugin name fully earned.

Design questions to settle before implementation

1. Verdict semantics don't transfer cleanly

gate1/gate2 review work products (designs, code). Reviewing an issue draft is a different beast — what does red mean? "Don't file this"?

Proposal: introduce a propose-specific token set on the same ## Verdict: line:

• ## Verdict: file — draft is good, ready to create
• ## Verdict: needs-edit — re-roll with reviewer's suggestions
• ## Verdict: duplicate — existing issue covers this; abort
• ## Verdict: out-of-scope — not appropriate for this repo

These extend the existing structured-line contract (#13) rather than fighting it.

2. /pm as enrichment, not gate

/claude-c-suite:pm is one CxO. For bugs you want /cso or /qa-lead; for UX /cdo. So /ask (auto-router) does the review, and /pm runs after purely as a labeling/prioritization helper. Pinning the gate to /pm would narrow it artificially.

3. Dedup must be first-class

If dedup is optional, the first power user will paper the repo with duplicates within a week. It needs to be a hard step in the pipeline, with --force as the only escape hatch and a warning printed.

4. Never autonomous

Unlike the Copilot loop in ship, issue creation is socially expensive to revert (notifications, watchers, history). Default behavior must be: print draft → wait for user edit → require explicit "create" confirmation. No "autopilot" flag in v0.2.

5. State file location

gate1/gate2 state is keyed by branch name. propose runs before any branch exists. Suggested layout:

~/.claude/cache/gh-issue-driven/proposals/<timestamp>-<slug>.json

Cleaned up on successful gh issue create, retained on abort for resume.

6. Session context boundary

--from-session needs a clear definition of what "session" means. Options:

• Last N tool calls in current Claude Code conversation (hard to access reliably)
• git diff + recent file timestamps (deterministic, tool-friendly)
• Explicit user-provided summary block

Probably (b) + (c), with (a) as best-effort.

Why this is its own issue, not a sub-task of another

This expands the plugin's surface area meaningfully. It needs:

• a new command file under commands/
• a new state-file schema
• new Verdict tokens (extending feat: structured ## Verdict: <token> parser contract (#1) #13's contract)
• doctor + status integration
• README and CONTRIBUTING updates
• dogfooding (this very issue could have been the first dogfood run)

That deserves design discussion in the open before any code lands.

Out of scope (for this issue)

• Multi-issue batch capture
• Auto-linking to PRs
• Cross-repo proposals
• Any "autonomous filer" mode

Acceptance for the design discussion

Close this issue when:

1. We've decided whether propose belongs in v0.2 or later
2. The Verdict token extension is agreed (or rejected in favor of reusing green/yellow/red)
3. The dedup-mandatory stance is confirmed
4. State-file layout is approved
5. A follow-up implementation issue is opened (or this one is converted)

[JFK]

Label maintenance scope (added during 2026-04-10 dogfooding session)

The /propose command should include label maintenance as part of the issue creation workflow:

1. When composing a new issue, suggest appropriate labels based on the issue content (bug, enhancement, docs, security, tech-debt, copilot, dx, i18n, needs-design, dogfooding, tests)
2. If a suggested label doesn't exist in the repo, create it via gh label create with a sensible color before applying
3. Apply the labels to the newly created issue via gh issue edit --add-label

This makes the label taxonomy grow organically as issues are filed, rather than requiring a separate label maintenance pass. The /gh-issue-driven:tag skill (#28) reads these labels at release time to group changes in the release notes.

Why this belongs in /propose, not in a standalone /label skill

Labels are part of the issue lifecycle, not a separate workflow. When you're proposing an issue, you already have the context to pick the right labels. A standalone label skill would require re-reading the issue after creation, which is redundant.

Initial label taxonomy (to be created by /propose on first use)

Label	Color	When to apply
tech-debt	#FBCA04	Architectural follow-ups, refactoring debt
copilot	#1D76DB	Copilot loop / review related
dx	#0E8A16	Developer experience improvements
i18n	#D4C5F9	Internationalization / localization
needs-design	#E99695	Issues requiring design discussion before implementation
dogfooding	#F9D0C4	Issues discovered during dogfooding sessions

Existing GitHub default labels (bug, enhancement, documentation, security, tests, etc.) are kept as-is.

Caught during

PR #24 dogfooding session (2026-04-10). The user observed that label maintenance should be integrated into the workflow skills (/propose for creation, /tag for reading), not done as a standalone cleanup pass.