intake

intake — specode's requirements-intake engine

Host-tool convention 🔧: tool names in this skill — AskUserQuestion (structured multiple-choice question), the Skill tool (invoke another skill by name) — are written for Claude-family hosts (Claude Code / CodeBuddy), where naming them directly is the most reliable. On a host that lacks one, use its nearest equivalent (a structured-question tool / a skill-invocation mechanism); with no equivalent, fall back to a plain-text question / reading the target skill's SKILL.md directly. The described behavior is what matters, not the exact tool name.

§0 Who you are / when you're invoked

• The specode orchestration shell invokes you by name (specode:intake) via the Skill tool during the requirements phase. By then <specsRoot> is resolved, <specsRoot>/<slug>/ exists, and the slug is fixed.
• You are the sole producer of requirements.md — specode no longer forks the requirements phase on "superpowers present or not". superpowers' brainstorming is used only for design from here on; it never moonlights as a requirements writer.
• What sets you apart from the old "native 2-4 question wizard" is entirely §Step 2 project analysis + §Step 3 analysis-driven clarification: read the real project first to establish a factual baseline, then ask grounded questions — that is specode's own "driving capability", not a blank questionnaire.
• Your outputs:
  1. <specsRoot>/<slug>/requirements.md — prose requirements plus the hard frontmatter contract (§1);
  2. a block of 参考定位（非事实来源） location pointers handed to the design phase (§5, ephemeral context, never persisted as fact).

§1 Hard constraints 🔒 (never violate)

1. Frontmatter contract (highest priority — explicitly required by the user): the YAML at the top of requirements.md must carry three fields — spec_id / created_at / project_root. project_root is the single source of truth for downstream distill / task-swarm / retrieval, and it may only be written through the single validated writer resolve_root.py write-project-root (it validates absolute path / dir exists / /Volumes mount); never hand-write that field. You change who generates the body of requirements, and must never break these contract elements.
2. Prose requirements: requirements.md is a natural-language spec (background / scope in-out / - [ ] AC-N / open questions), no formalized clauses, no checkboxes — the plan lives in tasks.md and the design in design.md; don't cross that boundary. Bug fixes go here as Current / Expected prose; there is no separate bugfix.md.
3. User-facing output is Chinese — technical names / paths / code identifiers / frontmatter key names stay verbatim.
4. Never reprint the full document (see §5 reporting discipline).