Add `intake` skill: turn a GitHub/linear issue into a scoped poteto-mode run

[thisguymartin]

Problem

Every pstack run today starts with a human writing a good prompt. The quality of the run tracks the quality of that prompt: scope, exit condition, which playbook fits, which files matter. orchestrate and autopilot-* assume the briefs already exist ("author briefs, drain the queue"). Nothing in the tree takes the raw thing a team actually has, a GitHub issue, and turns it into a brief pstack can run.

So the flow is: issue -> human rewrites it as a prompt -> poteto-mode. The rewrite step is where the human still does real work, and it's the step that doesn't scale to "work the backlog overnight".

Proposed skill

Skill	Use it when
intake	You have a GitHub issue (or several) and want each turned into a poteto-mode run with a scope, an exit condition, a playbook, and a worktree, without writing the brief yourself.

Flow: issue -> read + ground in the repo -> brief -> playbook pick -> worktree -> (optionally) launch.

1. Read the issue. Title, body, labels, linked PRs, comments. Comments often carry the real spec ("actually we decided X in the thread").
2. Ground it in the repo. Run the how skill on the subsystem the issue names. Collect file pointers, entry points, test commands, and the project's verification skill if one exists. No inlined dumps (principle-guard-the-context-window).
3. Classify. Pick the playbook: bug-fix, feature, refactoring, perf-issue, investigation, or figure-it-out when nothing narrower fits. Say why.
4. Write the brief. One file per issue under a run directory: goal, in-scope / out-of-scope, exit condition (what "done" is, in observable terms), verification plan (unit, live, perf boxes per multi-phase-plan), file pointers, and the issue link. Mark anything the issue leaves ambiguous as an explicit question.
5. Ambiguity gate. If the brief has open questions that change the design, stop and ask, or post them as a comment on the issue when running unattended. Don't guess at product decisions (principle-never-block-on-the-human applies to mechanics, not to intent).
6. Prepare the worktree. One per issue, branch named from the issue number. Writers never touch the primary checkout.
7. Launch or hand off. With --run, start poteto-mode on the brief. Without it, return the brief and worktree path for a human to review first.

Output: the brief file, the worktree path, the chosen playbook, and open questions. When several issues are given, one summary table.

Real-world use cases

1. Solo dev, Sunday backlog. Martin has 12 open issues on a Go API. Most are small: "rate limit header missing on /v1/export", "flaky test in internal/queue", "add --json to the CLI". He runs /pstack:intake 41 42 45 47. Intake reads each one, grounds it, writes four briefs, flags that ericlitman#45 ("make search faster") has no target number and asks for one. He answers the question, then hands the three ready briefs to autopilot-stack. Monday morning he reviews three PRs instead of writing three prompts.

2. Issue with a buried decision. Issue ericlitman#88 says "support SSO". Twenty comments down, the team agreed on OIDC only, no SAML, and picked a library. Intake pulls that out of the comments into the brief's scope and out-of-scope lines. Without it, poteto-mode would read the title and start designing for both.

3. Bug report with a repro. A user files "export CSV has wrong timezone" with sample input and expected output. Intake classifies it as bug-fix, turns the sample into a failing-test candidate for tdd, and the exit condition is "that test passes and the live export shows the expected timestamp".

4. Triage before a nightly run. Combined with the planned nightwatch skill: intake is the front door that decides which issues are runnable unattended (clear scope, testable exit) and which need a human first.

What already exists and how this differs

• orchestrate / autopilot-*: consume briefs. Intake produces them.
• figure-it-out: designs a playbook when none fits. Intake picks from existing playbooks and only falls through to figure-it-out.
• how: intake calls it for grounding rather than reimplementing exploration.
• recall / session-pickup: about resuming your own past work, not starting from an issue.

Guardrails (from AGENTS.md and provider-dispatch)

• Reads only. Intake never edits product code. Launching poteto-mode is a separate, explicit step.
• No implicit timeout, no weaker-model fallback. Grounding runs on the configured how explorer / judgment and prose roles via provider dispatch; children never pick routes.
• Forge access via the existing gh conventions in opening-a-pr.md / babysit. Codex mapping goes in codex-tools.md, not a forked skill.
• Anything posted back to the issue (open questions) carries the usual attribution.

Acceptance

• plugins/pstack/skills/intake/SKILL.md with the flow above, shared by Claude Code and Codex.
• Brief template documented in the skill (or references/).
• README "Useful skills" row and docs/reference.md entry.
• Bun tests, strict typecheck, static invariants, plugin validation pass.
• Live test on the installed candidate in each affected harness: run intake against a real issue in a scratch repo, confirm the brief, worktree, and playbook choice. Record installed version, surface, action, and observed result in the PR.