domain-analysis

Codex compatibility note:

• Invoke $skill-name: load the registered .agents/skills/<name>/SKILL.md and execute it with Codex tools; no separate Skill tool or Claude mode switch is needed. Author .claude/**; mirrors are generated.
• Track steps before execution and keep progress/evidence current. Explicit skill requests execute their protocol. Use the native question tool for required questions.
• Map foreign tool names to available host capabilities. A name mismatch needs no approval; an actually unavailable required capability stops with its step/evidence and a user question before adaptation.
• Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task.
• Preserve protocol order unless the user approves a deviation. Workflows use $start-workflow: gates stay fixed; other steps may flex with logged reasons and evidence. [BLOCKING] Mode routing — detect FIRST. Explicit --mode=review selects the DDD entity/value-object quality review; no mode is the default business domain analysis (the default workflow below). $domain-analysis --mode=review is the former /domain-entities-review: that slash command no longer exists, and the mode works called directly with no workflow. Read the mode file in full before anything else (see Mode Dispatch).

Quick Summary

Review modes: For review/audit work, standalone defaults to --review-only (--report-only alias); --fix-loop enables review → validate → authorized fix → fresh re-review, default cap 3. --fix-loop --loop-owner=caller returns a read-only pass to the caller that owns fixes/re-review. Create triage, review, validation and re-review todo tasks first; apply the carried review-policy contract for LOW deferral and user-approved bounded extensions. Non-review modes and terminal findings validation keep their own dispatch.

Goal: Produce a user-confirmed DDD model and ERD from business evidence so implementation preserves domain invariants and boundaries.

Summary:

• Default route: 0 plan/reference → 1 business context → 2 contexts → 3 entities/aggregates → 4 relationships → 5 events → 6 ERD → 7 user validation → 8 approved reference changes → 9 plan update; then Next Steps and a separate council prompt.
• Derive the model from evidence, confirm boundaries with the user, and persist decisions. --mode=review [changes | scan [<module>]] [--report-only] loads the quality-review contract instead.

Workflow: Execute Steps 0–9 below for analysis; use Mode Dispatch for review.

Key Rules:

• Track every step before work; execute in order without skipping, merging or reordering unless the user approves. Keep one task in progress, complete with evidence, record skip reasons, and resume existing tracking after context loss. Use an equivalent tracker if Task tools are unavailable.
• MANDATORY IMPORTANT MUST ATTENTION run user validation interview at end (NEVER skip).
• Validate every bounded context and key relationship with the user. Establish each model's owning context and explicit cross-context contracts; choose integration patterns from business and architecture evidence.
• Derive decisions from business artifacts; cite artifact/file:line evidence and confidence (>80% to act, otherwise verify). Compare 3+ existing reference entities before adding one; reuse only when identity, lifecycle and transaction scope fit.
• Include a Mermaid ERD; distinguish domain ownership from storage relationships and cross-service contracts. Use the shared entity-quality decisions and applicable DDD reference sections.
• Persist intermediate findings in tmp/reports/; add a final quality-review task. Reference updates require approval.