사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/drewbarontini/skills --skill map-shape시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Map Shape
Given a product problem or opportunity, use Shape Mapping to discover the work's relationships, isolate deliverable value, reduce scope, and establish an order of operations without prematurely specifying implementation.
Boundaries
Shape Mapping is for clarifying what should be built and how the value can be bounded. It is not a substitute for product discovery, detailed technical planning, task estimation, or code generation. Do not invent product requirements to make the shape look complete; retain Questions, Risks, and Unknowns.
Canonical Method
Follow these five steps in order, revisiting earlier steps as new information appears:
- Surface — Create a flat list of everything. Tag each item as Action, Decision, Question, Risk, or Unknown. Nothing is in or out of scope yet.
- Structure — Build relationships in the list. Anchor root nodes, nest sub-items, and link dependencies. Discover relational groups rather than imposing an operational plan.
- Slice — Find vertical slices of value. Name each slice, define its boundary, and test whether it can stand alone as a usable flow—not merely a technical capability.
- Simplify — Reduce each slice to the smallest version that still delivers value. Remove, defer, or narrow scope explicitly.
- Sequence — Create the order of operations. Distinguish build units from value units and bundle slices when users only receive meaningful value from them together.
Read references/shape-mapping.md for the detailed tests and the optional Shape Prompt form.
Output
# Shape: [Name]
## Context
[Problem, opportunity, user value, and why it matters.]
## Surface
- [A] Action
- [D] Decision
- [Q] Question
- [R] Risk
- [U] Unknown
## Structure
### [Root / Group] (depends on [...])
- [...]
## Slices
### [Slice Name]
- Value: [...]
- Boundary: In [...]; Out [...]
- Dependencies: [...]
- Independence test: [...]
## Simplification
- Keep: [...]
- Reduce: [...]
- Defer / remove: [...]
## Sequence
1. [Build unit or value bundle] — because [...]
## Remaining Uncertainty
- [...]Produce a Shape Prompt only when the user needs a handoff into planning or execution. The Shape Map remains the primary output.
Quality Bar
A strong shape preserves the five canonical steps, makes relationships and dependencies visible, defines end-to-end slices of recognizable value, subtracts meaningful scope, distinguishes build order from release value, retains uncertainty, and is concrete enough to guide product work without pretending implementation decisions are settled.
