skills/vibe-map/references/product-capability-map.md

# Product Capability Map

## Operation

Create or refresh only the requested repository map. A map is a navigation index, not proof of correctness. Verify entries against current owners and preserve stable IDs. If the user asks for an explanation in chat, do not insist on writing a file.

## Goal

Create or update `docs/product_capability_map.md` as an evidence-backed map of product capabilities, user value, actors, entry points, acceptance boundaries, and implementation owners.

## Inspect

Product routes, navigation, feature modules, copy, onboarding, settings, billing/plan gates, permissions, analytics events, experiments, docs/PRDs, tests, API contracts, workers, and existing product maps. Use repository behavior as the primary evidence source.

## Map rules

- Write or update `docs/product_capability_map.md` when possible; otherwise print the full markdown.
- Preserve stable IDs: capability `CAP-*`, actor `ACT-*`, journey `JNY-*`, requirement `REQ-*`, acceptance `ACC-*`, metric `MET-*`, risk `RISK-*`.
- Connect each capability to an authoritative owner, visible surfaces, backend/data contracts, roles/plans/tenant scopes, tests, metrics, and known gaps.
- Separate repository facts from inferred product intent. If product docs and implementation disagree, mark drift and cite both sources.
- Do not create implementation tasks; this map feeds product audits, workstream decomposition, traceability, and release readiness.

## Coverage

Map capabilities by user/business goal, not by folder alone. Include target actors, activation path, core and edge states, monetization or entitlement dependency, analytics/events, experiments, copy/legal claims, support/admin surfaces, acceptance evidence, and explicit non-goals if they are discoverable.

## Markdown structure

Use summary, conventions, actors, capability inventory, capability detail sections, requirement/acceptance matrix, surfaced gaps/drift, product metrics links, related maps, and unknowns.