/intake

name: intake
description: "Pre-planning ticket ingestion. Given a ticket ID or URL, reads the full ticket via MCP or CLI, follows all referenced links (Notion, Figma, GitHub, articles, etc.) using parallel subagents, synthesises a context brief, grounds it in the actual codebase via /flagrare:codebase-explore, then asks codebase-informed clarifying questions before handing off to /flagrare:atdd-plan. Works with Linear, Jira, Asana, Shortcut, Trello."

Intake

Turn a ticket reference into a planning-ready context brief before `/flagrare:atdd-plan` runs. The goal: **every relevant fact is on the table and every ambiguity is resolved before a single line of implementation is planned**.

---

Lock the goal first (anti-stall): do this before Step 0

**Hard requirement.** Before any other tool call, you (the executing model) MUST call `/goal` yourself, unless you were invoked through `/flagrare:work-prep` (see the skip rule below). This is not a suggestion to the user.

**Why:** intake's most common failure is stopping after it emits the context brief and never reaching the clarifying questions. Emitting a large artifact reads as "turn complete," and the only forcing function downstream (the `AskUserQuestion` call in Step 5) sits two steps past that natural stop. A `/goal` is a session-scoped Stop-hook: after every turn a fast evaluator checks your condition against the conversation and, if unmet, makes you continue instead of yielding. Set it *before* the brief exists, so it is already holding you in place when you emit it. (Grounded in [`docs/research/2026-06-11-claude-code-goal-anti-stall.md`](../../../../docs/research/2026-06-11-claude-code-goal-anti-stall.md).)

Call `/goal` with a condition phrased as something your own output demonstrates, the evaluator cannot run tools or read files, it only judges what you have surfaced in the conversation:

> The ticket and every referenced link have been read; a codebase-grounded context brief has been produced (with `## Codebase Findings` populated); the 3-5 most blocking clarifying questions have been asked via the `AskUserQuestion` tool and answered (or the brief had no blocking ambiguity and a short overview was presented instead); and either `/flagrare:atdd-plan` has been invoked with the brief as input, or the user has explicitly chosen "Stop here". Stop after 12 turns if not met.

After setting the goal, create a Todo list (TodoWrite), one item per remaining step (read ticket, follow references, synthesise brief, ground in codebase, ask questions, hand off). The todo list tracks coverage; the goal prevents the harness from letting you stop. Both are required.

**Skip rule (nested under work-prep):** if the args passed to this skill start with `[work-prep]`, do NOT call `/goal`, `/flagrare:work-prep` already set a session-spanning goal, and only one goal can be active per session (a second would silently replace the first). Still create the Todo list.

**If `/goal` is unavailable** (it reports the workspace is untrusted, or `disableAllHooks` / `allowManagedHooksOnly` is set): proceed without it, but treat the no-yield notes in Steps 4-5 as mandatory rather than belt-and-suspenders.

---

Step 0: Inventory available tools

Before anything else, check what tools and MCPs are available in this session. List every MCP whose name contains any of: `linear`, `jira`, `asana`, `shortcut`, `trello`, `notion`, `figma`, `drive`, `github`, `gitlab`, `confluence`, `browser`, `playwright`, `puppeteer`, `fetch`, `web`, `obsidian`.

Build a capability map:

available MCPs:   [list every matched tool]
available CLIs:   run `which linear jira shortcut gh glab notion 2>/dev/null`, note which exist
browser tools:    [any MCP or tool that can load a URL with JS/auth, playwright, puppeteer, browser MCP]
file system:      [local Obsidian vault paths if known]

Use this map to pick the best tool for every fetch in Steps 2-3. A browser/automation MCP beats WebFetch for pages behind login. A first-party MCP beats a browser tool. An authenticated CLI beats an unauthenticated API call.

---

Step 1: Parse the input

Accept any of:

• A bare ticket ID: `INT-42`, `ch12345`, `PROJ-99`
• A full URL: `https://linear.app/…`, `https://company.atlassian.net/…`
• A plain-text description pasted inline, treat as the ticket body directly, skip Steps 2-3

Identify the platform:

| Signal | Platform | |---|---| | `linear.app` URL or `[A-Z]{2,}-[0-9]+` | Linear | | `atlassian.net/jira` URL | Jira | | `app.asana.com` URL | Asana | | `app.shortcut.com` URL or `ch[0-9]+` | Shortcut | | `trello.com` URL | Trello |

If the platform is ambiguous, ask before proceeding.

---

Step 2: Read the ticket

**When to call directly vs. spawn a subagent:** If the platform MCP is available in your session (e.g. you can call `mcp__jira__getIssue` yourself), call it directly -- there is no benefit to adding a subagent layer for a single tool call you already have access to. The subagent path exists for two cases: (1) the ticket has a large comment history that would bloat your context, or (2) the MCP is unavailable and the agent needs to walk a fallback chain (CLI, then WebFetch). Use judgement: small ticket + MCP available = call directly; large ticket or no MCP = subagent.

Direct path (when MCP is available)

Call the platform MCP tool directly. Extract: title, description, acceptance criteria, labels/tags, priority, assignee, linked issues, attached files, and every URL mentioned in the body or comments. Keep the raw structured output for Steps 3-4.

Subagent path (when MCP is unavailable or response would be very large)

Spawn a **Ticket Reader** subagent with `model: "sonnet"` and this brief:

> Read the full ticket [ID/URL] and return: title, description, acceptance criteria, labels/tags, priority, assignee, linked issues, attached files, and every URL mentioned in the body or comments. > > Use the best available tool in this order: > 1. MCP tool for the platfo