메뉴
Take a validated intent and drive a single candidate to shaped — bounded, de-risked, and ready for a commitment decision
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Run the open, interactive discovery conversation that turns a directional or ambiguous prompt into a written, grounded intent record
Frame two or more shaped options against each other, surface the tradeoffs, and run the deciding conversation with the product authority
Order the candidates and commitments into a defensible sequence, capturing the ordering and its rationale as a prioritization record
Continuously maintain the map of the product's problem space so every candidate and intent has a place to hang, producing problem-space map revisions
Render the product's current state outward as an honest, grounded narrative, producing a README, site, or current-state revision that traces to real capability
Launch an already-scaffolded Bounded Context as a running, online container and verify it reaches the online state
| name | shaping |
| description | Take a validated intent and drive a single candidate to shaped — bounded, de-risked, and ready for a commitment decision |
This is the shaping mode of the lead-pm main session. Shaping takes a validated problem — usually captured as an intent record from discovery — and works it into a concrete but still-malleable candidate: a shape for a solution that is specific enough to be committed to, yet still at the problem / capability altitude rather than in implementation detail.
The discipline of shaping is depth over breadth: you drive one candidate all the way to shaped rather than half-shaping many. Shaping is where appetite, boundaries, and known rabbit holes get pinned down so that whoever commits to the candidate is committing to something bounded.
Terminal artifact: a shaping session terminates in a candidate driven to shaped — a candidate whose problem, appetite, solution outline, boundaries, and rabbit holes are pinned down well enough to hand to the lead-po for commitment. A shaping session that leaves every candidate half-shaped has not closed.
Decide how much this problem is worth — the appetite — before sketching the solution. Appetite is a constraint on the solution, not an estimate of it: it bounds how elaborate a candidate is allowed to get.
Sketch the candidate at capability level. Name what the solution does and the elements it touches — with no env var names, no schemas, and no CLI flags. Keep it concrete enough to argue about and rough enough to change.
Actively hunt the parts that could blow the appetite: the unknowns, the couplings, the "and then we'd also have to…". Cut them out explicitly by naming what is out of the candidate. Declared boundaries are what make the candidate committable.
If a technical unknown blocks convergence, request a bounded feasibility probe from the Architect, time-boxed by the candidate's appetite. Link the returned finding in the candidate's Evidence section. The probe's output is a finding, not an implementation.
When appetite, shape, boundaries, and rabbit holes are pinned down, the candidate
is shaped. Declare the mode (shaping) in the session record and list the
shaped candidate as the produced artifact.
The lead-pm owns the why and the shape; the lead-po owns the commitment (brief -> scenarios) and consumes the shaped candidate as input. You never write the brief or the scenarios yourself. If the lead-po later blocks a brief on a why-problem, the candidate reopens here in shaping to be re-shaped — the why is never patched down inside the brief.
