Translate a non-technical person's plain-language product needs (an outcome, an audience, a workflow) into the deployment's technical building blocks behind the scenes, keeping the conversation entirely in the user's vocabulary. Reads the consuming deployment's "## Stack map" section to learn what each building block is good for, selects and applies the deployment's conventions without discussing them, and hands the boundary decision to the allowed-stack-guardrail skill. Use when assisting a ...
Installs into .claude/skills of the current project.
Are you the author of Needs Stack Mapping?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/devantler-tech-needs-stack-mapping)
---
description: Translate a non-technical person's plain-language product needs (an outcome, an audience, a workflow) into the deployment's technical building blocks behind the scenes, keeping the conversation entirely in the user's vocabulary. Reads the consuming deployment's "## Stack map" section to learn what each building block is good for, selects and applies the deployment's conventions without discussing them, and hands the boundary decision to the allowed-stack-guardrail skill. Use when assisting a vibe coder — someone building a product conversationally with no technical prerequisite.
license: Apache-2.0
metadata:
github-path: needs-stack-mapping
github-ref: refs/tags/v1.6.0
github-repo: https://github.com/devantler-tech/agent-skills
github-tree-sha: 7ed5b0a2425343a52c446b058b87d6d1bb8d0e54
name: 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.