@sulhadin/orchestrator 3.0.0-beta.12 → 3.0.0-beta.13

package/README.md

@@ -28,7 +28,7 @@ Terminal 1 (PM):                    Terminal 2 (Conductor):
   │                                   ├─ Delegate to frontend → UI
   │  (plan M2 while M1 runs)          ├─ Call reviewer → code review
   │                                   ├─ Push → milestone done
-  │                                   └─ Loop → next milestone
+  │                                   └─ Stop (inline) or next milestone (agent)
 ```
 
 ## Quick Example
@@ -49,8 +49,7 @@ PM challenges scope, creates M1-user-auth with 3 phases
 ⚙️ backend → phase-2: API endpoints → committed
 🎨 frontend → phase-3: Login UI → committed
 🔍 reviewer → approved
-🚦 Push? → yes
-✅ M1-user-auth done. Checking for next milestone...
+✅ M1-user-auth done. Pushed to origin.
 ```
 
 ## Commands
@@ -117,6 +116,8 @@ PM challenges scope, creates M1-user-auth with 3 phases
 
 **Role boundaries** — Enforced via `.claude/rules/`. PM cannot write code. Engineers cannot modify system files. Orchestrator cannot write features. Boundaries checked by file path, not by words.
 
+**Milestone isolation** — `inline` mode stops after each milestone (user compacts manually). `agent` mode spawns each milestone in its own sub-agent — context freed automatically, enabling 20+ milestones in a single `--auto` session.
+
 **Stuck detection** — Detects repeated failures, circular fixes, over-engineering. Tries different approach once, then escalates. Auto mode skips to next phase.
 
 ## Upgrading

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sulhadin/orchestrator",
-  "version": "3.0.0-beta.12",
+  "version": "3.0.0-beta.13",
   "description": "AI Team Orchestration System — multi-role coordination for Claude Code",
   "bin": "bin/index.js",
   "scripts": {

package/template/.claude/agents/conductor.md

@@ -18,8 +18,10 @@ by delegating each phase to a sub-agent. You NEVER implement code yourself.
 
 When started:
 
-1. If `--auto`: print `Warning: Auto mode — all gates skipped, auto-push enabled.` and proceed.
+1. If `--auto`: print `Warning: Auto mode — RFC gate skipped, fully autonomous.` and proceed.
 2. Read `.orchestra/config.yml` for pipeline settings and thresholds.
+   - Read `pipeline.milestone_isolation` (default: `inline`).
+   - If `--auto` and `milestone_isolation: inline`: warn once: "Inline mode with --auto: conductor stops after each milestone. Consider `milestone_isolation: agent` for batch runs."
 3. Read `.orchestra/README.md` for orchestration rules.
 4. Read `.orchestra/knowledge.md` Active Knowledge section (skip Archive).
 5. Scan milestones:
@@ -136,10 +138,11 @@ that affect this phase. Omit for first phase.}
 ### 4. Process Sub-Agent Result (Conductor does this)
 
 - If **done** (verification passed):
-  1. Conductor commits → update phase status → `done`, update context.md
-  2. Store sub-agent ID for potential review fix cycle
+  1. Conductor commits
+  2. Update context.md: set phase `done`, add commit hash + files_changed, append decisions from notes
+  3. Store sub-agent ID for potential review fix cycle
 - If **failed** (verification failed after max retries):
-  1. Log in context.md: phase name, last error summary, retry count
+  1. Update context.md: set phase `failed`, add error summary + last-error + retry count
   2. Decide: retry with new sub-agent or escalate to user
 
 **Note:** Conductor owns commit only. Sub-agents own implementation + verification.
@@ -188,6 +191,8 @@ Read gate behavior from config.yml:
 
 ## Milestone Completion
 
+### Inline Mode (default)
+
 After push:
 1. Update milestone.md `status: done`, remove `Locked-By`.
 2. Append 5-line retrospective to knowledge.md:
@@ -199,35 +204,185 @@ After push:
    - Review findings: {N blocking, N non-blocking} — {top issue}
    - Missing skill: {name or "none"}
    ```
+3. Proceed to "Next Milestone — Mode-Dependent Behavior" → Inline Mode.
+
+### Agent Mode
+
+Milestone agent handles push and returns structured result (see Milestone Agent Delegation).
+Conductor processes the return:
+1. Update milestone.md `status: done`, remove `Locked-By`.
+2. Append retro from milestone agent's return to knowledge.md.
+3. Proceed to "Next Milestone — Mode-Dependent Behavior" → Agent Mode.
+
+## Next Milestone — Mode-Dependent Behavior
+
+Behavior after milestone completion depends on `pipeline.milestone_isolation`:
+
+### Inline Mode (default)
+
+After push and retro:
+1. Clear context.md: remove `## Status`, `## Phases`, `## Decisions`, `## Metrics` sections, keep only `## Codebase Map`
+2. **STOP.** Print: "Milestone {id} complete and pushed. Run `/compact` then `/orchestra start` for next milestone."
+3. Do NOT loop to next milestone — user manages context manually.
+
+**Why stop?** Conductor accumulates ~5-8k tokens per milestone from phase
+results, review cycles, and commit logs. In inline mode, the user controls
+when to compact and restart, keeping quality high across milestones.
+
+### Agent Mode
+
+After milestone agent returns (retro already written in Milestone Completion above):
+1. Re-read knowledge.md Active section (may have new retros)
+2. Re-scan `.orchestra/milestones/` using Glob (PM may have created new ones)
+3. If pending → spawn next milestone agent
+4. If none → "All milestones complete. Waiting for new work from PM."
+
+Context stays lean because all phase-level context lived in the (now ended)
+milestone agent. Conductor only accumulates ~1-2k tokens per milestone
+(prompt + structured result).
+
+## Milestone Agent Delegation (Agent Mode Only)
+
+This section applies ONLY when config `pipeline.milestone_isolation: agent`.
+
+In agent mode, the conductor becomes a two-tier dispatcher:
+- Conductor spawns one milestone agent per milestone
+- Milestone agent spawns phase sub-agents (same as current phase delegation)
+- When milestone agent completes, its context is freed entirely
+
+### Milestone Agent Prompt Template
+
+```
+You are a Milestone Agent executing milestone {milestone_id}: {title}.
+Rules from `.claude/rules/*.orchestra.md` are automatically loaded.
+
+**Config:**
+{config_yml_content}
+
+**Orchestration Rules:**
+{readme_content}
+
+**Active Knowledge:**
+{knowledge_active_section}
+
+**Milestone:**
+{milestone.md content}
+
+**Grooming:**
+{grooming.md content}
 
-## Next Milestone — Context Reset
+**Context (if resuming):**
+{context.md content}
+Sections: `## Status` (milestone state), `## Phases` (per-phase status — skip `done` phases),
+`## Decisions` (cross-phase context), `## Metrics` (duration + retries per phase).
 
-Between milestones, reset to prevent context accumulation:
+**Phase files:**
+{all phase file contents, in order}
 
-1. Write retro to knowledge.md (see Milestone Completion above)
-2. Clear context.md: remove phase-specific sections, keep only `## Codebase Map`
-3. Drop cached role/skills content — next milestone may use different roles
-4. Re-read essentials: config.yml (if not cached), knowledge.md Active section
-5. Re-scan `.orchestra/milestones/` using Glob (PM may have created new ones)
-6. If pending → start next milestone
-7. If none → "All milestones complete. Waiting for new work from PM."
+**Role files (unique, one per role used in phases):**
+{role file contents — deduplicated}
 
-**Why reset?** Conductor accumulates ~5-8k tokens per milestone from phase
-results, review cycles, and commit logs. Over multiple milestones this
-degrades quality. Resetting keeps conductor lean within a single session.
+**Skills (unique, one per skill used in phases):**
+{skill file contents — deduplicated}
+
+## Your Task
+Execute this milestone using the Phase Execution protocol:
+1. For each phase: pre-flight → compose prompt → delegate to phase sub-agent → process result
+2. Conductor (you) commits after each successful phase, updates context.md
+3. After all phases: trigger review (unless config says skip)
+4. After review passes: push to origin
+5. On phase failure after max retries: set phase to `failed`, log in context.md
+   - If stuck: set milestone status to `failed`, return immediately
+6. You own exactly ONE milestone — do NOT loop to other milestones
+
+## Return Format
+- status: done | failed
+- phases_completed: [list of phase names]
+- phases_failed: [list with error summaries]
+- review_verdict: approved | approved-with-comments | changes-requested | skipped
+- pushed: true | false
+- retro: |
+    ## Retro: {id} — {title} ({date})
+    - Longest phase: {name} (~{duration}) — {why}
+    - Verification retries: {count} — {which phases}
+    - Stuck: {yes/no} — {root cause if yes}
+    - Review findings: {N blocking, N non-blocking} — {top issue}
+    - Missing skill: {name or "none"}
+- notes: {anything conductor should know for subsequent milestones}
+
+IMPORTANT: Return retro text in your result. Do NOT write to knowledge.md — conductor handles this.
+```
+
+### Processing Milestone Agent Result
+
+Conductor processes the return:
+
+- **status: done + pushed: true** → Write retro to knowledge.md, update milestone.md status to `done`, remove `Locked-By`, proceed to next milestone.
+- **status: failed** → Log failure to context.md, write partial retro to knowledge.md.
+  - `--auto` mode: move to next milestone.
+  - Normal mode: stop and report to user with options: (a) retry with fresh agent, (b) skip, (c) stop.
+- **status: done + pushed: false** → Log error, escalate to user.
+
+### Milestone Agent Configuration
+
+- Use default (general-purpose) subagent_type — milestone identity is in the prompt
+- Do NOT use `isolation: "worktree"` — milestones run sequentially, not in parallel
+- Milestone agent inherits all conductor capabilities: git, Agent tool, file access
+- On resume (milestone was `in-progress`): include context.md in prompt — milestone agent reads phase statuses and continues from last completed phase
 
 ## Context Persistence
 
-Update context.md at: phase start, phase completion (with sub-agent summary), errors.
-On resume: read context.md, continue from last completed phase.
+context.md uses a fixed structure. Conductor updates it at phase start, completion, and on errors.
+
+### context.md Format
+
+```markdown
+## Status
+milestone: {milestone-id}
+started: {YYYY-MM-DD}
+pipeline: {quick | standard | full}
+
+## Phases
+- phase-1: {done | in-progress | failed | pending} | commit: {hash} | files: {changed files}
+- phase-2: {status} | error: {error summary, retry count} | last-error: {specific error}
+- phase-3: pending
+...
+
+## Codebase Map
+{path — one-line description, generated by scout sub-agent}
+
+## Decisions
+- phase-1: {key decision or trade-off made during implementation}
+- phase-2: {why a specific approach was chosen}
+
+## Metrics
+- phase-1: duration: ~{N}min | verification_retries: {N}
+- phase-2: duration: ~{N}min | verification_retries: {N}
+```
+
+### Update Rules
+
+- **Phase start:** Set phase status to `in-progress`
+- **Phase done:** Set status to `done`, add commit hash and files_changed from sub-agent result
+- **Phase failed:** Set status to `failed`, add error summary and last-error
+- **Decisions:** Append key decisions from sub-agent's `notes` field — only non-obvious choices that affect later phases
+- **Metrics:** Record approximate phase duration and verification_retries from sub-agent result
+- **Milestone complete (inline mode):** Clear all sections except `## Codebase Map`
+
+### On Resume
+
+Read context.md → skip phases marked `done` → resume from first non-done phase.
+`## Decisions` from completed phases are included in "previous phase summary" for the next sub-agent — this preserves cross-phase context even after session restart.
 
 ## Hotfix Pipeline
 
+Hotfix always runs inline regardless of `milestone_isolation` setting — single-phase fast path, sub-agent isolation adds no value.
+
 When user types `/orchestra hotfix {description}`:
 1. Auto-create hotfix milestone + single phase
 2. Launch implementation sub-agent (model: standard) — implements, verifies, reports
 3. If done → conductor commits → push immediately (no RFC, no review, no gates)
-5. Append one-liner to knowledge.md
+4. Append one-liner to knowledge.md
 6. Return to normal execution if active
 
 ## What Conductor Does NOT Do

package/template/.claude/agents/reviewer.md

@@ -10,7 +10,7 @@ Review code independently. No implementation context by design — only the code
 
 ## Process
 
-1. Read context.md for objectives and acceptance criteria
+1. Read milestone.md for objectives, phase files for acceptance criteria, context.md for codebase map and decisions
 2. Read RFC if exists
 3. `git log origin/{branch}..HEAD` + `git diff origin/{branch}...HEAD`
 4. Detect mode from diff: backend / frontend / both → apply relevant checklist

package/template/.claude/commands/orchestra/start.md

@@ -7,7 +7,11 @@ The conductor will:
 2. Execute phases sequentially (or parallel if configured)
 3. Activate roles, load skills, implement code
 4. Trigger code review via reviewer agent
-5. Push after approval (or auto-push in --auto mode)
-6. Loop to next milestone until all complete
+5. Push automatically after review passes
+6. Behavior after milestone: stop (inline mode) or continue to next (agent mode)
+
+Config `pipeline.milestone_isolation` controls post-milestone behavior:
+- `inline` (default): stops after each milestone. User compacts and restarts.
+- `agent`: spawns each milestone in sub-agent. Loops automatically. Best with `--auto`.
 
 Pass `--auto` flag for fully autonomous mode (warns once, then skips all gates).

package/template/.claude/commands/orchestra/status.md

@@ -5,7 +5,7 @@ Show full milestone status report. PM role only.
 3. For active milestones, read context.md for progress details.
 4. Report:
    - All milestones with status, current phase, next action
-   - Phase details for active milestone (role, status, cost tracking)
+   - Phase details for active milestone (role, status, metrics)
    - Git status (branch, unpushed commits)
-   - Cost summary (from context.md)
+   - Metrics summary from context.md `## Metrics` section (duration + retries per phase)
    - Actions needed (specific next steps)

package/template/.orchestra/README.md

@@ -15,9 +15,8 @@ Terminal 1 (PM):                    Terminal 2 (Conductor):
   ├─ Always available                ├─ ⚙️ delegate to backend → phase by phase
   │                                  ├─ 🎨 delegate to frontend → phase by phase
   │  (can plan M2 while M1 runs)     ├─ 🔍 reviewer → review commits
-  │                                  ├─ 🚦 User approves push
   │                                  ├─ git push → milestone done
-  │                                  └─ Loop → next milestone
+  │                                  └─ Stop (inline) or next milestone (agent)
 ```
 
 ## Directory Structure
@@ -57,7 +56,8 @@ You can plan new milestones while the conductor is executing another one.
 ### Terminal 2: `/orchestra start` (Execution)
 
 Conductor reads milestones, delegates each phase to a sub-agent with the right role.
-Sub-agents implement + verify; conductor commits. Loops to next milestone when done.
+Sub-agents implement + verify; conductor commits. After milestone completion, behavior
+depends on `milestone_isolation` config: stops (inline) or continues to next (agent).
 Maintains `context.md` for resume capability.
 
 ```
@@ -82,7 +82,6 @@ PM discusses feature with user
   → Conductor executes frontend phases (sequential, each → commit)
   → Conductor calls reviewer agent (reviews unpushed commits)
   → FIX cycle if changes-requested (re-review if fix >= 30 lines)
-  → [USER APPROVAL GATE: Push to origin]
   → Conductor pushes, PM verifies acceptance criteria, closes milestone
   → Conductor appends 5-line retrospective to knowledge.md
 
@@ -110,6 +109,31 @@ PM sets `Complexity` on milestone (pipeline) and `complexity` on each phase (mod
 
 Defaults: config.yml `pipeline.default_pipeline` and `pipeline.default_complexity`.
 
+### Milestone Isolation
+
+Config `pipeline.milestone_isolation` controls how the conductor handles multiple milestones:
+
+| Mode | Behavior | Best for |
+|------|----------|----------|
+| `inline` (default) | Conductor runs milestone directly, **stops** after completion. User runs `/compact` then `/orchestra start` for next milestone. | Manual sessions, PC-based work |
+| `agent` | Conductor spawns a sub-agent per milestone. Context freed automatically after each. Loops to next milestone. | `--auto` overnight batch runs |
+
+```
+Inline mode:                          Agent mode:
+  /orchestra start                      /orchestra start --auto
+  → M1 executes → done → STOP          → Spawn Agent(M1) → done → freed
+  user: /compact                        → Spawn Agent(M2) → done → freed
+  /orchestra start                      → Spawn Agent(M3) → done → freed
+  → M2 executes → done → STOP          → All done
+```
+
+In agent mode, the delegation is two-tier:
+```
+Conductor (lean dispatcher)
+  └── Milestone Agent (fresh context)
+        └── Phase Agent (unchanged)
+```
+
 ### Milestone Statuses
 
 | Status | Meaning |
@@ -153,7 +177,8 @@ Conductor NEVER commits unless verification passes.
 
 - Each phase completion → **one conventional commit** on the current branch
 - No branch creation or switching — work happens on whatever branch is checked out
-- Milestone completion → **push to origin** (after user approval)
+- Milestone completion → **push to origin** (automatic after review passes)
+- Commits stay local until milestone fully completes — no partial push on failure
 - Reviewer reviews unpushed commits: `git log origin/{branch}..HEAD`
 - Clean git history: each commit maps to a phase
 
@@ -187,16 +212,14 @@ Rules:
 
 The user must approve before these transitions:
 - **Milestone creation** — PM discusses and plans, but must get user approval before creating the milestone directory and files
-- **RFC → Implementation** — user reviews architect's RFC
-- **Push to origin** — user approves the final changeset
+- **RFC → Implementation** — user reviews architect's RFC (if `rfc_approval` is not `skip`)
 
-All other transitions are automatic.
+Push is automatic after review passes. All other transitions are automatic.
 
 ### Rejection Handling
 
 If the user says **no** at any gate:
 - **RFC rejected** → Architect revises based on feedback, re-submits (max config `pipeline.max_rfc_rounds`)
-- **Push rejected** → Conductor creates fix phase, implements, re-submits push gate
 - **Milestone rejected** → PM revises in PM terminal
 
 Rejections are normal. The system does not stall — it loops back with feedback.
@@ -215,9 +238,9 @@ Conductor calls reviewer agent
   → Returns: approved / approved-with-comments / changes-requested
 ```
 
-**If approved** → proceed to push gate.
+**If approved** → push immediately.
 
-**If approved-with-comments** → proceed to push gate. Comments are logged in context.md.
+**If approved-with-comments** → push immediately. Comments are logged in context.md.
 
 **If changes-requested** → Conductor continues the phase's sub-agent via SendMessage with
 reviewer findings. Re-review triggered if fix >= config `re_review_lines` threshold.
@@ -285,16 +308,21 @@ PM and conductor run in **separate terminals**. They communicate through milesto
 
 ### Context Persistence
 
-Conductor maintains `context.md` in each milestone directory. This allows:
-- Resume after terminal close/reopen
-- Track decisions made during implementation
-- Record what was committed in each phase
+Conductor maintains `context.md` in each milestone directory with a fixed structure:
+- `## Status` — milestone id, start date, pipeline type
+- `## Phases` — per-phase status, commit hash, files changed, errors
+- `## Codebase Map` — scout-generated file map (survives milestone clear)
+- `## Decisions` — key choices from each phase that affect later phases
+- `## Metrics` — phase duration and verification retries (used by `/orchestra status`)
+
+This enables resume after terminal close/reopen. On restart, conductor reads context.md and skips completed phases.
 
 ### Approval Gates (Conductor Terminal)
 
-Conductor asks the user directly (not PM) at these points:
-1. **RFC ready** — "Approve RFC to start implementation?"
-2. **Push to origin** — "All done. Push to origin?"
+Conductor asks the user directly (not PM) at this point:
+1. **RFC ready** — "Approve RFC to start implementation?" (if `rfc_approval` is not `skip`)
+
+Push is automatic after review passes — no approval needed.
 
 ---
 
@@ -332,16 +360,18 @@ sequenceDiagram
         C->>C: Fix → commit
     end
 
-    C->>U: Push to origin?
-    U->>C: Yes
     C->>C: git push → milestone done
 
-    C->>C: Next milestone? → loop or done
+    alt Inline mode (default)
+        C->>C: STOP — user compacts and restarts
+    else Agent mode
+        C->>C: Next milestone? → loop or done
+    end
 
     Note over PM: PM is free the entire time<br/>Can plan M2 while M1 executes
 ```
 
-### 2. Conductor Execution Loop
+### 2. Conductor Execution Loop (Inline Mode)
 
 ```mermaid
 sequenceDiagram
@@ -356,11 +386,27 @@ sequenceDiagram
     C->>C: reviewer → approved
     C->>C: Push → M1 done
 
-    C->>C: Start M2
-    C->>C: architect → RFC
-    C->>C: backend phase-1
-    C->>C: reviewer → approved
-    C->>C: Push → M2 done
+    Note over C: STOP. "Run /compact then /orchestra start"
+```
+
+### 3. Conductor Execution Loop (Agent Mode)
+
+```mermaid
+sequenceDiagram
+    participant C as Conductor
+    participant MA as Milestone Agent
+
+    C->>C: Scan milestones/
+
+    C->>MA: Spawn Agent(M1)
+    MA->>MA: phase-1 → phase-2 → review → push
+    MA-->>C: {status: done, retro: ...}
+    Note over C: Write retro, ~1-2k tokens retained
+
+    C->>MA: Spawn Agent(M2)
+    MA->>MA: phase-1 → phase-2 → review → push
+    MA-->>C: {status: done, retro: ...}
+    Note over C: Write retro, ~1-2k tokens retained
 
     C->>C: No more milestones
     Note over C: "All done. Waiting for new work."

package/template/.orchestra/config.yml

@@ -22,6 +22,11 @@ pipeline:
   # When enabled, phases with depends_on: [] run in parallel
   parallel: disabled
 
+  # Milestone isolation mode: inline | agent
+  # inline: conductor runs milestones directly, stops after each. User compacts manually. (default)
+  # agent: each milestone runs in its own sub-agent. Context freed automatically. Best for --auto.
+  milestone_isolation: inline
+
   # Default pipeline when milestone Complexity is missing
   default_pipeline: full  # quick | standard | full
 

package/template/.orchestra/knowledge.md

@@ -69,7 +69,7 @@ Last 5 milestones. Conductor reads before every milestone start. PM reads before
 
 ### Decisions
 - Skill System (markdown-only): Lightweight `.orchestra/skills/` with domain checklists (auth, CRUD, deployment). No registry, no keyword matching — PM manually assigns via `skills:` frontmatter in phase files. Preserves zero-infrastructure philosophy.
-- Cost Awareness: Track duration + verification retries per phase in context.md Cost Tracking table. PM sees this in #status. No token counting (unreliable from prompt), focus on observable metrics.
+- Cost Awareness: Track duration + verification retries per phase in context.md `## Metrics` section. PM sees this in `/orchestra status`. No token counting (unreliable from prompt), focus on observable metrics.
 - Re-review Threshold: Fix < 30 lines → no re-review. Fix >= 30 lines → abbreviated re-review (only the fix commit). Balances quality vs speed.
 - Rejection Flow: RFC rejected → architect revises (max 3 rounds). Push rejected → create fix phase. System no longer stalls on "no".
 

package/template/CLAUDE.md

@@ -1,6 +1,6 @@
-# CLAUDE.md — Orchestra Setup Instructions
+# CLAUDE.md
 
-This file is automatically read by Claude at the start of every session.
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
 
 <!-- orchestra -->
 ## Orchestra — AI Team Orchestration System
@@ -46,6 +46,22 @@ Role IDs: orchestrator, product-manager, architect, backend-engineer, frontend-e
 - Rules (`.claude/rules/*.orchestra.md`) auto-loaded. Skills loaded per phase.
 - **PROTECTED:** Non-Orchestrator roles NEVER modify `.orchestra/roles/`, `.orchestra/config.yml`, `.orchestra/README.md`, `.orchestra/blueprints/`, `.claude/agents/`, `.claude/rules/*.orchestra.md`, `.claude/skills/*.orchestra.md`, `.claude/commands/orchestra/`, `CLAUDE.md`, or `docs/`.
 
+## Development
+
+This is an npm package (`@sulhadin/orchestrator`) — a CLI installer that copies Orchestra template files into user projects.
+
+```bash
+yarn test              # Run tests (node:test, test/**/*.test.js)
+yarn template          # Rebuild template/ from source files (bin/build-template.js)
+yarn build             # Full build (defined in lint-staged)
+```
+
+**Architecture:** `bin/index.js` is the CLI entry point (runs via `npx`). It copies files from `template/` into the user's project, with smart YAML merge for `config.yml` (preserves user values, adds new keys). `bin/build-template.js` generates the `template/` directory from the source `.orchestra/` and `.claude/` files.
+
+**npm publishes:** Only `bin/` and `template/` directories (see `package.json` `files` field). Tests, docs, and source orchestra files are excluded.
+
+**Pre-commit:** Husky + lint-staged runs `yarn template && yarn build` on staged `.js`, `.md`, `.yml`, `.json` files.
+
 ## Installation
 
 See `docs/getting-started.md` for setup instructions.