intake

intake

Overview

The front door of the spec-driven workflow. A raw idea or voice transcript goes in; a reviewable story artifact comes out at docs/superpowers/stories/YYYY-MM-DD-<topic>-story.md and feeds superpowers:brainstorming as its input document. This standardizes an entrance that otherwise varies by whoever writes the prompt.

intake captures WHAT and WHY, never HOW — designing the solution is brainstorming's job. That boundary governs every story section except Section 4 (Affected AGENTS.md invariants), which quotes existing project invariants verbatim as constraints the future solution must respect. Naming a guardrail the solution has to honor is not designing it — so "auth via the project's requireAuth barrier" belongs in Section 4, while "add a requireAuth call to the new handler" is a HOW leak anywhere else.

Target model: Claude via Claude Code. This skill is a prompt artifact and follows the checklist in docs/prompt-standards.md.

Requires AGENTS.md (the project's invariants file) — the Flow's invariant-tagging step greps it, and story Section 4 quotes what it finds. If the repo has none, say so and offer /dev-workflow:workflow-init, which walks you through writing one.

When to use

• A raw idea or voice transcript arrives and needs to enter the workflow, before any brainstorming — so the entrance is consistent regardless of author.
• A backlog line needs to become a reviewable story before design starts.

Not for designing a solution (that's superpowers:brainstorming), and not for items that already have an approved story/spec or have moved into solution design.

Flow

Follow in order. Each step names why it exists.

1. Read the input — the idea or transcript (German or English). The story you write is in English (the codebase and AGENTS.md language), preserving domain terms the user used verbatim where meaning matters — so downstream grep and consistency hold even for German input.
2. Detect ambiguity — if any of the six story sections can't be filled from the input without guessing (most often vague acceptance criteria or an unclear outcome), ask targeted questions first — surface gaps rather than filling them silently (CLAUDE.md §1).
3. Assess the profile — derive a proposal for two axes and a validation mode, so the single question round below can carry it. Nothing is recorded yet:
   • Risk — trivial (no behavioural effect in the artifact's own execution context; for a prompt artifact the text is the behaviour, so a wording change to a skill, command, agent definition, hook message or template is not trivial by default) · standard (a behaviour change hitting no named trigger — the default) · high (the change affects a named domain trigger — auth, permissions, payments, migrations, data deletion, public APIs, personal data, supply chain — or a named effect trigger — irreversibility, data loss or corruption, outage exposure).
   • Security relevance — none (touches no asset, trust boundary, role or external system — a real answer and the common one) · standard (touches one without changing what it permits) · high (changes a trust boundary, an authorization decision, or the handling of secret or personal data).
   • Validation mode, derived not asked: effective level = max(risk, security) over none|trivial → 0, standard → 1, high → 2 → battery / battery+check / battery+check+verification, plus +abuse-path when and only when security is high.