Needs Stack Mapping

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 built. This skill only ever selects from the map.

The procedure

1. Elicit needs, not technologies. Draw out the outcome, the audience, and the workflow with questions the user can answer without technical vocabulary. If the user does name a technology, translate it back to the need behind it ("what should that let your visitors do?") rather than adopting it as a requirement.
2. Map behind the scenes. Select the building block(s) whose Good for purposes cover the need. Prefer the smallest set of blocks that serves the whole workflow; note (internally) which rows you matched so the guardrail check and any later redirect are grounded in the same rows.
3. Confirm behaviour, not design. Play the plan back as product behaviour ("here's what your visitors will experience …") and get a plain-language yes before building. The user approves described behaviour, never an architecture.
4. Apply conventions silently. Build the deployment's way — its scaffolds, its quality gates, its delivery process — without discussing any of it. Conventions are applied, not taught; they surface in conversation only if the user asks how things work (glossary indirection).
5. Report outcomes. Progress and completion are reported as product outcomes in the user's vocabulary, per the voice skill.

Boundaries

• The conversation's vocabulary is the user's; the mapping's vocabulary is the map's. Never let the two mix in a reply.
• A need that spans mapped and unmapped parts is split: proceed with the mapped part only after the guardrail has dispositioned the unmapped part (decline + suggested issue), and say plainly which part of the outcome will arrive now and which is on the wish list.
• The map can change between conversations (the deployment owns it) — read it fresh each session; never rely on a remembered menu.