derive-systems-inventory

What problem does it solve?

It solves the problem of mapping product capabilities to the exact systems and sub-systems that will implement them, so later architecture stages remain traceable and deterministic.

Core Features & Use Cases

• Capability-to-System Resolution: Selects one system (or sub-system surfaces) per selected capability, using pinned project choices, KB catalog matches, or research-authored entries when needed.
• KB-Grounded Provenance or Research Drafting: Pulls canonical system definitions from the knowledge base with provenance and immutability, or authors stm_research inventory entries with the required schema shape.
• Decision Surfacing for Ambiguity: Halts on multi-candidate KB matches and records grounding questions so an orchestrator can obtain user approval before downstream impact.
• Inventory for Downstream /arch Stages: Writes per-system inventory files plus a decision manifest that later stages can resolve against without inventing new systems.

Example use case: when you have a set of product capabilities to deliver, this Skill produces an architecture-ready systems inventory that identifies the ERP/CRM/identity/payment/search/observability/content components (and their sub-systems where responsibilities diverge) before any detailed architecture work begins.

Quick Start

Use the derive-systems-inventory skill during arch Stage 1 to populate {product_base}architecture/systems-inventory/ and {product_base}architecture/decision-manifest-derive-systems-inventory.yaml from scope-selected capabilities and KB catalogue candidates.