---
name: scorpio-intake
description: The Scorpio front door — turn a freeform description of a bug, feature, chore, or piece of work into one or more SCOPED tracker issues, ready for scorpio-ship / scorpio-loop. Use this BEFORE writing any code whenever the user describes something to build, fix, or change ("there's a bug where…", "we should add…", "can you make it so…", "I want…"). Captures + scopes + creates the issue(s) on approval, instead of jumping straight to implementation.
argument-hint: "[freeform description of the work, optional]"
---

# Scorpio Intake (the front door)

In a Scorpio-managed repo, work flows from **tracker issue → `scorpio-ship` → shipped**. The thing that
keeps that flow honest is that *every* piece of work starts as a **scoped issue in the tracker** — not as
an ad-hoc edit. This skill is the on-ramp: it takes whatever the user just described and turns it into one
or more scoped tracker issues, then hands off to the ship pipeline.

**This is a routing + capture skill. You do NOT implement anything here.** No code edits, no file writes to
source. Your job is: understand the work, scope it, create the issue(s) on approval, and point at the next
step.

## When this fires

Reach for this skill whenever the user *describes work* in conversation — a bug, a feature, a chore, a
refactor, a "wouldn't it be nice if…" — and there is **not already a scoped tracker issue** for it. The
default instinct ("they described a bug, let me go fix it") is exactly what this skill exists to interrupt.
Capture and scope first.

### The bypass (don't be annoying about it)

Intake-first is the default, **not a cage**. If the user signals they want a direct change — "just fix it",
"quick edit", "don't make an issue", "one-liner", a trivial typo/copy tweak — **skip intake** and route to
**`scorpio-edit`** (or make the change directly if truly trivial). Confirm, don't assume: when it's
ambiguous whether something deserves an issue, ask once (see Step 2) rather than forcing the heavyweight path.

## Procedure

### Step 1 — Resolve the tracker and echo it
Resolve `tracker.adapter` / `tracker.issueIdPattern` / `tracker.credentialEnv` from `scorpio.config.json`
per the standard resolution rule (explicit config → repo detection → ask). Issues are created **only**
through the tracker seam — `node scripts/tracker.mjs create …` — never a tracker-specific call. **Echo which
tracker you'll create issues in before doing anything that writes.** Creating tracker issues is an
outward-facing write — surface it. If the tracker can't be resolved, stop and ask; never guess it.

### Step 2 — Classify and confirm intent
From the description, decide the work type and the right depth:

| Signal | Work type | If requirements are genuinely unclear, delegate to |
|--------|-----------|-----------------------------------------------------|
| Broken / regressed behavior | **Bug** | `scorpio-bug-intake` |
| New capability / "add…" / "support…" | **Feature** | `scorpio-feature-intake` |
| Whole product / major module / "let's plan the app" | **Project** | `scorpio-project-intake` |
| Business goal / "we need to move metric X" | **Objective** | `scorpio-objective-intake` |
| Small mechanical change (rename, bump, copy) | **Chore** | *(scope inline; no interview)* |

Then **confirm intent in one short turn**, e.g.:
> "Sounds like a bug in checkout. Want me to **capture + scope it as a tracker issue** (then you can run
> `scorpio-ship`/`scorpio-loop`), or **just fix it directly**?"

- If they want it captured → continue.
- If they want it fixed directly → hand to **`scorpio-edit`** and stop.

Only run a full intake interview when the description is genuinely too thin to scope. If the user already
described it well, **do not interrogate them** — go straight to drafting (Step 4). Most descriptions need
zero or one clarifying question, not an interview.

### Step 3 — Split into one or more issues
One issue = one discrete, independently-shippable concern. If the description bundles several (e.g. "the
modal is broken **and** we should add keyboard nav **and** the copy is wrong"), split it into separate
issues so `scorpio-loop` can ship them one at a time. Keep each tight; resist scope creep. Note dependencies
between them (issue B depends on issue A) so the loop orders them correctly.

### Step 4 — Draft each issue so it is SCOPED
"Scoped" in Scorpio means the issue description carries **a clear plan + acceptance criteria** — enough that
`scorpio-ship`'s scope gate passes and an implementer knows what "done" means. Draft each issue body:

- **Bug**: summary · observed vs. expected behavior · reproduction steps · suspected area (if known) ·
  **done criteria** (how we know it's fixed).
- **Feature/chore**: summary · what it does + who/where · the proposed approach at a high level ·
  **acceptance criteria** (specific, testable checkboxes) · constraints.

Pick a priority (1 urgent → 4 low) from the user's signal; ask if unclear. For a complex feature whose
*design* needs codebase investigation, it's fine to leave the deep design to `scorpio-feature-plan` (the
ship scope gate will invoke it) — but the issue must still state intent + acceptance criteria so it isn't a
vague stub. **Never create a vague issue.**

### Step 5 — Propose, do NOT create yet
Present the proposed issue set as a short table — title, type, priority, one-line scope, and any
dependencies — plus the count. Then **ask the user to confirm before creating anything.** Honor a dry-run:
if they only wanted the preview, stop here. Quickly sanity-check the open backlog
(`node scripts/tracker.mjs list`) for an obvious existing duplicate and flag it rather than creating a twin.

### Step 6 — Create on confirmation
Only after explicit approval, create each issue in priority order through the seam:

```
node scripts/tracker.mjs create --title "<title>" --priority <N> --desc "<scoped body>"
```

Capture each printed issue id/url.

### Step 7 — Hand off
Summarize the issue id(s) created (with priorities) and point at the next step:
- One issue → **"Run `scorpio-ship <ID>` to take it scoped → shipped."**
- Several → **"Run `scorpio-loop` to prioritize and ship them one at a time."**

## Guardrails
- **Never implement here.** No source edits, no commits. Capture + scope + create + hand off only.
- **Never create issues without explicit user confirmation** — always propose first; honor a dry-run.
- **Confirm intent, don't hijack.** Offer the capture-vs-fix choice; respect the bypass to `scorpio-edit`.
- **One concern per issue.** Split bundles; note dependencies; keep scope tight.
- **Never create a vague issue** — plan + acceptance criteria or it isn't scoped.
- **Resolve the tracker, never guess it.** If it can't be resolved, stop and ask.

## Skill chain

```
user describes work
    → scorpio-intake (classify · confirm · scope · [user approves] · tracker.create)
        ├─ (unclear requirements) → scorpio-bug-intake / scorpio-feature-intake / scorpio-project-intake / scorpio-objective-intake
        └─ (just fix it)          → scorpio-edit
    → scorpio-ship <ID>   (one issue)   or   scorpio-loop   (several)
```

See `scorpio-mode` for the session-level "think in Scorpio terms" posture that routes here, and
`SKILLS-ECOSYSTEM.md` for the full pipeline map.