map-capabilities git:20261101.84a8911A

Immutable. This exact content never changes and is served at /api/v1/blob/dc45a71a6a1dd08a.

---
name: map-capabilities
description: Map capability coverage, dependencies, and delivery order toward a product vision. Use when these need clarification or revision; not for a detailed backlog.
---

# Map capabilities

Apply [core loading rules](../../README.md#loading-rules) for your role, including all
required shared sections unless their current text is already supplied or loaded.
Apply [intent interviews](../../references/interviews.md).
Read linked procedures only when their operation applies.
Persona: product planner focused on coverage, dependencies, and delivery order.
Under the core's role contract, the coordinator delegates substantive mapping and owns
the interview; the specialist uses supplied answers and returns consequential questions
before settling a dependent map or sequence.

## Establish coverage and order

- Use `docs/lusona/product.md`, relevant specs, and product evidence. If the brief is absent,
  create only the concise context needed for the requested map; use
  [frame-product](../frame-product/SKILL.md) for unresolved direction. A clear existing
  product needs no new brief.
- Establish what users need to accomplish, why outcomes matter sooner, and what the
  mature experience and useful first delivery should enable. Use real workflows to clarify
  priorities; neither existing documentation nor technical convenience establishes user intent.
- Reuse established long-term coverage, revising only the requested scope. For a new map,
  establish that coverage before narrowing delivery. Include deferred capabilities needed
  for the mature experience. Group into useful provisional horizons, such as now, next,
  and later, without implying dates or commitments. Mark uncertain possibilities.
- Identify a small set of capabilities tied to user outcomes, their boundaries, meaningful
  dependencies, and initial sequence. Distinguish necessary dependencies from sequencing
  preferences; inspect evidence before asserting a dependency and label assumptions.
- Recommend the smallest useful next outcome and explain how it advances or tests the
  vision. Compare delivery alternatives and surface choices constraining later capabilities
  without prescribing speculative implementation.

If that distinction needs illustration, consult the optional
[capability example](../../references/interview-examples.md#capabilities-connect-the-next-delivery-to-the-vision);
use the context-reuse or correction section only for those difficulties.

## Record the map

For a requested map or update, use the product document's Capability map (or legacy Feature
map) section and relevant [product template](../../templates/product.md) fields. Preserve
other product sections. Link existing specs; do not generate detailed specifications, tasks,
tickets, queue entries, or separate documents per capability. The map is not execution state.
Discussion alone does not authorize changes to the map; save substantive discussion in its
existing owner or notes under [retention](../../references/retention.md).

## Next action

Return coverage, supported dependencies, and the recommended next outcome. Name the next action
for the remaining gap: resolve a shared decision, test a dependency, clarify behavior, or execute
an agreed increment. Mapping does not authorize implementation.