ddd-distribute

DDD Distribute (s_ddd-distribute) — the distribution step of the DDD lifecycle

Render a grown DDD into a distributable capability package so another agent host (Kiro / Quick / Claude Code / a public consumer) can install and use it.

This skill is a thin human-in-the-loop wrapper — all packaging logic lives in core/ddd_packager.py and the reach policy in core/ddd_distribution_policy.py. The skill's job is: read the declaration → confirm the target subset with the human → call the packager → surface warnings and the built path.

The reach model (READ BEFORE RUNNING)

A DDD declares its own reach in its aim.json:

"distribution": {
  "targets": ["aim-capabilities", "open-plugin"],   // the CEILING (0..2)
  "visibility": "internal"                            // internal | external
}

• The declaration is the ceiling. You may emit a SUBSET of the declared targets; you may NEVER add an undeclared target or raise visibility. To widen reach, the DDD owner edits the declaration first (a separate, deliberate change).
• Fail-closed. An absent / malformed declaration → targets:[] = not distributable. Nothing leaves by inference.
• Emit ≠ publish. A visibility:internal DDD may EMIT an open-plugin tree for a private install, but the public-publish step is refused until visibility is explicitly external (a human-gated change).

Workflow (HITL)

1. Locate the DDD — resolve <workspace>/Projects/<name>/ (the DDD dir).
2. Read the declaration — call the packager's policy; show the human the declared targets + visibility + any warnings (e.g. an unknown target token).
3. Confirm the subset — ask the human WHICH declared target(s) to emit now, and whether this is an emit-only pass or an external publish. Never propose a target the DDD didn't declare.
4. Render — run scripts/distribute.py with the confirmed subset. The packager: emits each target tree, runs the content-safety scan over the EMITTED tree, and aborts (fail-closed) on any secret / host-path (any target) or internal-string (external publish).
5. Return the path(s) — report the built package dir(s) + any scan warnings + which skills were included (class-B domain) vs excluded (class-A enablement / unclassified). Point the human at the install command:
   • internal → build + cr/PR into the internal package, then aim plugins install <Pkg>
   • external → push to the public code host, then aim plugins install / bash install.sh