map-systems

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow,docs.density,project.stage

Resolved above — use as-is; --review overrides review_mode. No block → defaults in .claude/docs/config-resolution.md.

Map Systems

When this skill is invoked:

Parse Arguments

Two modes:

• No argument: /map-systems — Run the full decomposition workflow (Phases 1-5) to create or update the systems index.
• next: /map-systems next — Pick the highest-priority undesigned system from the index and hand off to /design-system (Phase 6).

See .claude/docs/director-gates.md for the full check pattern. Individual gate definitions live in .claude/docs/director-gates/[gate-id].md — the spawned agent reads its own gate file; do not read it in the parent session.

Every AskUserQuestion call follows .claude/docs/automation-modes.md (collaborative asks always · guided major-only · autonomous logs and proceeds; automation_always_ask categories always prompt). In collaborative mode the system list, dependency, priority and write approvals are separate questions: each waits for its answer before the next step runs.

docs.density — it controls per-section depth, where workflow controls which sections exist. modes.rigor sets both together; set docs.density explicitly to vary depth alone: terse (the default, via rigor: minimal) = one-line system descriptions; balanced = a brief paragraph per system + dependency notes (rigor: standard); thorough = full system-by-system rationale + relationship analysis. Apply it to every section you author.

Where the per-system prose goes. templates/systems-index.md's Systems Enumeration is a fixed-column table with no description column, so at balanced and thorough the prose belongs in ## Overview — one short paragraph per system at balanced, plus relationship analysis at thorough — and in the ## Dependency Map layer notes. Do not add a column to the enumeration table — it is a fixed contract in .claude/docs/templates/systems-index.md, and its consumers (/design-system §6 and §7, /create-epics) are written against the columns it defines. Widening it is a schema change, not a formatting choice.

How the consumers actually read it. Nothing parses this table positionally. The two scripts that mention systems-index.md (gdd-structure-check.sh:51, review-scope.sh:40) match it by filename in a case statement and parse no columns at all; the two skills key on the Category column by name (design-system:229, :780). So Category is the column that must never be renamed or dropped, and the table stays a fixed contract because every consumer is written against the set of columns the template defines. At terse, the table plus a one-paragraph ## Overview is the whole output.