stelow-product-scope-mapping

Scope Mapping

Use this skill to turn an approved product proposal, technical plan, or codebase context into a small set of coherent delivery scopes.

The method is product planning: it discovers the boundaries of the work and makes uncertainty visible. It does not create execution tasks, choose a runner, or silently change an approved Shape.

Required input

Use the available proposal, spec, codebase context, and constraints. If the request is not approved for Scope, stop at the current lifecycle boundary and name the missing gate.

Record the input sources before generating scopes. Do not invent product authority, evidence, or approval.

Brownfield input (codebase exists)

Ground scopes in the code before drawing boundaries:

• cymbal structure --json — entry points and packages the map must respect;
• sem entities --json — domain symbols that anchor IN/OUT items;
• ripwire --exemplar "<outcome>" (or --lego <Iface> for a known interface) — reuse-first: imitate the existing block instead of inventing a parallel one.

Record these sources alongside the proposal before generating scopes.

Method

1. Restate the decision the map must support.
2. Identify the user-visible or operational outcome of the work.
3. Split the outcome into vertical scopes that can each deliver a coherent result.
4. Give every scope a stable ID, outcome, IN items, OUT items, capabilities, and dependencies.
5. Mark open decisions and evidence gaps explicitly.
6. Check that the graph is acyclic and that no scope silently owns another scope's boundary.
7. If a narrow bugfix or mechanical refactor needs no full map, emit a one-scope plan and record why the full map is unnecessary.

Preview mode (draft for the product gate)

Run with mode: preview when the decision-maker needs to SEE the division before approving anything — typically ahead of the product gate review:

• Single pass, no parallel scouts, no approval. Read the shaped proposal (approved or not) and emit tentative names, outcomes, and dependencies only. Capabilities and evidence stay explicitly marked as unharvested.
• Write scope-map-draft.json (same contract as the map, status: "draft") plus a readable draft companion (scope names + one-line outcomes + counts, never the full evidence tables).
• A draft from an unapproved spec is explicitly allowed here and ONLY here: it illustrates the division, it commits to nothing, and it must never be promoted without re-validation once the spec is approved.
• The gate review renders the draft read-only in a draft tone. Nobody edits the draft at the gate; feedback lands as review annotations, which the scope stage reconciles.