---
name: scorpio-advisor-intake
description: Turn an scorpio-advisor-synthesize findings report into prioritized tracker issues that scorpio-loop can drain. Reads the synthesis sidecar, maps each actionable finding to a proposed tracker issue, shows the set for approval, and creates them (via the tracker seam) only on confirmation. Use after scorpio-advisor-synthesize to feed the advisor audit into the ship backlog.
argument-hint: "[synthesis sidecar path or date folder]"
---

# Advisor Report Intake

You convert the output of **scorpio-advisor-synthesize** into actionable backlog. The advisor skills audit the
running app; `scorpio-advisor-synthesize` reconciles their findings into a ranked `findings[]` sidecar. This
skill turns those findings into **tracker issues**, so `scorpio-loop` — which selects work purely from
the tracker — can prioritize and ship them like any other issue. You do not plan, design, or implement;
you map findings to issues and create them **only after the user approves**.

This is the advisor → ship-lifecycle edge: `advisor-* → scorpio-advisor-synthesize → scorpio-advisor-intake →
tracker → scorpio-loop → scorpio-ship`.

## Prerequisites

1. **A synthesis sidecar exists** — `{docs.advisorReports}/{date}/synthesis-{HHmm}.json` (produced by
   `scorpio-advisor-synthesize`). If `$ARGUMENTS` names a sidecar path or a date folder, use it; otherwise use
   the most recent `synthesis-*.json` under `{docs.advisorReports}`. If none exists, stop and tell the
   user to run `scorpio-advisor-synthesize` first.
2. **The tracker is resolved** — Resolve `tracker.adapter` / `tracker.issueIdPattern` /
   `tracker.credentialEnv` per the resolution rule (explicit config → repo detection → ask). Issues are
   created through the tracker seam (`node scripts/tracker.mjs create …`), never a tracker-specific call.

## Procedure

### Step 1 — Resolve and echo
Resolve the config values above and the report dir, and **echo them to the user before doing anything**
that writes: which tracker/adapter, which synthesis sidecar you're reading. Creating issues is an
outward-facing write to the tracker — surface it.

### Step 2 — Load and validate the findings
Read the sidecar and confirm it has a `findings` array. Each finding has: `id` (`S-###`), `title`,
`severity`, `effort`, `recommendation`, optional `rank`, `deferred`, `source_skills[]`. If the file is
malformed or `findings` is empty, report that and stop. Also read the sibling `synthesis-{HHmm}.md` for
context (cross-impact, rationale) to enrich issue bodies.

### Step 3 — Select actionable findings
- **Exclude** `deferred: true` findings by default (they are intentionally not-now). Include them only
  if the user passes `--include-deferred`.
- Order by `rank` ascending when present, else by severity (Critical → Low).

### Step 4 — Map each finding to a proposed issue
| Finding field | Tracker issue field |
|---------------|---------------------|
| `title` | issue title (prefix with `[advisor]` so seeded issues are recognizable) |
| `severity` | priority — **critical → 1 (urgent), high → 2, medium → 3, low → 4** (match case-insensitively; scorpio-advisor-synthesize emits lowercase severities. The seam's priority convention; the adapter normalizes for non-Linear trackers. Map anything unrecognized to 3/medium and note it.) |
| `recommendation` + synthesis context | issue description |
| `id` (`S-###`) + source report | a marker line in the body, e.g. `Source: scorpio-advisor-synthesize S-007 ({date})`, used for dedup |
| `source_skills[]` | mention which advisors flagged it |

Build the description so a future implementer has what they need: the recommendation, why it matters
(cross-impact from the synthesis), severity/effort, and the `Source:` marker.

### Step 5 — Dedup against the tracker
List current open issues (`node scripts/tracker.mjs list`) and **skip any finding whose `Source:`
marker (`S-###` + synthesis date) already appears** in an existing issue's title/body — so re-running
intake on the same synthesis doesn't create duplicates. Report what you skipped and why.

### Step 6 — Propose (do NOT create yet)
Present the full proposed issue set as a table — title, mapped priority, source `S-###`, one-line
description — plus the count and any skipped (deferred / duplicate) findings. Then **ask the user to
confirm** before creating anything. Support a dry-run: if the user only wants the preview, stop here.

### Step 7 — Create on confirmation
Only after explicit approval, create each proposed issue:

```
node scripts/tracker.mjs create --title "[advisor] <title>" --priority <N> --desc "<body with Source: marker>"
```

Create them in priority order. Capture each printed issue id/url.

### Step 8 — Report and hand off
Summarize: the issue ids created (with their priorities), what was skipped, and the next step —
**"Run `scorpio-loop` to prioritize and ship the new backlog,"** since scorpio-loop will now see these
issues in the tracker with no changes on its side.

## Guardrails
- **Never create issues without explicit user confirmation** — creating tracker issues is an
  outward-facing write. Always propose first; honor a dry-run.
- **Skip `deferred` findings** unless `--include-deferred` is given.
- **Dedup by the `S-###` + synthesis-date marker** so re-runs are idempotent.
- **Don't plan or implement** — map findings to issues only. The shipping happens downstream via
  `scorpio-loop` → `scorpio-ship`.
- If the tracker can't be resolved, stop and ask — never guess the tracker.

## Skill Chain

```
advisor-{a11y,growth,monetization,trust,ux} → scorpio-advisor-synthesize → synthesis-*.json
        → scorpio-advisor-intake → [user approves] → tracker.create
        → scorpio-loop (prioritizes from tracker) → scorpio-ship
```