القائمة
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
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
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
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
Take a validated intent and drive a single candidate to shaped — bounded, de-risked, and ready for a commitment decision
Launch an already-scaffolded Bounded Context as a running, online container and verify it reaches the online state
استنادا إلى تصنيف SOC المهني
| name | problem-space-mapping |
| description | 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 |
This is the mapping mode of the lead-pm main session, and unlike the others it runs continuously rather than as a one-off session. Its job is to keep the problem-space map — the living picture of the problems the product exists to solve, how they relate, which are solved, which are open, and which are parked — current as intent records, candidates, and decisions accumulate.
The map is what keeps discovery and shaping honest: a new problem is understood by where it sits relative to the ones already mapped, and a candidate is understood by which mapped problem it closes. Without the map, each session re-derives the landscape from scratch and the product loses its throughline.
Terminal artifact: a mapping pass terminates in a problem-space map revision — an update to the living map reflecting a newly surfaced problem, a newly closed one, a re-drawn relationship, or a re-parked area. Because mapping is continuous, its artifact is a revision to the existing map rather than a fresh document each time.
Mapping is not a gate you wait for; it is upkeep you fold into every session that changes the problem landscape.
Identify what moved: a new problem, a closed problem, a changed relationship, a re-scoped area. Tie it to the intent record, candidate, or decision that caused the move.
Situate the change relative to the problems already on the map. Is it a child of an existing problem, a sibling, a newly independent area, or a re-framing of one already there? The value of the map is in the relationships, not the list.
Update the living problem-space map: add, close, re-relate, or re-park. The map is a stewarded living document — you revise it in place as the product moves rather than appending a new copy.
Declare the mode (mapping) in the session record and list the problem-space
map revision as the produced or revised artifact.
The map lives in the problem space — problems and their relationships, at capability altitude. It never carries implementation detail: no schemas, no CLI flags, no env var names. Those belong to the solution space the Architect holds.
