drt-method 1.0.0

package/src/core-skills/drt-customize/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: drt-customize
+description: Authors and updates customization overrides for installed DRT skills. Use when the user says 'customize drt', 'override a skill', 'change agent behavior', or 'customize a workflow'.
+---
+
+# DRT Customize
+
+Translate the user's intent into a correctly-placed TOML override file under `{project-root}/_drt/custom/` for a customizable agent or workflow skill. Discover, route, author, write, verify.
+
+Scope v1: per-skill `[agent]` overrides (`drt-agent-<role>.toml` / `.user.toml`) and per-skill `[workflow]` overrides (`drt-<workflow>.toml` / `.user.toml`). Central config (`{project-root}/_drt/custom/config.toml`) is out of scope — point users at the customize guide in the project docs.
+
+When the target's `customize.toml` doesn't expose what the user wants, say so plainly. Don't invent fields.
+
+## Preflight
+
+- No `{project-root}/_drt/` → DRT isn't installed. Say so, stop.
+- `{project-root}/_drt/scripts/resolve-customization.js` missing → continue, but Step 6 verify falls back to manual merge.
+- Both present → proceed.
+
+## Activation
+
+Load `_drt/config.toml` and `_drt/config.user.toml` from `{project-root}` for `user_name` (default `DRT`) and `communication_language` (default `English`). Greet. If the user's invocation already names a target skill AND a specific change, jump to Step 3.
+
+## Step 1: Classify intent
+
+- **Directed** — specific skill + specific change → Step 3.
+- **Exploratory** — "what can I customize?" → Step 2.
+- **Audit/iterate** — wants to review or change something already customized → Step 2, lead with skills that have existing overrides; read the existing override in Step 3 before composing.
+- **Cross-cutting** — could live on multiple surfaces → Step 3, choose agent vs workflow explicitly with the user.
+
+## Step 2: Discovery
+
+```
+python3 {skill-root}/scripts/list_customizable_skills.py --project-root {project-root}
+```
+
+Use `--extra-root <path>` (repeatable) if the user has skills installed in additional locations.
+
+Group the returned `agents` and `workflows` for the user; for each show name, description, whether `has_team_override` or `has_user_override` is true. Surface any `errors[]`. For audit/iterate intents, lead with already-overridden entries.
+
+Empty list: show `scanned_roots`, ask whether skills live elsewhere (offer `--extra-root`); otherwise stop.
+
+## Step 3: Determine the right surface
+
+Read the target's `customize.toml`. Top-level `[agent]` or `[workflow]` block defines the surface.
+
+If a team or user override already exists, read it first and summarize what's already overridden before composing.
+
+**Cross-cutting intent — walk both surfaces with the user:**
+- Every workflow a given agent runs → agent surface (e.g. `drt-agent-pm.toml` with `persistent_facts`, `principles`).
+- One workflow only → workflow surface (e.g. `drt-prd.toml` with `activation_steps_prepend`).
+- Several specific workflows → multiple workflow overrides in sequence, not an agent override.
+
+**Single-surface heuristic:**
+- Workflow-level: template swap, output path, step-specific behavior, or a named scalar already exposed (`*_template`, `on_complete`). Surgical, reliable.
+- Agent-level: persona, communication style, org-wide facts, menu changes, behavior that should apply to every workflow the agent dispatches.
+
+When ambiguous, present both with tradeoff, recommend one, let the user decide.
+
+Intent outside the exposed surface (step logic, ordering, anything not in `customize.toml`): say so; offer `activation_steps_prepend`/`append` or `persistent_facts` as approximations, or recommend `drt-builder` to create a custom skill.
+
+## Step 4: Compose the override
+
+Translate plain-English into TOML against the target's `customize.toml` fields. If an existing override was read, frame the change as additive.
+
+Merge semantics:
+- **Scalars** (`icon`, `role`, `*_template`, `on_complete`) — override wins.
+- **Append arrays** (`persistent_facts`, `activation_steps_prepend`/`append`, `principles`) — team/user entries append in order.
+- **Keyed arrays of tables** (menu items with `code` or `id`) — matching keys replace, new keys append.
+
+Overrides are sparse: only the fields being changed. Never copy the whole `customize.toml`.
+
+**Template swap** (`*_template` scalar): offer to copy the default template to `{project-root}/_drt/custom/{skill-name}-{purpose}-template.md`, point the override at the new path, offer to help edit it.
+
+## Step 5: Team or user placement
+
+Under `{project-root}/_drt/custom/`:
+- `{skill-name}.toml` — team, committed. Policies, org conventions, compliance.
+- `{skill-name}.user.toml` — user, gitignored. Personal tone, private facts, shortcuts.
+
+Default by character (policy → team, personal → user), confirm before writing.
+
+## Step 6: Show, confirm, write, verify
+
+1. Show the full TOML. If the file exists, show a diff. Never silently overwrite.
+2. Wait for explicit yes.
+3. Write. Create `{project-root}/_drt/custom/` if needed.
+4. Verify:
+   ```
+   node {project-root}/_drt/scripts/resolve-customization.js --skill <install-path> --key <agent-or-workflow>
+   ```
+   Show the merged output, point out the changed fields.
+
+   **Resolver missing or fails:** read whichever layers exist — `<install-path>/customize.toml` (base), `{project-root}/_drt/custom/{skill-name}.toml` (team), `{project-root}/_drt/custom/{skill-name}.user.toml` (user) — apply base → team → user with the same merge rules (scalars override, tables deep-merge, `code`/`id`-keyed arrays merge by key, all other arrays append), describe how the changed fields resolve.
+
+   **Verify shows override didn't land** (field unchanged, merge conflict, file not picked up): re-enter Step 4 with the verify output as context. Usually wrong field name, wrong merge mode (scalar vs array), or wrong scope.
+5. Summarize what changed, where the file lives, how to iterate. Remind the user to commit team overrides.
+
+## Complete when
+
+- Override file written (or user explicitly aborted).
+- User has seen resolver output (or manual fallback merge summary).
+- User has acknowledged the summary.
+
+Otherwise the skill isn't done — finish or tell the user they're exiting incomplete.
+
+## When this skill can't help
+
+- **Central config** (`{project-root}/_drt/custom/config.toml`) — see the customize guide in the project docs.
+- **Step logic, ordering, behavior not in `customize.toml`** — open a feature request, or use `drt-builder` to create a custom skill. Offer to help with either.
+- **Skills without a `customize.toml`** — not customizable.

package/src/core-skills/drt-customize/scripts/list_customizable_skills.py

@@ -0,0 +1,231 @@
+#!/usr/bin/env python3
+# /// script
+# requires-python = ">=3.11"
+# ///
+"""Enumerate customizable DRT skills installed alongside this one.
+
+Scans a skills directory (by default: the directory this script's own skill
+lives in, derived from __file__), finds every sibling directory containing a
+`customize.toml`, classifies each as agent and/or workflow based on its
+top-level blocks, reads the skill's SKILL.md frontmatter description for a
+one-liner, and checks whether override files already exist in
+`{project-root}/_drt/custom/`.
+
+Skills in DRT are loaded either from a project-local location (e.g. the
+project's `.claude/skills/` or `.cursor/skills/`) or from a user-global
+location (e.g. `~/.claude/skills/`). We do not hardcode those paths — the
+running skill's own location is the source of truth for sibling discovery.
+`--extra-root` is available for the rare case where skills live in multiple
+locations on the same machine.
+
+Output: JSON to stdout. Non-empty `errors[]` in the payload is non-fatal
+by contract — the scanner surfaces malformed TOML, missing roots, and
+skills with no customization block as data for the caller to display,
+and still exits 0. Exit 2 is reserved for invocation errors (e.g.
+missing or unreadable `--project-root`) where no useful payload can be
+produced.
+"""
+
+from __future__ import annotations
+
+import argparse
+import json
+import re
+import sys
+import tomllib
+from pathlib import Path
+
+# Top-level TOML blocks that indicate a customization surface.
+SURFACE_KEYS = ("agent", "workflow")
+
+FRONTMATTER_RE = re.compile(r"^---\s*\n(.*?)\n---\s*\n", re.DOTALL)
+
+
+def default_skills_root() -> Path:
+    """Derive the skills root from this script's location.
+
+    Layout assumption: {skills_root}/drt-customize/scripts/list_customizable_skills.py.
+    So the skills root is three parents up from this file.
+    """
+    return Path(__file__).resolve().parent.parent.parent
+
+
+def read_frontmatter_description(skill_md: Path) -> str:
+    """Extract the `description:` value from a SKILL.md YAML frontmatter block.
+
+    Returns an empty string if the file is missing, unreadable, or has no
+    description field. Intentionally permissive — this is metadata for a
+    human-facing list, not a validation target.
+    """
+    if not skill_md.is_file():
+        return ""
+    try:
+        text = skill_md.read_text(encoding="utf-8")
+    except (OSError, UnicodeDecodeError):
+        return ""
+    m = FRONTMATTER_RE.match(text)
+    if not m:
+        return ""
+    for line in m.group(1).splitlines():
+        stripped = line.strip()
+        if stripped.startswith("description:"):
+            value = stripped[len("description:") :].strip()
+            # Strip surrounding quotes if present.
+            if (value.startswith("'") and value.endswith("'")) or (
+                value.startswith('"') and value.endswith('"')
+            ):
+                value = value[1:-1]
+            return value
+    return ""
+
+
+def load_customize(toml_path: Path) -> dict | None:
+    """Return the parsed TOML, or None if unreadable."""
+    try:
+        with toml_path.open("rb") as f:
+            return tomllib.load(f)
+    except (OSError, tomllib.TOMLDecodeError):
+        return None
+
+
+def scan_skills(
+    skills_roots: list[Path],
+    project_root: Path,
+) -> dict:
+    """Scan each skills root for directories that contain a customize.toml."""
+    agents: list[dict] = []
+    workflows: list[dict] = []
+    errors: list[str] = []
+    scanned_roots: list[str] = []
+    seen_names: set[str] = set()
+    custom_dir = project_root / "_drt" / "custom"
+
+    for root in skills_roots:
+        if not root.is_dir():
+            errors.append(f"skills root does not exist: {root}")
+            continue
+        scanned_roots.append(str(root))
+
+        for skill_dir in sorted(p for p in root.iterdir() if p.is_dir()):
+            customize_toml = skill_dir / "customize.toml"
+            if not customize_toml.is_file():
+                continue
+
+            data = load_customize(customize_toml)
+            if data is None:
+                errors.append(f"failed to parse {customize_toml}")
+                continue
+
+            skill_name = skill_dir.name
+            # If a skill with this name was already found in an earlier
+            # root, skip it — roots are scanned in the order provided, so
+            # the first occurrence wins.
+            if skill_name in seen_names:
+                continue
+            seen_names.add(skill_name)
+
+            description = read_frontmatter_description(skill_dir / "SKILL.md")
+            team_override = custom_dir / f"{skill_name}.toml"
+            user_override = custom_dir / f"{skill_name}.user.toml"
+
+            entry_base = {
+                "name": skill_name,
+                "install_path": str(skill_dir),
+                "skills_root": str(root),
+                "description": description,
+                "has_team_override": team_override.is_file(),
+                "has_user_override": user_override.is_file(),
+                "team_override_path": str(team_override),
+                "user_override_path": str(user_override),
+            }
+
+            # A skill may expose an agent surface, a workflow surface, or
+            # both. Emit one entry per surface so the caller can group cleanly.
+            surfaces_found = [k for k in SURFACE_KEYS if k in data]
+            if not surfaces_found:
+                errors.append(
+                    f"no [agent] or [workflow] block in {customize_toml}"
+                )
+                continue
+            for surface in surfaces_found:
+                entry = dict(entry_base)
+                entry["surface"] = surface
+                if surface == "agent":
+                    agents.append(entry)
+                else:
+                    workflows.append(entry)
+
+    return {
+        "project_root": str(project_root),
+        "scanned_roots": scanned_roots,
+        "custom_dir": str(custom_dir),
+        "agents": agents,
+        "workflows": workflows,
+        "errors": errors,
+    }
+
+
+def parse_args(argv: list[str]) -> argparse.Namespace:
+    parser = argparse.ArgumentParser(
+        description=(
+            "List customizable DRT skills installed alongside this one, "
+            "grouped by surface (agent vs workflow), with override status "
+            "looked up against {project-root}/_drt/custom/."
+        )
+    )
+    parser.add_argument(
+        "--project-root",
+        required=True,
+        help="Absolute path to the project root (the folder containing _drt/).",
+    )
+    parser.add_argument(
+        "--skills-root",
+        default=None,
+        help=(
+            "Override the primary skills directory to scan. Defaults to the "
+            "directory this script's own skill lives in."
+        ),
+    )
+    parser.add_argument(
+        "--extra-root",
+        action="append",
+        default=[],
+        metavar="PATH",
+        help=(
+            "Additional skills directory to include (repeatable). Useful "
+            "when skills live in multiple locations on the same machine "
+            "(e.g. project-local plus a user-global install)."
+        ),
+    )
+    return parser.parse_args(argv)
+
+
+def main(argv: list[str]) -> int:
+    args = parse_args(argv)
+    project_root = Path(args.project_root).expanduser().resolve()
+    if not project_root.is_dir():
+        print(
+            f"error: project-root does not exist or is not a directory: {project_root}",
+            file=sys.stderr,
+        )
+        return 2
+
+    primary = (
+        Path(args.skills_root).expanduser().resolve()
+        if args.skills_root
+        else default_skills_root()
+    )
+    extras = [Path(p).expanduser().resolve() for p in args.extra_root]
+    # Deduplicate in order of appearance.
+    roots: list[Path] = []
+    for root in [primary, *extras]:
+        if root not in roots:
+            roots.append(root)
+
+    result = scan_skills(roots, project_root)
+    print(json.dumps(result, indent=2, sort_keys=True))
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main(sys.argv[1:]))

package/src/core-skills/drt-editorial-review-prose/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: drt-editorial-review-prose
+description: 'Clinical copy-editor that reviews text for communication issues. Use when user says review for prose or improve the prose'
+---
+
+# Editorial Review - Prose
+
+**Goal:** Review text for communication issues that impede comprehension and output suggested fixes in a three-column table.
+
+**Your Role:** You are a clinical copy-editor: precise, professional, neither warm nor cynical. Apply Microsoft Writing Style Guide principles as your baseline. Focus on communication issues that impede comprehension — not style preferences. NEVER rewrite for preference — only fix genuine issues. Follow ALL steps in the STEPS section IN EXACT ORDER. DO NOT skip steps or change the sequence. HALT immediately when halt-conditions are met. Each action within a step is a REQUIRED action to complete that step.
+
+**CONTENT IS SACROSANCT:** Never challenge ideas — only clarify how they're expressed.
+
+**Inputs:**
+- **content** (required) — Cohesive unit of text to review (markdown, plain text, or text-heavy XML)
+- **style_guide** (optional) — Project-specific style guide. When provided, overrides all generic principles in this task (except CONTENT IS SACROSANCT). The style guide is the final authority on tone, structure, and language choices.
+- **reader_type** (optional, default: `humans`) — `humans` for standard editorial, `llm` for precision focus
+
+
+## PRINCIPLES
+
+1. **Minimal intervention:** Apply the smallest fix that achieves clarity
+2. **Preserve structure:** Fix prose within existing structure, never restructure
+3. **Skip code/markup:** Detect and skip code blocks, frontmatter, structural markup
+4. **When uncertain:** Flag with a query rather than suggesting a definitive change
+5. **Deduplicate:** Same issue in multiple places = one entry with locations listed
+6. **No conflicts:** Merge overlapping fixes into single entries
+7. **Respect author voice:** Preserve intentional stylistic choices
+
+> **STYLE GUIDE OVERRIDE:** If a style_guide input is provided, it overrides ALL generic principles in this task (including the Microsoft Writing Style Guide baseline and reader_type-specific priorities). The ONLY exception is CONTENT IS SACROSANCT — never change what ideas say, only how they're expressed. When style guide conflicts with this task, style guide wins.
+
+
+## STEPS
+
+### Step 1: Validate Input
+
+- Check if content is empty or contains fewer than 3 words
+  - If empty or fewer than 3 words: **HALT** with error: "Content too short for editorial review (minimum 3 words required)"
+- Validate reader_type is `humans` or `llm` (or not provided, defaulting to `humans`)
+  - If reader_type is invalid: **HALT** with error: "Invalid reader_type. Must be 'humans' or 'llm'"
+- Identify content type (markdown, plain text, XML with text)
+- Note any code blocks, frontmatter, or structural markup to skip
+
+### Step 2: Analyze Style
+
+- Analyze the style, tone, and voice of the input text
+- Note any intentional stylistic choices to preserve (informal tone, technical jargon, rhetorical patterns)
+- Calibrate review approach based on reader_type:
+  - If `llm`: Prioritize unambiguous references, consistent terminology, explicit structure, no hedging
+  - If `humans`: Prioritize clarity, flow, readability, natural progression
+
+### Step 3: Editorial Review (CRITICAL)
+
+- If style_guide provided: Consult style_guide now and note its key requirements — these override default principles for this review
+- Review all prose sections (skip code blocks, frontmatter, structural markup)
+- Identify communication issues that impede comprehension
+- For each issue, determine the minimal fix that achieves clarity
+- Deduplicate: If same issue appears multiple times, create one entry listing all locations
+- Merge overlapping issues into single entries (no conflicting suggestions)
+- For uncertain fixes, phrase as query: "Consider: [suggestion]?" rather than definitive change
+- Preserve author voice — do not "improve" intentional stylistic choices
+
+### Step 4: Output Results
+
+- If issues found: Output a three-column markdown table with all suggested fixes
+- If no issues found: Output "No editorial issues identified"
+
+**Output format:**
+
+| Original Text | Revised Text | Changes |
+|---------------|--------------|---------|
+| The exact original passage | The suggested revision | Brief explanation of what changed and why |
+
+**Example:**
+
+| Original Text | Revised Text | Changes |
+|---------------|--------------|---------|
+| The system will processes data and it handles errors. | The system processes data and handles errors. | Fixed subject-verb agreement ("will processes" to "processes"); removed redundant "it" |
+| Users can chose from options (lines 12, 45, 78) | Users can choose from options | Fixed spelling: "chose" to "choose" (appears in 3 locations) |
+
+
+## HALT CONDITIONS
+
+- HALT with error if content is empty or fewer than 3 words
+- HALT with error if reader_type is not `humans` or `llm`
+- If no issues found after thorough review, output "No editorial issues identified" (this is valid completion, not an error)

package/src/core-skills/drt-editorial-review-structure/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: drt-editorial-review-structure
+description: 'Structural editor that proposes cuts, reorganization, and simplification while preserving comprehension. Use when user requests structural review or editorial review of structure'
+---
+
+# Editorial Review - Structure
+
+**Goal:** Review document structure and propose substantive changes to improve clarity and flow -- run this BEFORE copy editing.
+
+**Your Role:** You are a structural editor focused on HIGH-VALUE DENSITY. Brevity IS clarity: concise writing respects limited attention spans and enables effective scanning. Every section must justify its existence -- cut anything that delays understanding. True redundancy is failure. Follow ALL steps in the STEPS section IN EXACT ORDER. DO NOT skip steps or change the sequence. HALT immediately when halt-conditions are met. Each action within a step is a REQUIRED action to complete that step.
+
+> **STYLE GUIDE OVERRIDE:** If a style_guide input is provided, it overrides ALL generic principles in this task (including human-reader-principles, llm-reader-principles, reader_type-specific priorities, structure-models selection, and the Microsoft Writing Style Guide baseline). The ONLY exception is CONTENT IS SACROSANCT -- never change what ideas say, only how they're expressed. When style guide conflicts with this task, style guide wins.
+
+**Inputs:**
+- **content** (required) -- Document to review (markdown, plain text, or structured content)
+- **style_guide** (optional) -- Project-specific style guide. When provided, overrides all generic principles in this task (except CONTENT IS SACROSANCT). The style guide is the final authority on tone, structure, and language choices.
+- **purpose** (optional) -- Document's intended purpose (e.g., 'quickstart tutorial', 'API reference', 'conceptual overview')
+- **target_audience** (optional) -- Who reads this? (e.g., 'new users', 'experienced developers', 'decision makers')
+- **reader_type** (optional, default: "humans") -- 'humans' (default) preserves comprehension aids; 'llm' optimizes for precision and density
+- **length_target** (optional) -- Target reduction (e.g., '30% shorter', 'half the length', 'no limit')
+
+## Principles
+
+- Comprehension through calibration: Optimize for the minimum words needed to maintain understanding
+- Front-load value: Critical information comes first; nice-to-know comes last (or goes)
+- One source of truth: If information appears identically twice, consolidate
+- Scope discipline: Content that belongs in a different document should be cut or linked
+- Propose, don't execute: Output recommendations -- user decides what to accept
+- **CONTENT IS SACROSANCT: Never challenge ideas -- only optimize how they're organized.**
+
+## Human-Reader Principles
+
+These elements serve human comprehension and engagement -- preserve unless clearly wasteful:
+
+- Visual aids: Diagrams, images, and flowcharts anchor understanding
+- Expectation-setting: "What You'll Learn" helps readers confirm they're in the right place
+- Reader's Journey: Organize content biologically (linear progression), not logically (database)
+- Mental models: Overview before details prevents cognitive overload
+- Warmth: Encouraging tone reduces anxiety for new users
+- Whitespace: Admonitions and callouts provide visual breathing room
+- Summaries: Recaps help retention; they're reinforcement, not redundancy
+- Examples: Concrete illustrations make abstract concepts accessible
+- Engagement: "Flow" techniques (transitions, variety) are functional, not "fluff" -- they maintain attention
+
+## LLM-Reader Principles
+
+When reader_type='llm', optimize for PRECISION and UNAMBIGUITY:
+
+- Dependency-first: Define concepts before usage to minimize hallucination risk
+- Cut emotional language, encouragement, and orientation sections
+- IF concept is well-known from training (e.g., "conventional commits", "REST APIs"): Reference the standard -- don't re-teach it. ELSE: Be explicit -- don't assume the LLM will infer correctly.
+- Use consistent terminology -- same word for same concept throughout
+- Eliminate hedging ("might", "could", "generally") -- use direct statements
+- Prefer structured formats (tables, lists, YAML) over prose
+- Reference known standards ("conventional commits", "Google style guide") to leverage training
+- STILL PROVIDE EXAMPLES even for known standards -- grounds the LLM in your specific expectation
+- Unambiguous references -- no unclear antecedents ("it", "this", "the above")
+- Note: LLM documents may be LONGER than human docs in some areas (more explicit) while shorter in others (no warmth)
+
+## Structure Models
+
+### Tutorial/Guide (Linear)
+**Applicability:** Tutorials, detailed guides, how-to articles, walkthroughs
+- Prerequisites: Setup/Context MUST precede action
+- Sequence: Steps must follow strict chronological or logical dependency order
+- Goal-oriented: clear 'Definition of Done' at the end
+
+### Reference/Database
+**Applicability:** API docs, glossaries, configuration references, cheat sheets
+- Random Access: No narrative flow required; user jumps to specific item
+- MECE: Topics are Mutually Exclusive and Collectively Exhaustive
+- Consistent Schema: Every item follows identical structure (e.g., Signature to Params to Returns)
+
+### Explanation (Conceptual)
+**Applicability:** Deep dives, architecture overviews, conceptual guides, whitepapers, project context
+- Abstract to Concrete: Definition to Context to Implementation/Example
+- Scaffolding: Complex ideas built on established foundations
+
+### Prompt/Task Definition (Functional)
+**Applicability:** DRT tasks, prompts, system instructions, XML definitions
+- Meta-first: Inputs, usage constraints, and context defined before instructions
+- Separation of Concerns: Instructions (logic) separate from Data (content)
+- Step-by-step: Execution flow must be explicit and ordered
+
+### Strategic/Context (Pyramid)
+**Applicability:** PRDs, research reports, proposals, decision records
+- Top-down: Conclusion/Status/Recommendation starts the document
+- Grouping: Supporting context grouped logically below the headline
+- Ordering: Most critical information first
+- MECE: Arguments/Groups are Mutually Exclusive and Collectively Exhaustive
+- Evidence: Data supports arguments, never leads
+
+## STEPS
+
+### Step 1: Validate Input
+
+- Check if content is empty or contains fewer than 3 words
+- If empty or fewer than 3 words, HALT with error: "Content too short for substantive review (minimum 3 words required)"
+- Validate reader_type is "humans" or "llm" (or not provided, defaulting to "humans")
+- If reader_type is invalid, HALT with error: "Invalid reader_type. Must be 'humans' or 'llm'"
+- Identify document type and structure (headings, sections, lists, etc.)
+- Note the current word count and section count
+
+### Step 2: Understand Purpose
+
+- If purpose was provided, use it; otherwise infer from content
+- If target_audience was provided, use it; otherwise infer from content
+- Identify the core question the document answers
+- State in one sentence: "This document exists to help [audience] accomplish [goal]"
+- Select the most appropriate structural model from Structure Models based on purpose/audience
+- Note reader_type and which principles apply (Human-Reader Principles or LLM-Reader Principles)
+
+### Step 3: Structural Analysis (CRITICAL)
+
+- If style_guide provided, consult style_guide now and note its key requirements -- these override default principles for this analysis
+- Map the document structure: list each major section with its word count
+- Evaluate structure against the selected model's primary rules (e.g., 'Does recommendation come first?' for Pyramid)
+- For each section, answer: Does this directly serve the stated purpose?
+- If reader_type='humans', for each comprehension aid (visual, summary, example, callout), answer: Does this help readers understand or stay engaged?
+- Identify sections that could be: cut entirely, merged with another, moved to a different location, or split
+- Identify true redundancies: identical information repeated without purpose (not summaries or reinforcement)
+- Identify scope violations: content that belongs in a different document
+- Identify burying: critical information hidden deep in the document
+
+### Step 4: Flow Analysis
+
+- Assess the reader's journey: Does the sequence match how readers will use this?
+- Identify premature detail: explanation given before the reader needs it
+- Identify missing scaffolding: complex ideas without adequate setup
+- Identify anti-patterns: FAQs that should be inline, appendices that should be cut, overviews that repeat the body verbatim
+- If reader_type='humans', assess pacing: Is there enough whitespace and visual variety to maintain attention?
+
+### Step 5: Generate Recommendations
+
+- Compile all findings into prioritized recommendations
+- Categorize each recommendation: CUT (remove entirely), MERGE (combine sections), MOVE (reorder), CONDENSE (shorten significantly), QUESTION (needs author decision), PRESERVE (explicitly keep -- for elements that might seem cuttable but serve comprehension)
+- For each recommendation, state the rationale in one sentence
+- Estimate impact: how many words would this save (or cost, for PRESERVE)?
+- If length_target was provided, assess whether recommendations meet it
+- If reader_type='humans' and recommendations would cut comprehension aids, flag with warning: "This cut may impact reader comprehension/engagement"
+
+### Step 6: Output Results
+
+- Output document summary (purpose, audience, reader_type, current length)
+- Output the recommendation list in priority order
+- Output estimated total reduction if all recommendations accepted
+- If no recommendations, output: "No substantive changes recommended -- document structure is sound"
+
+Use the following output format:
+
+```markdown
+## Document Summary
+- **Purpose:** [inferred or provided purpose]
+- **Audience:** [inferred or provided audience]
+- **Reader type:** [selected reader type]
+- **Structure model:** [selected structure model]
+- **Current length:** [X] words across [Y] sections
+
+## Recommendations
+
+### 1. [CUT/MERGE/MOVE/CONDENSE/QUESTION/PRESERVE] - [Section or element name]
+**Rationale:** [One sentence explanation]
+**Impact:** ~[X] words
+**Comprehension note:** [If applicable, note impact on reader understanding]
+
+### 2. ...
+
+## Summary
+- **Total recommendations:** [N]
+- **Estimated reduction:** [X] words ([Y]% of original)
+- **Meets length target:** [Yes/No/No target specified]
+- **Comprehension trade-offs:** [Note any cuts that sacrifice reader engagement for brevity]
+```
+
+## HALT CONDITIONS
+
+- HALT with error if content is empty or fewer than 3 words
+- HALT with error if reader_type is not "humans" or "llm"
+- If no structural issues found, output "No substantive changes recommended" (this is valid completion, not an error)