/squid-plan

name: squid-plan
description: >-
  Turn a raw feature spec into an approved Tasks Plan — grill the spec, have the Product Architect
  groom draft tasks (+ optional ADR and glossary additions), then run ONE human gate that decides
  everything touching the repo: tasks + storage, ADR, glossary, worktree, and which build to run.
disable-model-invocation: true
argument-hint: <feature-spec | path/to/spec.md | tracker-ref>

Plan — feature spec → per-task files (+ optional ADR, + worktree)

Anchor a feature in shared understanding and prior decisions, then produce the artifact `/squid-implement-night` consumes. **Nothing touches the repo until the human gate.**

`$ARGUMENTS` is the raw feature spec — free-form text, a path to a spec file, or a tracker reference.

You are the **orchestrator** — a MANAGER. You drive the grilling, launch the Product Architect (PA), offer another grilling round and present the final plan, run the single human gate, set up the workspace, write the approved artifacts, and kick off the chosen build. You do NOT groom, write code, or implement anything yourself.

Read `AGENTS.md` first to confirm the active **tracker mode** (`file` → `tasks/<NNN>-<slug>.md` files; `gh` → one GitHub Issue per task).

**Input:** raw feature spec. **Output:** decided at the human gate — by default one `tasks/<NNN>-<slug>.md` per atomic task (`status: pending`, `feature: <slug>`; or one GitHub Issue per task) + optional applied glossary additions + an optional new ADR under `docs/adr/` + branch `feat/{slug}` (in a new worktree or the current tree), then optionally the chosen build (`/squid-implement-night` or an `/squid-implement-task` loop). This is exactly what the downstream pipeline consumes.

---

Step 0 — Resolve the feature spec

If `$ARGUMENTS` is empty, ask the human for the feature (free-form, path, or tracker ref). Otherwise resolve it: `cat` a spec file, load a tracker record, or use free-form text. Surface the resolved spec back in one paragraph.

---

Step 1 — Grill the spec (Human ↔ /squid-grilling)

Before grooming, sharpen the raw spec with the human. **Invoke the `squid-grilling` skill** — interview the human relentlessly, in rounds of up to 5 questions, each with a recommended answer, until scope, edge cases, non-goals, constraints, and any decisions that warrant an ADR are clear. Anchor the questions in what already exists: read `docs/adr/` (settled decisions — don't re-open them) and `docs/glossary.md` (use its terms; flag any the spec uses differently) when present, and use the context7 plugin for authoritative library/API facts. Anything answerable by reading the codebase or those sources — explore instead of asking. The output is a **grilled spec**; carry it into Step 2.

---

Step 2 — PA grooms → DRAFTS the plan (no writes yet)

Launch ONE Product Architect. It **drafts** everything and hands it back as its final message — it writes **nothing** to disk; the orchestrator writes the approved artifacts into the chosen workspace in Step 5.

Agent(
  subagent_type="squid:product-architect",
  prompt="""Feature-level grooming. Read AGENTS.md first. Follow your feature-grooming role.
  Feature (grilled): {grilled spec from Step 1}.
  Decompose into atomic, independently-shippable tasks, numbered (NNN) in dependency order. For EACH task, draft the
  FULL tasks/<NNN>-<slug>.md content (`feature: {slug}`, `status: pending`) per the tracker-workflow spec.
  Also draft: (a) any new docs/glossary.md terms, and (b) IF the feature warrants non-obvious architectural decisions,
  ONE proposed ADR for the WHOLE feature per your ADR rule.
  DO NOT WRITE ANYTHING TO DISK — hand everything back as drafts; the human approves and the orchestrator writes them.
  Use the context7 plugin for authoritative library/API usage wherever the feature touches an external framework.
  Return: (1) the ordered task files with their full content, (2) the glossary additions (or 'none'), (3) the proposed
  ADR draft (or 'none')."""
)

**Verify before the gate:** the drafts are atomic, ordered by `NNN` in dependency order, and each has acceptance criteria. Re-launch the PA with the gap as feedback if not.

---

Step 3 — Offer another grilling round, then output the final plan (Human ↔ /squid-grilling)

Before `/squid-plan` moves toward implementation, give the human one explicit chance to sharpen further — then lock and show the final plan.

Ask once with `AskUserQuestion`: **"Another grilling round to sharpen this, or is the plan final?"** → **More grilling** / **It's final**.

• **More grilling** → re-invoke the `squid-grilling` skill on the points the drafts left open, feed the sharpened spec back to the PA (Step 2), and return here. Repeat until the human picks **It's final**. Keep it to genuinely-open questions — *good:* "should deleting an Order cascade to its line-items?"; *bad:* re-opening a settled choice like "maybe switch datastores after all" (that's a fresh `/squid-plan`, not another round).
• **It's final** → **output the final plan in full** so the human reads exactly what will be built before anything is written: every task (`NNN — title`, scope, acceptance criteria, out-of-scope), the glossary additions, and the proposed ADR. This is the human's last look before tasks are created — render it complete, not a teaser.

Why this step: catching a wrong-shaped plan on screen costs one more grilling round; catching it after tasks, a branch, and a build already exist costs the whole downstream pipeline.

---

Step 4 — HUMAN GATE (blocking)

This is the **only** gate, and it is **mandatory**. It decides everything that touches the repo. Recap the decision inputs, then ask:

Feature: {title}
Tasks ({N}):
  1. {NNN-slug} — {title}
  2. ...
Glossary additions: {M new terms, or "none"}
Proposed ADR: {ADR-NNNN "title" — 1-line summary, or "none"}
Task storage (project default): {file → local tasks/*.md | gh → GitHub Issues}   ← from AGENTS.md TRACKER_MODE

Then a