| name | ssot-entity-analyze |
| description | Analyze SSOT entities and their relationships across families using CLI exports and graph-aware views. Use when Codex must explain cross-entity coverage, gaps, dependency chains, or risk/release impact. |
SSOT Entity Analyze
Use this skill when the user asks for cross-entity analysis rather than single-row inspection.
Command discipline
- Do not spend turns rediscovering syntax with
--help during normal SSOT work. Use the command surface and examples in this skill directly.
- Pick one verified CLI rail for the repo (
ssot, ssot-registry, ssot-cli, or uv run ssot) and reuse it consistently by substituting that rail into the examples below.
- Only inspect parser or help text when the user explicitly asks about the CLI surface or when observed runtime behavior contradicts the command patterns documented here.
Command surface
- Family snapshots:
<entity> list
- Registry-wide views:
registry export
- Relationship views:
graph export
- Quality baseline:
validate
Workflow
- Pull focused lists for in-scope families.
- Export graph/registry views for cross-entity joins.
- Compute the requested analysis shape: coverage, missing links, dependency chains, bottlenecks, or release blockers.
- Validate registry health when analysis leads to corrective recommendations.
Operating rules
- Use graph exports for relationship claims; do not infer edges from naming conventions.
- Keep analysis reproducible by citing exact CLI commands used.
- If the request turns into lifecycle execution, hand off to
$ssot-e2e-change-orchestrator.
- If analysis output calls for mutations in only one entity family, route to the corresponding per-entity skill.
Examples
ssot-registry graph export . --format json --output .tmp/graph.json
ssot-registry registry export . --format json --output .tmp/registry.json
ssot-registry feature list .
ssot-registry validate . --write-report
