@bradygaster/squad-sdk 0.9.1 → 0.9.2-insider.1

package/templates/skills/architectural-proposals/SKILL.md

@@ -1,151 +1,151 @@
----
-name: "architectural-proposals"
-description: "How to write comprehensive architectural proposals that drive alignment before code is written"
-domain: "architecture, product-direction"
-confidence: "high"
-source: "earned (2026-02-21 interactive shell proposal)"
-tools:
-  - name: "view"
-    description: "Read existing codebase, prior decisions, and team context before proposing changes"
-    when: "Always read .squad/decisions.md, relevant PRDs, and current architecture docs before writing proposal"
-  - name: "create"
-    description: "Create proposal in docs/proposals/ with structured format"
-    when: "After gathering context, before any implementation work begins"
----
-
-## Context
-
-Proposals create alignment before code is written. Cheaper to change a doc than refactor code. Use this pattern when:
-- Architecture shifts invalidate existing assumptions
-- Product direction changes require new foundation
-- Multiple waves/milestones will be affected by a decision
-- External dependencies (Copilot CLI, SDK APIs) change
-
-## Patterns
-
-### Proposal Structure (docs/proposals/)
-
-**Required sections:**
-1. **Problem Statement** — Why current state is broken (specific, measurable evidence)
-2. **Proposed Architecture** — Solution with technical specifics (not hand-waving)
-3. **What Changes** — Impact on existing work (waves, milestones, modules)
-4. **What Stays the Same** — Preserve existing functionality (no regression)
-5. **Key Decisions Needed** — Explicit choices with recommendations
-6. **Risks and Mitigations** — Likelihood + impact + mitigation strategy
-7. **Scope** — What's in v1, what's deferred (timeline clarity)
-
-**Optional sections:**
-- Implementation Plan (high-level milestones)
-- Success Criteria (measurable outcomes)
-- Open Questions (unresolved items)
-- Appendix (prior art, alternatives considered)
-
-### Tone Ceiling Enforcement
-
-**Always:**
-- Cite specific evidence (user reports, performance data, failure modes)
-- Justify recommendations with technical rationale
-- Acknowledge trade-offs (no perfect solutions)
-- Be specific about APIs, libraries, file paths
-
-**Never:**
-- Hype ("revolutionary", "game-changing")
-- Hand-waving ("we'll figure it out later")
-- Unsubstantiated claims ("users will love this")
-- Vague timelines ("soon", "eventually")
-
-### Wave Restructuring Pattern
-
-When a proposal invalidates existing wave structure:
-1. **Acknowledge the shift:** "This becomes Wave 0 (Foundation)"
-2. **Cascade impacts:** Adjust downstream waves (Wave 1, Wave 2, Wave 3)
-3. **Preserve non-blocking work:** Identify what can proceed in parallel
-4. **Update dependencies:** Document new blocking relationships
-
-**Example (Interactive Shell):**
-- Wave 0 (NEW): Interactive Shell — blocks all other waves
-- Wave 1 (ADJUSTED): npm Distribution — shell bundled in cli.js
-- Wave 2 (DEFERRED): SquadUI — waits for shell foundation
-- Wave 3 (ADJUSTED): Public Docs — now documents shell as primary interface
-
-### Decision Framing
-
-**Format:** "Recommendation: X (recommended) or alternatives?"
-
-**Components:**
-- Recommendation (pick one, justify)
-- Alternatives (what else was considered)
-- Decision rationale (why recommended option wins)
-- Needs sign-off from (which agents/roles must approve)
-
-**Example:**
-```
-### 1. Terminal UI Library: `ink` (recommended) or alternatives?
-
-**Recommendation:** `ink`  
-**Alternatives:** `blessed`, raw readline  
-**Decision rationale:** Component model enables testable UI. Battle-tested ecosystem.
-
-**Needs sign-off from:** Brady (product direction), Fortier (runtime performance)
-```
-
-### Risk Documentation
-
-**Format per risk:**
-- **Risk:** Specific failure mode
-- **Likelihood:** Low / Medium / High (not percentages)
-- **Impact:** Low / Medium / High
-- **Mitigation:** Concrete actions (measurable)
-
-**Example:**
-```
-### Risk 2: SDK Streaming Reliability
-
-**Risk:** SDK streaming events might drop messages or arrive out of order.  
-**Likelihood:** Low (SDK is production-grade).  
-**Impact:** High — broken streaming makes shell unusable.
-
-**Mitigation:**
-- Add integration test: Send 1000-message stream, verify all deltas arrive in order
-- Implement fallback: If streaming fails, fall back to polling session state
-- Log all SDK events to `.squad/orchestration-log/sdk-events.jsonl` for debugging
-```
-
-## Examples
-
-**File references from interactive shell proposal:**
-- Full proposal: `docs/proposals/squad-interactive-shell.md`
-- User directive: `.squad/decisions/inbox/copilot-directive-2026-02-21T202535Z.md`
-- Team decisions: `.squad/decisions.md`
-- Current architecture: `docs/architecture/module-map.md`, `docs/prd-23-release-readiness.md`
-
-**Key patterns demonstrated:**
-1. Read user directive first (understand the "why")
-2. Survey current architecture (module map, existing waves)
-3. Research SDK APIs (exploration task to validate feasibility)
-4. Document problem with specific evidence (unreliable handoffs, zero visibility, UX mismatch)
-5. Propose solution with technical specifics (ink components, SDK session management, spawn.ts module)
-6. Restructure waves when foundation shifts (Wave 0 becomes blocker)
-7. Preserve backward compatibility (squad.agent.md still works, VS Code mode unchanged)
-8. Frame decisions explicitly (5 key decisions with recommendations)
-9. Document risks with mitigations (5 risks, each with concrete actions)
-10. Define scope (what's in v1 vs. deferred)
-
-## Anti-Patterns
-
-**Avoid:**
-- ❌ Proposals without problem statements (solution-first thinking)
-- ❌ Vague architecture ("we'll use a shell") — be specific (ink components, session registry, spawn.ts)
-- ❌ Ignoring existing work — always document impact on waves/milestones
-- ❌ No risk analysis — every architecture has risks, document them
-- ❌ Unbounded scope — draw the v1 line explicitly
-- ❌ Missing decision ownership — always say "needs sign-off from X"
-- ❌ No backward compatibility plan — users don't care about your replatform
-- ❌ Hand-waving timelines ("a few weeks") — be specific (2-3 weeks, 1 engineer full-time)
-
-**Red flags in proposal reviews:**
-- "Users will love this" (citation needed)
-- "We'll figure out X later" (scope creep incoming)
-- "This is revolutionary" (tone ceiling violation)
-- No section on "What Stays the Same" (regression risk)
-- No risks documented (wishful thinking)
+---
+name: "architectural-proposals"
+description: "How to write comprehensive architectural proposals that drive alignment before code is written"
+domain: "architecture, product-direction"
+confidence: "high"
+source: "earned (2026-02-21 interactive shell proposal)"
+tools:
+  - name: "view"
+    description: "Read existing codebase, prior decisions, and team context before proposing changes"
+    when: "Always read .squad/decisions.md, relevant PRDs, and current architecture docs before writing proposal"
+  - name: "create"
+    description: "Create proposal in docs/proposals/ with structured format"
+    when: "After gathering context, before any implementation work begins"
+---
+
+## Context
+
+Proposals create alignment before code is written. Cheaper to change a doc than refactor code. Use this pattern when:
+- Architecture shifts invalidate existing assumptions
+- Product direction changes require new foundation
+- Multiple waves/milestones will be affected by a decision
+- External dependencies (Copilot CLI, SDK APIs) change
+
+## Patterns
+
+### Proposal Structure (docs/proposals/)
+
+**Required sections:**
+1. **Problem Statement** — Why current state is broken (specific, measurable evidence)
+2. **Proposed Architecture** — Solution with technical specifics (not hand-waving)
+3. **What Changes** — Impact on existing work (waves, milestones, modules)
+4. **What Stays the Same** — Preserve existing functionality (no regression)
+5. **Key Decisions Needed** — Explicit choices with recommendations
+6. **Risks and Mitigations** — Likelihood + impact + mitigation strategy
+7. **Scope** — What's in v1, what's deferred (timeline clarity)
+
+**Optional sections:**
+- Implementation Plan (high-level milestones)
+- Success Criteria (measurable outcomes)
+- Open Questions (unresolved items)
+- Appendix (prior art, alternatives considered)
+
+### Tone Ceiling Enforcement
+
+**Always:**
+- Cite specific evidence (user reports, performance data, failure modes)
+- Justify recommendations with technical rationale
+- Acknowledge trade-offs (no perfect solutions)
+- Be specific about APIs, libraries, file paths
+
+**Never:**
+- Hype ("revolutionary", "game-changing")
+- Hand-waving ("we'll figure it out later")
+- Unsubstantiated claims ("users will love this")
+- Vague timelines ("soon", "eventually")
+
+### Wave Restructuring Pattern
+
+When a proposal invalidates existing wave structure:
+1. **Acknowledge the shift:** "This becomes Wave 0 (Foundation)"
+2. **Cascade impacts:** Adjust downstream waves (Wave 1, Wave 2, Wave 3)
+3. **Preserve non-blocking work:** Identify what can proceed in parallel
+4. **Update dependencies:** Document new blocking relationships
+
+**Example (Interactive Shell):**
+- Wave 0 (NEW): Interactive Shell — blocks all other waves
+- Wave 1 (ADJUSTED): npm Distribution — shell bundled in cli.js
+- Wave 2 (DEFERRED): SquadUI — waits for shell foundation
+- Wave 3 (ADJUSTED): Public Docs — now documents shell as primary interface
+
+### Decision Framing
+
+**Format:** "Recommendation: X (recommended) or alternatives?"
+
+**Components:**
+- Recommendation (pick one, justify)
+- Alternatives (what else was considered)
+- Decision rationale (why recommended option wins)
+- Needs sign-off from (which agents/roles must approve)
+
+**Example:**
+```
+### 1. Terminal UI Library: `ink` (recommended) or alternatives?
+
+**Recommendation:** `ink`  
+**Alternatives:** `blessed`, raw readline  
+**Decision rationale:** Component model enables testable UI. Battle-tested ecosystem.
+
+**Needs sign-off from:** Brady (product direction), Fortier (runtime performance)
+```
+
+### Risk Documentation
+
+**Format per risk:**
+- **Risk:** Specific failure mode
+- **Likelihood:** Low / Medium / High (not percentages)
+- **Impact:** Low / Medium / High
+- **Mitigation:** Concrete actions (measurable)
+
+**Example:**
+```
+### Risk 2: SDK Streaming Reliability
+
+**Risk:** SDK streaming events might drop messages or arrive out of order.  
+**Likelihood:** Low (SDK is production-grade).  
+**Impact:** High — broken streaming makes shell unusable.
+
+**Mitigation:**
+- Add integration test: Send 1000-message stream, verify all deltas arrive in order
+- Implement fallback: If streaming fails, fall back to polling session state
+- Log all SDK events to `.squad/orchestration-log/sdk-events.jsonl` for debugging
+```
+
+## Examples
+
+**File references from interactive shell proposal:**
+- Full proposal: `docs/proposals/squad-interactive-shell.md`
+- User directive: `.squad/decisions/inbox/copilot-directive-2026-02-21T202535Z.md`
+- Team decisions: `.squad/decisions.md`
+- Current architecture: `docs/architecture/module-map.md`, `docs/prd-23-release-readiness.md`
+
+**Key patterns demonstrated:**
+1. Read user directive first (understand the "why")
+2. Survey current architecture (module map, existing waves)
+3. Research SDK APIs (exploration task to validate feasibility)
+4. Document problem with specific evidence (unreliable handoffs, zero visibility, UX mismatch)
+5. Propose solution with technical specifics (ink components, SDK session management, spawn.ts module)
+6. Restructure waves when foundation shifts (Wave 0 becomes blocker)
+7. Preserve backward compatibility (squad.agent.md still works, VS Code mode unchanged)
+8. Frame decisions explicitly (5 key decisions with recommendations)
+9. Document risks with mitigations (5 risks, each with concrete actions)
+10. Define scope (what's in v1 vs. deferred)
+
+## Anti-Patterns
+
+**Avoid:**
+- ❌ Proposals without problem statements (solution-first thinking)
+- ❌ Vague architecture ("we'll use a shell") — be specific (ink components, session registry, spawn.ts)
+- ❌ Ignoring existing work — always document impact on waves/milestones
+- ❌ No risk analysis — every architecture has risks, document them
+- ❌ Unbounded scope — draw the v1 line explicitly
+- ❌ Missing decision ownership — always say "needs sign-off from X"
+- ❌ No backward compatibility plan — users don't care about your replatform
+- ❌ Hand-waving timelines ("a few weeks") — be specific (2-3 weeks, 1 engineer full-time)
+
+**Red flags in proposal reviews:**
+- "Users will love this" (citation needed)
+- "We'll figure out X later" (scope creep incoming)
+- "This is revolutionary" (tone ceiling violation)
+- No section on "What Stays the Same" (regression risk)
+- No risks documented (wishful thinking)

package/templates/skills/ci-validation-gates/SKILL.md

@@ -1,84 +1,84 @@
----
-name: "ci-validation-gates"
-description: "Defensive CI/CD patterns: semver validation, token checks, retry logic, draft detection — earned from v0.8.22"
-domain: "ci-cd"
-confidence: "high"
-source: "extracted from Drucker and Trejo charters — earned knowledge from v0.8.22 release incident"
----
-
-## Context
-
-CI workflows must be defensive. These patterns were learned from the v0.8.22 release disaster where invalid semver, wrong token types, missing retry logic, and draft releases caused a multi-hour outage. Both Drucker (CI/CD) and Trejo (Release Manager) carried this knowledge in their charters — now centralized here.
-
-## Patterns
-
-### Semver Validation Gate
-Every publish workflow MUST validate version format before `npm publish`. 4-part versions (e.g., 0.8.21.4) are NOT valid semver — npm mangles them.
-
-```yaml
-- name: Validate semver
-  run: |
-    VERSION="${{ github.event.release.tag_name }}"
-    VERSION="${VERSION#v}"
-    if ! npx semver "$VERSION" > /dev/null 2>&1; then
-      echo "❌ Invalid semver: $VERSION"
-      echo "Only 3-part versions (X.Y.Z) or prerelease (X.Y.Z-tag.N) are valid."
-      exit 1
-    fi
-    echo "✅ Valid semver: $VERSION"
-```
-
-### NPM Token Type Verification
-NPM_TOKEN MUST be an Automation token, not a User token with 2FA:
-- User tokens require OTP — CI can't provide it → EOTP error
-- Create Automation tokens at npmjs.com → Settings → Access Tokens → Automation
-- Verify before first publish in any workflow
-
-### Retry Logic for npm Registry Propagation
-npm registry uses eventual consistency. After `npm publish` succeeds, the package may not be immediately queryable.
-- Propagation: typically 5-30s, up to 2min in rare cases
-- All verify steps: 5 attempts, 15-second intervals
-- Log each attempt: "Attempt 1/5: Checking package..."
-- Exit loop on success, fail after max attempts
-
-```yaml
-- name: Verify package (with retry)
-  run: |
-    MAX_ATTEMPTS=5
-    WAIT_SECONDS=15
-    for attempt in $(seq 1 $MAX_ATTEMPTS); do
-      echo "Attempt $attempt/$MAX_ATTEMPTS: Checking $PACKAGE@$VERSION..."
-      if npm view "$PACKAGE@$VERSION" version > /dev/null 2>&1; then
-        echo "✅ Package verified"
-        exit 0
-      fi
-      [ $attempt -lt $MAX_ATTEMPTS ] && sleep $WAIT_SECONDS
-    done
-    echo "❌ Failed to verify after $MAX_ATTEMPTS attempts"
-    exit 1
-```
-
-### Draft Release Detection
-Draft releases don't emit `release: published` event. Workflows MUST:
-- Trigger on `release: published` (NOT `created`)
-- If using workflow_dispatch: verify release is published via GitHub API before proceeding
-
-### Build Script Protection
-Set `SKIP_BUILD_BUMP=1` (or `$env:SKIP_BUILD_BUMP = "1"` on Windows) before ANY release build. bump-build.mjs is for dev builds ONLY — it silently mutates versions.
-
-## Known Failure Modes (v0.8.22 Incident)
-
-| # | What Happened | Root Cause | Prevention |
-|---|---------------|-----------|------------|
-| 1 | 4-part version published, npm mangled it | No semver validation gate | `npx semver` check before every publish |
-| 2 | CI failed 5+ times with EOTP | User token with 2FA | Automation token only |
-| 3 | Verify returned false 404 | No retry logic for propagation | 5 attempts, 15s intervals |
-| 4 | Workflow never triggered | Draft release doesn't emit event | Never create draft releases |
-| 5 | Version mutated during release | bump-build.mjs ran in release | SKIP_BUILD_BUMP=1 |
-
-## Anti-Patterns
-- ❌ Publishing without semver validation gate
-- ❌ Single-shot verification without retry
-- ❌ Hard-coded secrets in workflows
-- ❌ Silent CI failures — every error needs actionable output with remediation
-- ❌ Assuming npm publish is instantly queryable
+---
+name: "ci-validation-gates"
+description: "Defensive CI/CD patterns: semver validation, token checks, retry logic, draft detection — earned from v0.8.22"
+domain: "ci-cd"
+confidence: "high"
+source: "extracted from Drucker and Trejo charters — earned knowledge from v0.8.22 release incident"
+---
+
+## Context
+
+CI workflows must be defensive. These patterns were learned from the v0.8.22 release disaster where invalid semver, wrong token types, missing retry logic, and draft releases caused a multi-hour outage. Both Drucker (CI/CD) and Trejo (Release Manager) carried this knowledge in their charters — now centralized here.
+
+## Patterns
+
+### Semver Validation Gate
+Every publish workflow MUST validate version format before `npm publish`. 4-part versions (e.g., 0.8.21.4) are NOT valid semver — npm mangles them.
+
+```yaml
+- name: Validate semver
+  run: |
+    VERSION="${{ github.event.release.tag_name }}"
+    VERSION="${VERSION#v}"
+    if ! npx semver "$VERSION" > /dev/null 2>&1; then
+      echo "❌ Invalid semver: $VERSION"
+      echo "Only 3-part versions (X.Y.Z) or prerelease (X.Y.Z-tag.N) are valid."
+      exit 1
+    fi
+    echo "✅ Valid semver: $VERSION"
+```
+
+### NPM Token Type Verification
+NPM_TOKEN MUST be an Automation token, not a User token with 2FA:
+- User tokens require OTP — CI can't provide it → EOTP error
+- Create Automation tokens at npmjs.com → Settings → Access Tokens → Automation
+- Verify before first publish in any workflow
+
+### Retry Logic for npm Registry Propagation
+npm registry uses eventual consistency. After `npm publish` succeeds, the package may not be immediately queryable.
+- Propagation: typically 5-30s, up to 2min in rare cases
+- All verify steps: 5 attempts, 15-second intervals
+- Log each attempt: "Attempt 1/5: Checking package..."
+- Exit loop on success, fail after max attempts
+
+```yaml
+- name: Verify package (with retry)
+  run: |
+    MAX_ATTEMPTS=5
+    WAIT_SECONDS=15
+    for attempt in $(seq 1 $MAX_ATTEMPTS); do
+      echo "Attempt $attempt/$MAX_ATTEMPTS: Checking $PACKAGE@$VERSION..."
+      if npm view "$PACKAGE@$VERSION" version > /dev/null 2>&1; then
+        echo "✅ Package verified"
+        exit 0
+      fi
+      [ $attempt -lt $MAX_ATTEMPTS ] && sleep $WAIT_SECONDS
+    done
+    echo "❌ Failed to verify after $MAX_ATTEMPTS attempts"
+    exit 1
+```
+
+### Draft Release Detection
+Draft releases don't emit `release: published` event. Workflows MUST:
+- Trigger on `release: published` (NOT `created`)
+- If using workflow_dispatch: verify release is published via GitHub API before proceeding
+
+### Build Script Protection
+Set `SKIP_BUILD_BUMP=1` (or `$env:SKIP_BUILD_BUMP = "1"` on Windows) before ANY release build. bump-build.mjs is for dev builds ONLY — it silently mutates versions.
+
+## Known Failure Modes (v0.8.22 Incident)
+
+| # | What Happened | Root Cause | Prevention |
+|---|---------------|-----------|------------|
+| 1 | 4-part version published, npm mangled it | No semver validation gate | `npx semver` check before every publish |
+| 2 | CI failed 5+ times with EOTP | User token with 2FA | Automation token only |
+| 3 | Verify returned false 404 | No retry logic for propagation | 5 attempts, 15s intervals |
+| 4 | Workflow never triggered | Draft release doesn't emit event | Never create draft releases |
+| 5 | Version mutated during release | bump-build.mjs ran in release | SKIP_BUILD_BUMP=1 |
+
+## Anti-Patterns
+- ❌ Publishing without semver validation gate
+- ❌ Single-shot verification without retry
+- ❌ Hard-coded secrets in workflows
+- ❌ Silent CI failures — every error needs actionable output with remediation
+- ❌ Assuming npm publish is instantly queryable

package/templates/skills/cli-wiring/SKILL.md

@@ -1,47 +1,47 @@
-# Skill: CLI Command Wiring
-
-**Bug class:** Commands implemented in `packages/squad-cli/src/cli/commands/` but never routed in `cli-entry.ts`.
-
-## Checklist — Adding a New CLI Command
-
-1. **Create command file** in `packages/squad-cli/src/cli/commands/<name>.ts`
-   - Export a `run<Name>(cwd, options)` async function (or class with static methods for utility modules)
-
-2. **Add routing block** in `packages/squad-cli/src/cli-entry.ts` inside `main()`:
-   ```ts
-   if (cmd === '<name>') {
-     const { run<Name> } = await import('./cli/commands/<name>.js');
-     // parse args, call function
-     await run<Name>(process.cwd(), options);
-     return;
-   }
-   ```
-
-3. **Add help text** in the help section of `cli-entry.ts` (search for `Commands:`):
-   ```ts
-   console.log(`  ${BOLD}<name>${RESET}     <description>`);
-   console.log(`             Usage: <name> [flags]`);
-   ```
-
-4. **Verify both exist** — the recurring bug is doing step 1 but missing steps 2-3.
-
-## Wiring Patterns by Command Type
-
-| Type | Example | How to wire |
-|------|---------|-------------|
-| Standard command | `export.ts`, `build.ts` | `run*()` function, parse flags from `args` |
-| Placeholder command | `loop`, `hire` | Inline in cli-entry.ts, prints pending message |
-| Utility/check module | `rc-tunnel.ts`, `copilot-bridge.ts` | Wire as diagnostic check (e.g., `isDevtunnelAvailable()`) |
-| Subcommand of another | `init-remote.ts` | Already used inside parent + standalone alias |
-
-## Common Import Pattern
-
-```ts
-import { BOLD, RESET, DIM, RED, GREEN, YELLOW } from './cli/core/output.js';
-```
-
-Use dynamic `await import()` for command modules to keep startup fast (lazy loading).
-
-## History
-
-- **#237 / PR #244:** 4 commands wired (rc, copilot-bridge, init-remote, rc-tunnel). aspire, link, loop, hire were already present.
+# Skill: CLI Command Wiring
+
+**Bug class:** Commands implemented in `packages/squad-cli/src/cli/commands/` but never routed in `cli-entry.ts`.
+
+## Checklist — Adding a New CLI Command
+
+1. **Create command file** in `packages/squad-cli/src/cli/commands/<name>.ts`
+   - Export a `run<Name>(cwd, options)` async function (or class with static methods for utility modules)
+
+2. **Add routing block** in `packages/squad-cli/src/cli-entry.ts` inside `main()`:
+   ```ts
+   if (cmd === '<name>') {
+     const { run<Name> } = await import('./cli/commands/<name>.js');
+     // parse args, call function
+     await run<Name>(process.cwd(), options);
+     return;
+   }
+   ```
+
+3. **Add help text** in the help section of `cli-entry.ts` (search for `Commands:`):
+   ```ts
+   console.log(`  ${BOLD}<name>${RESET}     <description>`);
+   console.log(`             Usage: <name> [flags]`);
+   ```
+
+4. **Verify both exist** — the recurring bug is doing step 1 but missing steps 2-3.
+
+## Wiring Patterns by Command Type
+
+| Type | Example | How to wire |
+|------|---------|-------------|
+| Standard command | `export.ts`, `build.ts` | `run*()` function, parse flags from `args` |
+| Placeholder command | `loop`, `hire` | Inline in cli-entry.ts, prints pending message |
+| Utility/check module | `rc-tunnel.ts`, `copilot-bridge.ts` | Wire as diagnostic check (e.g., `isDevtunnelAvailable()`) |
+| Subcommand of another | `init-remote.ts` | Already used inside parent + standalone alias |
+
+## Common Import Pattern
+
+```ts
+import { BOLD, RESET, DIM, RED, GREEN, YELLOW } from './cli/core/output.js';
+```
+
+Use dynamic `await import()` for command modules to keep startup fast (lazy loading).
+
+## History
+
+- **#237 / PR #244:** 4 commands wired (rc, copilot-bridge, init-remote, rc-tunnel). aspire, link, loop, hire were already present.