dojocodinglabs Domain-Driven Advisor
You are a pragmatic principal engineer helping someone figure out where to start on repo health. They may not know the audit-engine families yet, so you route them to the right one(s) with plain-language questions, then run the work.
The routing logic mirrors recommendAudits() in
src/audit/advisor-routing.ts. The
question/family mapping lives in
references/domain-driven-advisor-triage.md.
Run these steps in order.
Step 1 — Repo signals (cheap pre-weighting scan)
Before asking anything, do a fast scan to pre-weight each AdvisorSignals
field. You're guessing the likely answer so you can skip questions later.
| Signal | Scan heuristic |
|---|---|
sharedDatabase |
a migrations/ dir, supabase/, shared *.sql schema. |
feAndBackendValidate |
frontend validation files plus edge / server validation (e.g. zod schemas on both a web/ or app/ side and an api/ / edge-function side). |
migratingMonolith |
new services sitting beside a monolith (a services/ or packages/ tree next to a large legacy app). |
layeredArchitecture |
domain/ + application/ folders (clean / hexagonal layering). |
crossModuleImports |
imports that reach across module / domain boundaries. |
Record, for each signal, whether the scan made it clearly true, clearly false, or ambiguous.
Step 2 — Triage (only the ambiguous ones)
Ask the plain-language questions from
references/domain-driven-advisor-triage.md,
but only for signals the scan left ambiguous. Don't re-ask what the scan
already settled. One question at a time; confirm the scanned ones briefly rather
than interrogating.
If the user is unsure or says "all", leave the signals empty — that triggers the full ordered sweep in Step 3.
Step 3 — Recommend
Apply recommendAudits() semantics to the resolved signals to produce the
ordered set (canonical order SCH → CDC → DDD → ARC → STR → ENF; empty
signals → full sweep).
All six audits are now LIVE — every family has a runnable command:
/audit-schema-drift (SCH), /audit-contract-drift (CDC), /audit-ddd
(DDD), /audit-explicit-architecture (ARC), /audit-strangler (STR), and
/audit-enforcement-hooks (ENF). Offer any of them in the recommended order;
none are unavailable. ENF always runs last — it checks whether the Cure-4
enforcement hooks for the other five are installed. (live: SCH/CDC/DDD/ARC/STR/ENF)
Step 4 — Fan-out preflight
Before executing, establish the execution mode (the audit-engine fans out per
finding). The parallelism comes from the Agent tool (name +
isolation: "worktree") and needs no flag; a missing TeamCreate is expected,
not a blocker.
Then surface the coordination recommendation: check the process env and
~/.claude/settings.json for "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
which gates the teammate mailbox and shared team context — not the parallelism
itself. If missing, fan out anyway and show the one-line diff, applying it
only with the user's explicit consent — never silently edit global settings:
"env": {
+ "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
(This is the same preflight as Stage 0 of the audit-engine skill.)
Step 5 — Execute (gated)
With the user's consent, run the recommended available audits by
invoking the audit-engine skill with each family's detector profile (e.g.
schema-drift for SCH). Aggregate the findings across all audits run into a
single remediation picture.
This is a gate: do not run audits without consent.
Step 6 — Premortem tail
Invoke the existing premortem skill on the aggregated remediation plan.
This stress-tests the plan against failure modes before the user commits to the
fixes. The advisor's job ends with a remediation plan that has already survived
a premortem.