capture

The user wants to capture: $ARGUMENTS

Interrogation mode. Before producing anything, resolve the mode:

• Explicit signal in the invocation is honored without asking. grill-me = --grill, "grill me", or "grill-me mode". standard = --standard, "standard", or "quick". Strip the signal from $ARGUMENTS and record the resolved mode.
• No explicit signal: ask via AskUserQuestion — one question, header "Mode", options Standard (recommended, listed first) and Grill me. Standard description: "Lightweight clarify — a restatement and at most one question, then proceed." Grill-me description: "Relentlessly walk the decision tree one question at a time, each with a recommended answer, self-answering from the codebase where possible." Use the user's choice.

Standard mode: proceed with the command's existing lightweight clarify (a restatement and at most one clarifying question) — do not ask the mode question again.

Grill-me mode: activate swe-workbench:workflow-grill and run its interrogation loop to completion (exit on shared understanding or when the user says "proceed"). Then thread the emitted ## Resolved decisions block into the command's normal artifact/delegation step below — the same way a ticket-context summary is prepended — and continue as in standard mode.

Delegate to the swe-workbench:product-manager subagent. Its response must deliver all of the following before any issue is filed:

1. Auth + repo detection. Run gh auth status, then gh repo view --json nameWithOwner,visibility. Surface the detected nameWithOwner in the preview as Filing into: <owner>/<repo>. Record the visibility: the redactor (step 6) runs on every draft unless visibility is affirmatively PRIVATE or INTERNAL, so a PUBLIC repo, a missing field and any other or unknown value all redact. If gh rejects the visibility field (an older gh), retry with --json nameWithOwner and treat the visibility as unknown. If either command otherwise fails, bail with a clear single-line message ("Repo detection failed: . Run gh repo view to diagnose.") and stop.

2. Restatement. One sentence in the user's domain language confirming the thought. If the thought is ambiguous, ask exactly one clarifying question before continuing.

3. Product framing — four lenses applied with brevity:

   • Problem. User pain or constraint, stated as the user's pain — not the feature.
   • Value. Who benefits and how. One "so-what" sentence.
   • Acceptance criteria. 2–4 bullets (Given/When/Then or simple bullets).
   • Impact / Effort (RICE-lite). Impact: S/M/L and Effort: S/M/L, one sentence each.

4. Template discovery. List .github/ISSUE_TEMPLATE/ filtered to *.md, skipping config.yml. Read each template's frontmatter and first ~20 body lines. Classify the thought into the closest-fit template with a one-sentence reason, or note "No issue templates found; using default body shape" when none exist.

5. Label discovery. Run gh label list --json name -q '.[].name' to get the repo's available labels. If the command fails or returns empty output, treat the label list as empty and proceed directly to step d (no match → omit --label). Otherwise select a label using this chain:

   a. Template frontmatter: if the chosen template has a labels: field and that value exists verbatim in the repo's label list, use it. b. Fallback — substring match (case-insensitive): if the frontmatter label is not present verbatim, pick the first repo label whose name case-insensitively contains (or is contained by) the template's value. c. No template chosen: map by commit-tag — [feat] → enhancement, [bug] → bug, [chore] → documentation — then apply the same chain against the repo's label list. If no commit-tag is recognisable in the user's input, proceed directly to step d. d. No match found: omit --label; record this so the preview can warn the user ("No matching label found; filing without label").