bmad-method 6.7.1-next.1 → 6.7.1-next.2

package/.claude-plugin/marketplace.json

@@ -20,7 +20,7 @@
       "skills": [
         "./src/core-skills/bmad-help",
         "./src/core-skills/bmad-brainstorming",
-        "./src/core-skills/bmad-distillator",
+        "./src/core-skills/bmad-spec",
         "./src/core-skills/bmad-party-mode",
         "./src/core-skills/bmad-shard-doc",
         "./src/core-skills/bmad-advanced-elicitation",

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-method",
-  "version": "6.7.1-next.1",
+  "version": "6.7.1-next.2",
   "description": "Breakthrough Method of Agile AI-driven Development",
   "keywords": [
     "agile",

package/removals.txt

@@ -52,3 +52,8 @@ bmad-bmm-sprint-planning
 bmad-bmm-sprint-status
 bmad-bmm-technical-research
 bmad-bmm-validate-prd
+
+# Removed skills (post-v6.7.x)
+# bmad-distillator: superseded by bmad-spec (universal intent distiller with
+# preservation-validated contract for downstream skills).
+bmad-distillator

package/src/core-skills/bmad-spec/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: bmad-spec
+description: Distill any intent input into the SPEC kernel + companions — the canonical, preservation-validated machine contract for downstream work. Use when the user says "create a spec", "distill this into a spec", "validate this spec", or "update the spec".
+---
+
+# BMad Spec
+## Overview
+
+Canonical transformer for the BMad spec-kernel ecosystem. Takes any intent input — vague idea, brain dump, PRD, GDD, RFC, brief, Slack thread, customer email, meeting transcript, mockups, mixed multi-source — and produces **SPEC.md** carrying the five-field kernel (Why, Capabilities, Constraints, Non-goals, Success signal) plus companion files for load-bearing content that does not fit or would bloat the kernel with expansive line-item detail. Together they are the machine contract every downstream BMad skill consumes.
+
+Multiple skills may call to update the same spec over time.
+
+## Conventions
+
+- Bare paths (e.g. `assets/spec-template.md`) resolve from the skill root.
+- `{skill-root}` is this skill's install dir; `{project-root}` is the working dir.
+- `{workflow.<name>}` resolves to fields in `customize.toml`.
+
+## On Activation
+
+1. Resolve customization: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. On failure, read `{skill-root}/customize.toml` directly.
+2. Run `{workflow.activation_steps_prepend}`. Treat `{workflow.persistent_facts}` as foundational context (`file:` entries are loaded).
+3. Load `{project-root}/_bmad/core/config.yaml` (and `config.user.yaml` if present), root level and `bmm` section. Resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{planning_artifacts}`, `{project_name}`, `{date}`.
+4. Detect mode. **Headless** when any of: no TTY, programmatic caller (another skill or non-interactive runner), or the first message pre-supplies all inputs and asks for an artifact path back. **Interactive** otherwise. In interactive mode, greet by `{user_name}` in `{communication_language}`, stay in that language, and mention that `bmad-party-mode` and `bmad-advanced-elicitation` are available for deeper exploration on any field.
+5. Run `{workflow.activation_steps_append}`.
+
+## Workspace
+
+The spec is **always a folder** named `{workflow.spec_output_path}/{workflow.run_folder_pattern}`, resolving by default to `{output_folder}/specs/spec-{slug}/`.
+
+`{slug}` describes the thing being specced, not the input shape:
+
+- Source artifact already carries a slug (e.g., `prd-foo-bar-2026-05-23/`): inherit (`foo-bar`).
+- Sparse, in-chat, or multi-source input: interactive asks; headless caller provides it as part of the input. If absent and underivable, headless blocks with `error_code: "missing_slug"`.
+- Same slug = same folder. A second invocation with the same `{slug}` lands at the existing spec folder and updates in place, preserving capability IDs.
+
+**No input.** Interactive: ask the user to share a file path, paste content, explain the idea in detail, or point to a source. Headless: respond with JSON containing `error_code: "insufficient_intent"`.
+
+Inside the spec folder:
+
+```
+<spec-folder>/
+  SPEC.md                  ← uppercase, the kernel
+  <companion-1>.md         ← optional, content-typed (e.g. glossary.md)
+  <companion-2>.md
+  .decision-log.md         ← canonical memory for this spec
+```
+
+## The Operation
+
+Read the input and its ancillary linked materials. If there is no input, follow the no-input branch in **Workspace** (ask or block). If a prior `SPEC.md` exists at the target folder, read it too — the operation becomes an update. Preserve capability IDs; new capabilities get the next unused `CAP-N`; never reuse retired IDs. Otherwise this is a create.
+
+When the input is structured and pre-sorted (a PRD with an addendum, a GDD, a brief produced by an upstream BMad skill), trust the authored separation: lift kernel-fitting content into SPEC.md, lift overflow into appropriately-named companions. When the input is mixed (a brain dump, a transcript, an RFC, a customer email), do the sorting yourself: walk each claim, apply the three-lens load-bearing test (Spec Law rule 7), and route to the kernel field or a companion.
+
+Distill the input into the five-field kernel using `{workflow.spec_template}` as the skeleton. When input is rich, extract directly — no elicitation. When input is sparse, choose: **express** (best-effort distill, every gap becomes an `open_questions[]` entry) or **guided** (walk the five fields with the user one at a time). Headless defaults to express and logs the choice. Interactive asks.
+
+Write lean from the first pass: every sentence must earn its place. Decoration costs tokens and dilutes downstream readers.
+
+If the input is genuinely too thin to distill (e.g. "an app for hikers" with no surrounding context), stop and suggest `bmad-prd` (or sibling ceremony skill). This skill distills; it does not coach.
+
+## Load-bearing
+
+A claim is **load-bearing** if any consumer (downstream skill, implementing agent, verification pass) would change a decision without it.
+
+## Companions
+
+When load-bearing content does not fit the five-field kernel, it lives in a companion. The kernel cites it; the companion holds it. Companions are part of the contract; every consumer reads `companions:` in SPEC.md frontmatter to discover them. Companions follow the same lean discipline as SPEC.md (Spec Law rule 8).
+
+**Spawn a companion when the content needs more than one kernel-shape line:** multi-item catalogs (per-entity matrices like archetypes, drinks, modes, routes), tables, diagrams (always), editorial voice rules, long-form reference material the kernel cites by name (glossary, brownfield notes, project conventions). Single-line decision-benders stay in Constraints; intent+success pairs stay in Capabilities. If a kernel field is starting to bullet into sub-bullets, the content has outgrown the kernel and wants a companion.
+
+Companions are either:
+
+- **Spec-authored** companions are written by bmad-spec and live as **siblings of SPEC.md** (e.g., `glossary.md`, `patron-archetypes.md`). bmad-spec owns them and may edit them on update operations.
+- **Adopted** companions are load-bearing artifacts written by an upstream skill that downstream still needs to read. bmad-spec references them into `companions:` by relative path but does NOT edit them (e.g., a `DESIGN.md` or `EXPERIENCE.md` from a UX run, an integration partner's API spec). The originating skill owns them.
+
+Two rules govern companions:
+
+1. **Name spec-authored companions for the content type they hold.** `glossary.md`, `<entity-class>.md` (e.g. `patron-archetypes.md`, `medication-routes.md`, `flight-modes.md`), `stack.md`, `conventions.md`, `brownfield.md`, `architecture-diagrams.md`, `state-machines.md`, `failure-modes.md`, `compliance-references.md`. The principle: "a reader should know what is inside before opening it." Adopted companions keep whatever name their originating skill gave them.
+2. **Diagrams always land in a companion**, regardless of size. SPEC.md kernel holds prose only. Mermaid blocks, ASCII diagrams, and image references all live in a companion (e.g. `architecture-diagrams.md`), with sibling image files referenced from there.
+
+Pre-existing project-wide docs (e.g. `project-context.md`) that downstream needs are listed as **adopted companions**, never duplicated into SPEC.md or a spec-authored companion.
+
+## Spec Law
+
+Every spec must satisfy these eight rules. The operation aims for them; the self-validate sweep enforces them.
+
+1. **Each capability has both `intent` and `success`.** Missing either = not a capability.
+2. **Intents describe WHAT, not HOW.** Implementation prescription belongs in a companion (stack, conventions).
+3. **Constraints actually bend design decisions.** A "constraint" that rules nothing out is decoration.
+4. **Non-goals are explicit.** At least one. Absence means downstream skills fill the vacuum.
+5. **Success signal is concrete enough to test or demonstrate against.** "Users love it" doesn't qualify.
+6. **Capability IDs are stable and unique.** Never reused, never renumbered.
+7. **Preservation.** Every load-bearing source claim lands in SPEC.md or a companion. Wrapper ceremony does not.
+8. **Lean prose.** Every sentence carries load-bearing content. Cut decoration, hedges, backstory, throat-clearing. Applies to SPEC.md, companions, and `.decision-log.md`.
+
+## Self-Validate
+
+After every create or update, sweep the resulting artifact in **two passes** before presenting.
+
+**Pass 1 — Coherence.** Judge the spec against Spec Law rules 1–6 and 8. For anything that fails or feels weak, attempt to fix it without inventing content the input did not support. Calls made without direct confirmation become `assumptions[]`; gaps that could not be filled become `open_questions[]`.
+
+**Pass 2 — Preservation.** Walk the source claim by claim. Confirm each load-bearing claim landed in SPEC.md or a companion. Wrapper-ceremony drops are logged under "Wrapper-only content" so the drop is on the record, not silent.
+
+Append a one-paragraph verdict to `.decision-log.md` covering both passes. In interactive mode, review the verdict with the user. In headless mode, `.decision-log.md` is one of the files returned, so the caller (or its downstream LLM) reads the verdict there.
+
+## Spec with no change signal
+
+When the user points the skill at an existing spec folder (or its SPEC.md) with no change signal, offer to review assumptions or open questions, or determine what they want to do.
+
+## Output
+
+**Interactive** — share the spec folder path conversationally. Name the capability count, the companions produced, and the verdict in one or two sentences. If `assumptions[]` or `open_questions[]` are non-empty, list them (short — one line each) and invite the user to walk through them. Make clear that addressing them can update the source input (if it was a file), the spec, or both — whichever combination the user prefers. Do not dump JSON or present a wall of output.
+
+**Headless** — return JSON per `assets/headless-schemas.md`.
+
+Run `{workflow.on_complete}` if set.
+
+## After Spec is Output
+
+Any update to spec regarding assumptions, open questions, or other changes should be appended to that source's decision log also and offer to update the source.
+
+## Frontmatter conventions
+
+- `companions:` array of `.md` files downstream MUST read alongside SPEC.md to have the full contract. Paths may point inside the spec folder (spec-authored companions like `glossary.md`) or outside it (adopted companions like `../planning-artifacts/ux-designs/ux-foo-bar-2026-05-23/DESIGN.md`). The split between spec-authored and adopted is implicit by path; downstream treats both the same.
+- `sources:` array of paths to files that were **fully absorbed** into the SPEC, with no remaining downstream value (e.g., a PRD whose every load-bearing claim is now in the kernel). Listed for audit and for bmad-spec to re-read on update. Downstream does NOT read these. Files that downstream still needs to read belong in `companions:`, not here.
+- **Do not list** decision logs, README files, organizational artifacts, or any operational record of how upstream skills produced their artifacts. Those are not source content; they are process metadata that downstream consumers don't need.

package/src/core-skills/bmad-spec/assets/headless-schemas.md

@@ -0,0 +1,33 @@
+# Headless JSON Response
+
+The default invocation is headless: input goes in, JSON comes out. The contract is intentionally tiny — return the outcome and the files touched. Anything else a caller needs is inside those files (SPEC.md, companions, `.decision-log.md`).
+
+## Success
+
+```json
+{
+  "status": "complete",
+  "files": [
+    "_bmad-output/specs/spec-quarter-drop/SPEC.md",
+    "_bmad-output/specs/spec-quarter-drop/glossary.md",
+    "_bmad-output/specs/spec-quarter-drop/.decision-log.md"
+  ]
+}
+```
+
+`files` lists every file written or modified in this run, in any order. The spec folder, kernel filename, decision log location, capabilities, companions, and verdict are all readable from those files; no need to re-encode them in the response.
+
+## Blocked
+
+```json
+{
+  "status": "blocked",
+  "error_code": "insufficient_intent",
+  "reason": "Input was a one-line idea with no surrounding context; too thin to distill. Suggest bmad-prd to draw the vision out first."
+}
+```
+
+Defined `error_code` values:
+
+- `insufficient_intent` — input too thin to distill into a kernel.
+- `missing_slug` — input is sparse or multi-source and no slug was provided by the caller or derivable from a source path.

package/src/core-skills/bmad-spec/assets/spec-template.md

@@ -0,0 +1,49 @@
+---
+id: SPEC-{slug}
+companions: []     # files downstream MUST read alongside SPEC.md. Paths may point inside the spec folder (spec-authored) or outside it (adopted from an upstream skill).
+sources: []        # files fully absorbed into the SPEC (audit only; downstream does NOT read these). Never decision logs.
+---
+
+> **Canonical contract.** This SPEC and the files in `companions:` are the complete, preservation-validated contract for what to build, test, and validate. Source documents listed in frontmatter are for traceability only — consult them only if you need narrative rationale or prose color this contract intentionally omits.
+
+# {Spec Title}
+
+## Why
+
+{One paragraph naming the force behind this work. A spec can exist for any of:
+  - **a pain to solve** — a user or operator is stuck on a specific gap;
+  - **an opportunity to capture** — something newly possible we want to claim;
+  - **a vision to realize** — a thing we want to make exist because we want it to exist;
+  - **a mandate to meet** — a regulation, deprecation, deadline, or contractual obligation.
+
+Name which (or which combination) applies, who is affected, and the backdrop that makes it matter now. This is the anchor every downstream trade-off resolves against.}
+
+## Capabilities
+
+- id: CAP-1
+  intent: {One sentence. "User or system can do X to achieve Y." WHAT, not HOW.}
+  success: {Testable or demonstrable criterion. Something a test or a real demonstration can decide.}
+
+## Constraints
+
+- {A non-negotiable that bends design. If it doesn't rule anything out, it doesn't belong.}
+
+## Non-goals
+
+- {Explicit out-of-scope item. At least one. Stops downstream from filling the vacuum.}
+
+## Success signal
+
+- {One or two sentences. World-change moment, not dashboard. Concrete enough to write a test or run a demonstration against.}
+
+## Assumptions
+
+<!-- Optional. Omit this section entirely if empty. Inferred calls made without direct confirmation from the input. -->
+
+- {Statement of fact the Spec proceeded under, e.g. "Assumed mobile-first since input mentioned GPS but no platform."}
+
+## Open Questions
+
+<!-- Optional. Omit this section entirely if empty. Gaps the input did not resolve that need a human decision before downstream skills consume the Spec. -->
+
+- {Question phrased so a human can answer it, e.g. "Is offline playback in scope for CAP-2?"}

package/src/core-skills/bmad-spec/customize.toml

@@ -0,0 +1,53 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-spec.
+#
+# Override files (not edited here):
+#   {project-root}/_bmad/custom/bmad-spec.toml        (team)
+#   {project-root}/_bmad/custom/bmad-spec.user.toml   (personal)
+
+[workflow]
+
+# --- Configurable below. Overrides merge per BMad structural rules: ---
+#   scalars: override wins • arrays: append
+
+# Steps to run before the standard activation (config load, greet).
+activation_steps_prepend = []
+
+# Steps to run after greet but before the operation begins.
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run.
+# Each entry is either a literal sentence, a skill prefixed with `skill:`,
+# or a `file:`-prefixed path/glob whose contents are loaded as facts.
+# Default points to a single top-level file; override in team/user TOML
+# to widen the scope (e.g. `_bmad/**/project-context.md`) if needed.
+persistent_facts = [
+  "file:{project-root}/project-context.md",
+]
+
+# Executed when the workflow completes. Scalar or array of instructions.
+on_complete = ""
+
+# Spec template. The five-field kernel skeleton. Override the path in
+# team/user TOML to enforce a different shape (e.g. a hypothesis field
+# for research initiatives, or a mechanics field for games).
+spec_template = "assets/spec-template.md"
+
+# Canonical filename for the kernel artifact inside the spec folder.
+# Uppercase by convention to signal "the central source of truth."
+spec_filename = "SPEC.md"
+
+# Output path for spec folders. Lands directly under {output_folder}
+# so bmad-spec works in core-only installs and matches the
+# long-term BMad direction of grouping artifacts as siblings under
+# {output_folder}/<type>/ rather than nested inside planning vs
+# implementation folders.
+spec_output_path = "{output_folder}/specs"
+
+# Run-folder pattern inside spec_output_path. Resolved against the
+# input-derived slug at activation. Same slug = same folder, so a
+# second invocation updates the existing spec in place (capability
+# IDs preserved). Override to add {date} or other components if a
+# fresh dated history is preferred.
+run_folder_pattern = "spec-{slug}"

package/src/core-skills/module-help.csv

@@ -9,5 +9,5 @@ Core,bmad-editorial-review-prose,Editorial Review - Prose,EP,Use after drafting
 Core,bmad-editorial-review-structure,Editorial Review - Structure,ES,Use when doc produced from multiple subprocesses or needs structural improvement.,,[path],anytime,,,false,report located with target document,
 Core,bmad-review-adversarial-general,Adversarial Review,AR,"Use for quality assurance or before finalizing deliverables. Code Review in other modules runs this automatically, but also useful for document reviews.",,[path],anytime,,,false,,
 Core,bmad-review-edge-case-hunter,Edge Case Hunter Review,ECH,Use alongside adversarial review for orthogonal coverage — method-driven not attitude-driven.,,[path],anytime,,,false,,
-Core,bmad-distillator,Distillator,DG,Use when you need token-efficient distillates that preserve all information for downstream LLM consumption.,,[path],anytime,,,false,adjacent to source document or specified output_path,distillate markdown file(s)
+Core,bmad-spec,Spec,SP,"Use to distill any intent input (brief, PRD, transcript, brain dump, design folder, mixed multi-source) into a succinct, no-fluff SPEC.md contract + companions that downstream work derives from. Locks the WHAT before the HOW. Works for software, game design, research, editorial, policy, business, anything intent-bearing. Validation mode also available.",,[path],anytime,,,false,{output_folder}/specs/spec-{slug},SPEC.md + companion files
 Core,bmad-customize,BMad Customize,BC,"Use when you want to change how an agent or workflow behaves — add persistent facts, swap templates, insert activation hooks, or customize menus. Scans what's customizable, picks the right scope (agent vs workflow), writes the override to _bmad/custom/, and verifies the merge. No TOML hand-authoring required.",,,anytime,,,false,{project-root}/_bmad/custom,TOML override files

package/src/core-skills/bmad-distillator/SKILL.md

@@ -1,177 +0,0 @@
----
-name: bmad-distillator
-description: Lossless LLM-optimized compression of source documents. Use when the user requests to 'distill documents' or 'create a distillate'.
----
-
-# Distillator: A Document Distillation Engine
-
-## Overview
-
-This skill produces hyper-compressed, token-efficient documents (distillates) from any set of source documents. A distillate preserves every fact, decision, constraint, and relationship from the sources while stripping all overhead that humans need and LLMs don't. Act as an information extraction and compression specialist. The output is a single dense document (or semantically-split set) that a downstream LLM workflow can consume as sole context input without information loss.
-
-This is a compression task, not a summarization task. Summaries are lossy. Distillates are lossless compression optimized for LLM consumption.
-
-## On Activation
-
-1. **Validate inputs.** The caller must provide:
-   - **source_documents** (required) — One or more file paths, folder paths, or glob patterns to distill
-   - **downstream_consumer** (optional) — What workflow/agent consumes this distillate (e.g., "PRD creation", "architecture design"). When provided, use it to judge signal vs noise. When omitted, preserve everything.
-   - **token_budget** (optional) — Approximate target size. When provided and the distillate would exceed it, trigger semantic splitting.
-   - **output_path** (optional) — Where to save. When omitted, save adjacent to the primary source document with `-distillate.md` suffix.
-   - **--validate** (flag) — Run round-trip reconstruction test after producing the distillate.
-
-2. **Route** — proceed to Stage 1.
-
-## Stages
-
-| # | Stage | Purpose |
-|---|-------|---------|
-| 1 | Analyze | Run analysis script, determine routing and splitting |
-| 2 | Compress | Spawn compressor agent(s) to produce the distillate |
-| 3 | Verify & Output | Completeness check, format check, save output |
-| 4 | Round-Trip Validate | (--validate only) Reconstruct and diff against originals |
-
-### Stage 1: Analyze
-
-Run `scripts/analyze_sources.py --help` then run it with the source paths. Use its routing recommendation and grouping output to drive Stage 2. Do NOT read the source documents yourself.
-
-### Stage 2: Compress
-
-**Single mode** (routing = `"single"`, ≤3 files, ≤15K estimated tokens):
-
-Spawn one subagent using `agents/distillate-compressor.md` with all source file paths.
-
-**Fan-out mode** (routing = `"fan-out"`):
-
-1. Spawn one compressor subagent per group from the analysis output. Each compressor receives only its group's file paths and produces an intermediate distillate.
-
-2. After all compressors return, spawn one final **merge compressor** subagent using `agents/distillate-compressor.md`. Pass it the intermediate distillate contents as its input (not the original files). Its job is cross-group deduplication, thematic regrouping, and final compression.
-
-3. Clean up intermediate distillate content (it exists only in memory, not saved to disk).
-
-**Graceful degradation:** If subagent spawning is unavailable, read the source documents and perform the compression work directly using the same instructions from `agents/distillate-compressor.md`. For fan-out, process groups sequentially then merge.
-
-The compressor returns a structured JSON result containing the distillate content, source headings, named entities, and token estimate.
-
-### Stage 3: Verify & Output
-
-After the compressor (or merge compressor) returns:
-
-1. **Completeness check.** Using the headings and named entities list returned by the compressor, verify each appears in the distillate content. If gaps are found, send them back to the compressor for a targeted fix pass — not a full recompression. Limit to 2 fix passes maximum.
-
-2. **Format check.** Verify the output follows distillate format rules:
-   - No prose paragraphs (only bullets)
-   - No decorative formatting
-   - No repeated information
-   - Each bullet is self-contained
-   - Themes are clearly delineated with `##` headings
-
-3. **Determine output format.** Using the split prediction from Stage 1 and actual distillate size:
-
-   **Single distillate** (≤~5,000 tokens or token_budget not exceeded):
-
-   Save as a single file with frontmatter:
-
-   ```yaml
-   ---
-   type: bmad-distillate
-   sources:
-     - "{relative path to source file 1}"
-     - "{relative path to source file 2}"
-   downstream_consumer: "{consumer or 'general'}"
-   created: "{date}"
-   token_estimate: {approximate token count}
-   parts: 1
-   ---
-   ```
-
-   **Split distillate** (>~5,000 tokens, or token_budget requires it):
-
-   Create a folder `{base-name}-distillate/` containing:
-
-   ```
-   {base-name}-distillate/
-   ├── _index.md           # Orientation, cross-cutting items, section manifest
-   ├── 01-{topic-slug}.md  # Self-contained section
-   ├── 02-{topic-slug}.md
-   └── 03-{topic-slug}.md
-   ```
-
-   The `_index.md` contains:
-   - Frontmatter with sources (relative paths from the distillate folder to the originals)
-   - 3-5 bullet orientation (what was distilled, from what)
-   - Section manifest: each section's filename + 1-line description
-   - Cross-cutting items that span multiple sections
-
-   Each section file is self-contained — loadable independently. Include a 1-line context header: "This section covers [topic]. Part N of M."
-
-   Source paths in frontmatter must be relative to the distillate's location.
-
-4. **Measure distillate.** Run `scripts/analyze_sources.py` on the final distillate file(s) to get accurate token counts for the output. Use the `total_estimated_tokens` from this analysis as `distillate_total_tokens`.
-
-5. **Report results.** Always return structured JSON output:
-
-   ```json
-   {
-     "status": "complete",
-     "distillate": "{path or folder path}",
-     "section_distillates": ["{path1}", "{path2}"] or null,
-     "source_total_tokens": N,
-     "distillate_total_tokens": N,
-     "compression_ratio": "X:1",
-     "source_documents": ["{path1}", "{path2}"],
-     "completeness_check": "pass" or "pass_with_additions"
-   }
-   ```
-
-   Where `source_total_tokens` is from the Stage 1 analysis and `distillate_total_tokens` is from step 4. The `compression_ratio` is `source_total_tokens / distillate_total_tokens` formatted as "X:1" (e.g., "3.2:1").
-
-6. If `--validate` flag was set, proceed to Stage 4. Otherwise, done.
-
-### Stage 4: Round-Trip Validation (--validate only)
-
-This stage proves the distillate is lossless by reconstructing source documents from the distillate alone. Use for critical documents where information loss is unacceptable, or as a quality gate for high-stakes downstream workflows. Not for routine use — it adds significant token cost.
-
-1. **Spawn the reconstructor agent** using `agents/round-trip-reconstructor.md`. Pass it ONLY the distillate file path (or `_index.md` path for split distillates) — it must NOT have access to the original source documents.
-
-   For split distillates, spawn one reconstructor per section in parallel. Each receives its section file plus the `_index.md` for cross-cutting context.
-
-   **Graceful degradation:** If subagent spawning is unavailable, this stage cannot be performed by the main agent (it has already seen the originals). Report that round-trip validation requires subagent support and skip.
-
-2. **Receive reconstructions.** The reconstructor returns reconstruction file paths saved adjacent to the distillate.
-
-3. **Perform semantic diff.** Read both the original source documents and the reconstructions. For each section of the original, assess:
-   - Is the core information present in the reconstruction?
-   - Are specific details preserved (numbers, names, decisions)?
-   - Are relationships and rationale intact?
-   - Did the reconstruction add anything not in the original? (indicates hallucination filling gaps)
-
-4. **Produce validation report** saved adjacent to the distillate as `-validation-report.md`:
-
-   ```markdown
-   ---
-   type: distillate-validation
-   distillate: "{distillate path}"
-   sources: ["{source paths}"]
-   created: "{date}"
-   ---
-
-   ## Validation Summary
-   - Status: PASS | PASS_WITH_WARNINGS | FAIL
-   - Information preserved: {percentage estimate}
-   - Gaps found: {count}
-   - Hallucinations detected: {count}
-
-   ## Gaps (information in originals but missing from reconstruction)
-   - {gap description} — Source: {which original}, Section: {where}
-
-   ## Hallucinations (information in reconstruction not traceable to originals)
-   - {hallucination description} — appears to fill gap in: {section}
-
-   ## Possible Gap Markers (flagged by reconstructor)
-   - {marker description}
-   ```
-
-5. **If gaps are found**, offer to run a targeted fix pass on the distillate — adding the missing information without full recompression. Limit to 2 fix passes maximum.
-
-6. **Clean up** — delete the temporary reconstruction files after the report is generated.

package/src/core-skills/bmad-distillator/agents/distillate-compressor.md

@@ -1,116 +0,0 @@
-# Distillate Compressor Agent
-
-Act as an information extraction and compression specialist. Your sole purpose is to produce a lossless, token-efficient distillate from source documents.
-
-You receive: source document file paths, an optional downstream_consumer context, and a splitting decision.
-
-You must load and apply `../resources/compression-rules.md` before producing output. Reference `../resources/distillate-format-reference.md` for the expected output format.
-
-## Compression Process
-
-### Step 1: Read Sources
-
-Read all source document files. For each, note the document type (product brief, discovery notes, research report, architecture doc, PRD, etc.) based on content and naming.
-
-### Step 2: Extract
-
-Extract every discrete piece of information from all source documents:
-- Facts and data points (numbers, dates, versions, percentages)
-- Decisions made and their rationale
-- Rejected alternatives and why they were rejected
-- Requirements and constraints (explicit and implicit)
-- Relationships and dependencies between entities
-- Named entities (products, companies, people, technologies)
-- Open questions and unresolved items
-- Scope boundaries (in/out/deferred)
-- Success criteria and validation methods
-- Risks and opportunities
-- User segments and their success definitions
-
-Treat this as entity extraction — pull out every distinct piece of information regardless of where it appears in the source documents.
-
-### Step 3: Deduplicate
-
-Apply the deduplication rules from `../resources/compression-rules.md`.
-
-### Step 4: Filter (only if downstream_consumer is specified)
-
-For each extracted item, ask: "Would the downstream workflow need this?"
-- Drop items that are clearly irrelevant to the stated consumer
-- When uncertain, keep the item — err on the side of preservation
-- Never drop: decisions, rejected alternatives, open questions, constraints, scope boundaries
-
-### Step 5: Group Thematically
-
-Organize items into coherent themes derived from the source content — not from a fixed template. The themes should reflect what the documents are actually about.
-
-Common groupings (use what fits, omit what doesn't, add what's needed):
-- Core concept / problem / motivation
-- Solution / approach / architecture
-- Users / segments
-- Technical decisions / constraints
-- Scope boundaries (in/out/deferred)
-- Competitive context
-- Success criteria
-- Rejected alternatives
-- Open questions
-- Risks and opportunities
-
-### Step 6: Compress Language
-
-For each item, apply the compression rules from `../resources/compression-rules.md`:
-- Strip prose transitions and connective tissue
-- Remove hedging and rhetoric
-- Remove explanations of common knowledge
-- Preserve specific details (numbers, names, versions, dates)
-- Ensure the item is self-contained (understandable without reading the source)
-- Make relationships explicit ("X because Y", "X blocks Y", "X replaces Y")
-
-### Step 7: Format Output
-
-Produce the distillate as dense thematically-grouped bullets:
-- `##` headings for themes — no deeper heading levels needed
-- `- ` bullets for items — every token must carry signal
-- No decorative formatting (no bold for emphasis, no horizontal rules)
-- No prose paragraphs — only bullets
-- Semicolons to join closely related short items within a single bullet
-- Each bullet self-contained — understandable without reading other bullets
-
-Do NOT include frontmatter — the calling skill handles that.
-
-## Semantic Splitting
-
-If the splitting decision indicates splitting is needed, load `../resources/splitting-strategy.md` and follow it.
-
-When splitting:
-
-1. Identify natural semantic boundaries in the content — coherent topic clusters, not arbitrary size breaks.
-
-2. Produce a **root distillate** containing:
-   - 3-5 bullet orientation (what was distilled, for whom, how many parts)
-   - Cross-references to section distillates
-   - Items that span multiple sections
-
-3. Produce **section distillates**, each self-sufficient. Include a 1-line context header: "This section covers [topic]. Part N of M from [source document names]."
-
-## Return Format
-
-Return a structured result to the calling skill:
-
-```json
-{
-  "distillate_content": "{the complete distillate text without frontmatter}",
-  "source_headings": ["heading 1", "heading 2"],
-  "source_named_entities": ["entity 1", "entity 2"],
-  "token_estimate": N,
-  "sections": null or [{"topic": "...", "content": "..."}]
-}
-```
-
-- **distillate_content**: The full distillate text
-- **source_headings**: All Level 2+ headings found across source documents (for completeness verification)
-- **source_named_entities**: Key named entities (products, companies, people, technologies, decisions) found in sources
-- **token_estimate**: Approximate token count of the distillate
-- **sections**: null for single distillates; array of section objects if semantically split
-
-Do not include conversational text, status updates, or preamble — return only the structured result.