ddd-protocol

---
name: ddd-protocol
description: Shared DDD workflow protocols referenced by all skills. Contains the Ambiguity Handling Protocol (STOP/ASSUME), Persistence Defense Reference (3-layer model + hooks enforcement), Domain Architecture Reference (red lines), Spec Change Detection Reference, Per-Phase Subagent Dispatch Protocol, Platform Detection Reference (unified platform detection + constraint/hook paths), and Cross-Skill Traceability Reference (artifact dependency chain + impact analysis). Not invoked directly — loaded by other skills via relative path references.
license: MIT
---

# DDD Protocol References

## Overview
Shared protocol definitions used by all DDD skills. Contains 7 reference files that define mandatory constraints for ambiguity handling, persistence defense, domain architecture, spec change detection, subagent dispatch, platform detection, and cross-skill traceability. Not invoked directly as a workflow — other skills load individual reference files on demand via `../ddd-protocol/filename.md`.

## When to Use
Do NOT invoke this skill directly. Individual reference files are loaded by other skills when entering a phase or checkpoint that requires the protocol. If you need to understand a specific protocol, read the individual reference file — not this SKILL.md.

## Quick Reference

| Rule | Requirement |
|:-----|:------------|
| Ambiguity Protocol | STOP for high return-work radius; ASSUME & RECORD for low radius |
| Persistence Defense | Layer 1 (hooks) + Layer 2 (self-check) + Layer 3 (scripts) — all layers mandatory |
| Architecture Red Lines | 7 hexagonal + 4 domain modeling constraints — checked in GREEN step |
| Spec Change Detection | `git diff` on Phase 5/6 source files — triggers RECONCILE if changed |
| Subagent Dispatch | Context Brief Rule + STOP return + fresh context per phase |

## Contents

| File | Purpose | Load Trigger | Used By |
|:---|:---|:---|:---|
| `ambiguity-handling-reference.md` | STOP/ASSUME protocol for handling ambiguities by return-work radius | When skill encounters unclear requirement or ambiguous domain term | All 10 workflow skills (extracting-domain-events through mapping-legacy-landscape, excluding language-conventions) + all 5 orchestrators |
| `persistence-defense-reference.md` | 3-layer defense model (hooks + self-check + scripts) + Hooks Enforcement Protocol | When skill produces artifacts that must be written to disk | All 5 orchestrators (full-ddd, iterating-ddd, piloting-ddd, restructuring-ddd, importing-technical-solution) + all skills with Self-Check Protocol |
| `domain-architecture-reference.md` | 7+4 architecture red lines for domain layer purity | When verifying layer boundaries or dependency direction | coding-isolated-domains, test-driven-development, spec-driven-development (via package-placement-reference.md), language-conventions (via go-conventions.md) |
| `spec-change-detection-reference.md` | Git-based change detection convention for spec files | When checking for schema or spec changes between sessions | Convention document — describes the `git diff` pattern used inline by defining-schemas (Merge mode), spec-driven-development (Merge mode DETECT), and test-driven-development (Entry Check / RECONCILE) |
| `subagent-dispatch-reference.md` | Per-phase subagent dispatch format, STOP return, context brief | When orchestrator dispatches sub-skill as subagent | All 5 orchestrators (full-ddd, iterating-ddd, piloting-ddd, restructuring-ddd, importing-technical-solution) |
| `platform-detection-reference.md` | Unified platform detection, constraint file paths, hook config paths | When detecting agent platform for constraint files (mapping-bounded-contexts Step 6a, spec-driven-development PERSIST) or hook setup (orchestrator Step 0) | mapping-bounded-contexts, spec-driven-development, persistence-defense-reference, all 5 orchestrators |
| `cross-skill-traceability-reference.md` | Artifact dependency chain, template ownership, impact analysis for skill evolution | Before modifying a skill's output structure, template format, or cross-referenced sections | Any skill maintainer; used during skill evolution to identify downstream breakage |

## Usage

Reference these files from other skills using relative paths: `../ddd-protocol/filename.md`. Files are loaded on demand — do not preload all references at skill start. When adding a new skill that uses a protocol, update the "Used By" column above.

## Loading Guidance

Individual reference files are loaded on demand by calling skills — do not preload all 7 files:

- **On ambiguity**: Load `ambiguity-handling-reference.md` when a skill encounters an unclear requirement.
- **On artifact write**: Load `persistence-defense-reference.md` when artifacts must be written to disk.
- **On domain code verification**: Load `domain-architecture-reference.md` when checking layer boundaries.
- **On spec change check**: Load `spec-change-detection-reference.md` when entering merge mode or session recovery.
- **On orchestrator dispatch**: Load `subagent-dispatch-reference.md` when dispatching a sub-skill.
- **On platform detection**: Load `platform-detection-reference.md` when detecting constraint/hook paths.
- **On skill evolution**: Load `cross-skill-traceability-reference.md` before modifying a skill's output structure or templates.

Each file is self-contained. Never load a file "just in case" — load it when you reach the triggering condition above.

## Adding a New Protocol

- **File naming**: `{topic}-reference.md` — use kebab-case with the `-reference.md` suffix.
- **Required structure**: Title, Purpose (1 sentence), Rules/Constraints (numbered list), Examples (optional).
- **After creating**: Update the Contents table above — add a row with File, Purpose, Load Trigger, and Used By.
- **Scope**: One concern per file, keep under 200 lines. If a protocol grows beyond that, split it.

## Rationalization Table

If you catch yourself thinking any excuse in the left column — **STOP and re-read the Reality column.**

| Excuse | Reality |
|:---|:---|
| "I know the STOP/ASSUME rules from memory" | Protocol references evolve. The file is authoritative, not your cached understanding. Read the file. |
| "The protocol is obvious — just STOP when unsure" | The STOP/ASSUME boundary is defined by return-work radius, not by uncertainty level. Low-radius ambiguities should ASSUME, not STOP — unnecessary STOPs block the workflow. |
| "Persistence defense is overkill for this small project" | Small projects have the same artifact-loss risk. The 3-layer model costs seconds to set up and prevents hours of rework. |
| "I'll check architecture red lines at the end" | Red lines are checked per GREEN step, not at the end. A violation in test #3 contaminates the baseline for tests #4-N. |
| "Subagent dispatch overhead is unnecessary — I'll run inline" | Inline execution defeats fresh-context isolation and skips sub-skill loading. The dispatch cost (seconds) is negligible compared to a hallucinated phase output. |
| "I'll load all protocol files upfront for efficiency" | Loading all files wastes context window. On-demand loading keeps only relevant constraints active. |
| "The spec hasn't changed — skip change detection" | "Hasn't changed" is a claim. `git diff` is evidence. The check takes seconds. |
| "I'll use my own STOP/ASSUME judgment rather than the return-work radius test" | The return-work radius test is the protocol. Your intuition about what's "important enough to STOP" produces inconsistent results. Apply the test. |
| "The protocol files haven't changed since I last read them" | Protocol files evolve between sessions. Your cached understanding may be outdated. Re-read the specific file when entering a new phase. |
| "I only need the relevant section of the protocol file" | Protocol files are read in full; partial reads produce partial compliance. A section you skip may contain the constraint that applies. |
| "The calling skill already restates the protocol rules" | Calling skills reference protocols, not reproduce them; the file is the authority. Restated rules may be simplified or outdated. |
| "I'll apply Context A's protocol to Context B — same rules" | Each protocol is context-sensitive; cross-application skips context-specific constraints. Read the protocol for the context you are in. |
| "The protocol is just process overhead" | Every constraint exists because its absence caused a concrete failure. Process overhead that prevents rework is not overhead. |

## Red Flags

If you catch yourself thinking "I remember the protocol rules", "the protocol is obvious — just STOP when unsure", "persistence defense is optional", "I'll check red lines later", "subagent dispatch overhead is unnecessary — I'll run inline", "skip change detection — nothing changed", "load everything upfront", "I'll use my own STOP/ASSUME judgment rather than the return-work radius test", or "the protocol files haven't changed since I last read them" — **STOP. Read the specific protocol reference file. Follow its rules exactly. Protocol files are the source of truth, not memory.**