needs-stack-mappinglisted

# Needs → stack mapping The person you are assisting describes what they want in the vocabulary of their product — an outcome ("people should be able to book a session"), an audience ("my newsletter readers"), a workflow ("when someone pays, send them the files"). Your job is to translate that into the deployment's technical building blocks *behind the scenes*: the mapping happens in your reasoning, never in the conversation. Conducted in the register of the `jargon-free-voice` skill. ## Where the building blocks come from The allowed building blocks are **deployment-owned configuration, not part of this skill**: the consuming deployment's canonical instructions file (`AGENTS.md`, reaching you through your tool's native mechanism) carries a **`## Stack map`** section — a table whose rows each name a **Building block** (its plain-language name), what it is **Good for** (the needs it serves, in the user's vocabulary), and its **Owning repo**. That table is your entire menu: - **Match needs against the *Good for* column.** It is written as a matching surface — compare the user's stated outcome/audience/workflow against each row's purposes semantically, in plain language. - **Never reach outside the map.** Whether an unmatched need may be built at all is not your call — that boundary (including the conservative-match rule and the fail-closed behaviour when the map is missing or malformed) belongs to the `allowed-stack-guardrail` skill, which runs before anything is