---
name: intake
description: Use at the very start of any coding task or project. Interviews, classifies scale AND stakes, resolves direction forks, emits a stated direction (or milestone roadmap). (Lineage: godmode/intent-discovery, agent-skills/interview-me, superpowers/brainstorming)
phase: Define
---

# Intake — the point of this skill is not to execute yet

## Prime directive
Nothing gets planned or built until Brad has confirmed, in his own words, what success looks like.

## Steps (in order)
1. **Classify scale and risk.** Full interview MANDATORY when: destructive data touch, multiple files, new dependency, or goal needs more than one sentence. Otherwise fast path.
2. **Set the stakes tier.** Every task or project gets one, written next to the direction: TOY (learning/experiment, nothing at risk), WORKFLOW (your own systems could break), or MONEY (payments, live trading, public-facing production). MONEY tier: the direction block names the risk plainly; verify gets a strong-model review recommendation.
3. **Interview.** What is wanted, what "done" looks like, how he verifies. Plain language.
4. **Write the success cue.** Measurable, observable, or honestly-labeled subjective. Vague goals do not pass.
5. **Learning-vs-tool reframe.** When he asks for something ambitious-and-general ("build an LLM"), ask: is the goal the artifact, or the learning? A learning goal reframes to a toy-scope project; a tool goal triggers the build-vs-reuse direction fork. Never let a two-week R&D slog start by accident.
6. **Major project?** ROADMAP.md: 3–7 milestones, one-line cues each. Loop per milestone; brief intake rerun per milestone.
7. **Knowledge page.** One-offs: never. Multi-milestone: strongly recommend per-repo Hindsight page; ask once; record answer in ROADMAP.md.
8. **Direction forks.** 2–3 options, pros/cons/recommendation/why, then WAIT. MONEY-tier forks always include risk in the cons column.

## Done when
- Stakes tier recorded. Success cue written. Direction given, undisputed.
- Direction forks answered. Roadmap exists iff multi-milestone. Page question asked iff ongoing.

## Cognitive traps
- "Big ask = big build" — ask learning-vs-tool before scaping weeks of work (X5 finding).
- "The request is obvious" — confirm the goal, not the mechanism.
- "Fuzzy goals are goals" — no cue, no plan.

## Guardrails
- No code, plan, or tool speculation before Done-when is satisfied.
- Destructive data work ALWAYS interviews.
- Max 3 options per fork.