Skip to content
Back to skills

Needs Stack Mapping

ASecurity

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 ...

  • 2 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 25, 2026
ai-agentsgogit

Works with

  • cli

Security analysis

A100/100

Scanned September 25, 2026

npx -y skills add devantler-tech/agent-plugins --skill needs-stack-mapping --agent claude-code

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.

Security grade badge for Needs Stack Mapping
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/devantler-tech-needs-stack-mapping/badge)](https://www.skillsdirectory.com/skills/devantler-tech-needs-stack-mapping)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.