@opendash-ai/cli 0.1.0-beta.1 → 0.1.0-beta.3

package/src/skill/compose/.bundle/parallel/SKILL.md

@@ -1,168 +0,0 @@
----
-name: compose:parallel
-hidden: true
-description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
----
-
-# Dispatching Parallel Agents
-
-## Overview
-
-You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
-
-When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
-
-**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.
-
-## When to Use
-
-1. Multiple failures? — No → not applicable
-2. Are they independent? — No (related) → single agent investigates all
-3. Can they work in parallel? — No (shared state) → sequential agents / Yes → **parallel dispatch**
-
-**Use when:**
-- 3+ test files failing with different root causes
-- Multiple subsystems broken independently
-- Each problem can be understood without context from others
-- No shared state between investigations
-
-**Don't use when:**
-- Failures are related (fix one might fix others)
-- Need to understand full system state
-- Agents would interfere with each other
-
-## The Pattern
-
-### 1. Identify Independent Domains
-
-Group failures by what's broken:
-- File A tests: Tool approval flow
-- File B tests: Batch completion behavior
-- File C tests: Abort functionality
-
-Each domain is independent - fixing tool approval doesn't affect abort tests.
-
-### 2. Create Focused Agent Tasks
-
-Each agent gets:
-- **Specific scope:** One test file or subsystem
-- **Clear goal:** Make these tests pass
-- **Constraints:** Don't change other code
-- **Expected output:** Summary of what you found and fixed
-
-### 3. Dispatch in Parallel
-
-Send one concurrent tool call per independent problem domain, all in the same turn. Use whichever subagent-dispatch tool is advertised in your tool list, following the syntax in that tool's own description (do not invent fields).
-
-Conceptual shape (example with three domains; use as many as you have):
-- agent → "Fix agent-tool-abort.test.ts failures"
-- agent → "Fix batch-completion-behavior.test.ts failures"
-- agent → "Fix tool-approval-race-conditions.test.ts failures"
-
-### 4. Review and Integrate
-
-When agents return:
-- Read each summary
-- Verify fixes don't conflict
-- Run full test suite
-- Integrate all changes
-
-## Agent Prompt Structure
-
-Good agent prompts are:
-1. **Focused** - One clear problem domain
-2. **Self-contained** - All context needed to understand the problem
-3. **Specific about output** - What should the agent return?
-
-```markdown
-Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
-
-1. "should abort tool with partial output capture" - expects 'interrupted at' in message
-2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
-3. "should properly track pendingToolCount" - expects 3 results but gets 0
-
-These are timing/race condition issues. Your task:
-
-1. Read the test file and understand what each test verifies
-2. Identify root cause - timing issues or actual bugs?
-3. Fix by:
-   - Replacing arbitrary timeouts with event-based waiting
-   - Fixing bugs in abort implementation if found
-   - Adjusting test expectations if testing changed behavior
-
-Do NOT just increase timeouts - find the real issue.
-
-Return: Summary of what you found and what you fixed.
-```
-
-## Common Mistakes
-
-**❌ Too broad:** "Fix all the tests" - agent gets lost
-**✅ Specific:** "Fix agent-tool-abort.test.ts" - focused scope
-
-**❌ No context:** "Fix the race condition" - agent doesn't know where
-**✅ Context:** Paste the error messages and test names
-
-**❌ No constraints:** Agent might refactor everything
-**✅ Constraints:** "Do NOT change production code" or "Fix tests only"
-
-**❌ Vague output:** "Fix it" - you don't know what changed
-**✅ Specific:** "Return summary of root cause and changes"
-
-## When NOT to Use
-
-**Related failures:** Fixing one might fix others - investigate together first
-**Need full context:** Understanding requires seeing entire system
-**Exploratory debugging:** You don't know what's broken yet
-**Shared state:** Agents would interfere (editing same files, using same resources)
-
-## Real Example from Session
-
-**Scenario:** 6 test failures across 3 files after major refactoring
-
-**Failures:**
-- agent-tool-abort.test.ts: 3 failures (timing issues)
-- batch-completion-behavior.test.ts: 2 failures (tools not executing)
-- tool-approval-race-conditions.test.ts: 1 failure (execution count = 0)
-
-**Decision:** Independent domains - abort logic separate from batch completion separate from race conditions
-
-**Dispatch:**
-```
-Agent 1 → Fix agent-tool-abort.test.ts
-Agent 2 → Fix batch-completion-behavior.test.ts
-Agent 3 → Fix tool-approval-race-conditions.test.ts
-```
-
-**Results:**
-- Agent 1: Replaced timeouts with event-based waiting
-- Agent 2: Fixed event structure bug (threadId in wrong place)
-- Agent 3: Added wait for async tool execution to complete
-
-**Integration:** All fixes independent, no conflicts, full suite green
-
-**Time saved:** 3 problems solved in parallel vs sequentially
-
-## Key Benefits
-
-1. **Parallelization** - Multiple investigations happen simultaneously
-2. **Focus** - Each agent has narrow scope, less context to track
-3. **Independence** - Agents don't interfere with each other
-4. **Speed** - 3 problems solved in time of 1
-
-## Verification
-
-After agents return:
-1. **Review each summary** - Understand what changed
-2. **Check for conflicts** - Did agents edit same code?
-3. **Run full suite** - Verify all fixes work together
-4. **Spot check** - Agents can make systematic errors
-
-## Real-World Impact
-
-From debugging session (2025-10-03):
-- 6 failures across 3 files
-- 3 agents dispatched in parallel
-- All investigations completed concurrently
-- All fixes integrated successfully
-- Zero conflicts between agent changes

package/src/skill/compose/.bundle/plan/SKILL.md

@@ -1,183 +0,0 @@
----
-name: compose:plan
-hidden: true
-description: Use when you have a spec or requirements for a multi-step task, before touching code
----
-
-# Writing Plans
-
-## Overview
-
-Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
-
-Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
-
-**Announce at start:** "I'm using the compose:plan skill to create the implementation plan."
-
-**Context:** If working in an isolated worktree, it should have been created via the `compose:worktree` skill at execution time.
-
-**Save plans to:** the `plans/` directory given in the `<compose_docs_dir>` block of your prompt, as `YYYY-MM-DD-<feature-name>.md`.
-- (User preferences for plan location override this default)
-
-## Scope Check
-
-If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.
-
-## File Structure
-
-Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
-
-- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.
-- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.
-- Files that change together should live together. Split by responsibility, not by technical layer.
-- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.
-
-This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.
-
-## Task Right-Sizing
-
-A task is the smallest unit that carries its own test cycle and is worth a
-fresh reviewer's gate. When drawing task boundaries:
-
-- Fold setup, configuration, scaffolding, and documentation steps into the task whose deliverable needs them
-- Split only where a reviewer could meaningfully reject one task while approving its neighbor
-- Each task ends with an independently testable deliverable
-
-## Bite-Sized Task Granularity
-
-**Each step is one action (2-5 minutes):**
-- "Write the failing test" - step
-- "Run it to make sure it fails" - step
-- "Implement the minimal code to make the test pass" - step
-- "Run the tests and make sure they pass" - step
-- "Commit" - step
-
-## Plan Document Header
-
-**Every plan MUST start with this header:**
-
-```markdown
-# [Feature Name] Implementation Plan
-
-> **For agentic workers:** REQUIRED SUB-SKILL: Use compose:subagent (recommended) or compose:execute to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
-
-**Goal:** [One sentence describing what this builds]
-
-**Architecture:** [2-3 sentences about approach]
-
-**Tech Stack:** [Key technologies/libraries]
-
-## Global Constraints
-
-[Project-wide requirements that bind EVERY task — version floors, dependency
-limits, naming and copy rules, platform requirements, exact values. One line
-each, copied verbatim from the spec. Implementers and reviewers downstream
-implicitly inherit this section without being told individually.]
-
----
-```
-
-## Task Structure
-
-````markdown
-### Task N: [Component Name]
-
-**Covers:** [S3, S7]
-<!-- spec section anchors this task implements; every task that produces
-     spec-required behavior must list at least one. Omit only for pure
-     scaffolding tasks (e.g. project setup) that map to no spec section. -->
-
-**Files:**
-- Create: `exact/path/to/file.py`
-- Modify: `exact/path/to/existing.py:123-145`
-- Test: `tests/exact/path/to/test.py`
-
-**Interfaces:**
-- Consumes: [what this task uses from earlier tasks — exact signatures, types]
-- Produces: [what later tasks rely on — exact function names, parameter and
-  return types. An implementer sees only its own task; this block is how it
-  learns the names and types neighboring tasks use.]
-
-- [ ] **Step 1: Write the failing test**
-
-```python
-def test_specific_behavior():
-    result = function(input)
-    assert result == expected
-```
-
-- [ ] **Step 2: Run test to verify it fails**
-
-Run: `pytest tests/path/test.py::test_name -v`
-Expected: FAIL with "function not defined"
-
-- [ ] **Step 3: Write minimal implementation**
-
-```python
-def function(input):
-    return expected
-```
-
-- [ ] **Step 4: Run test to verify it passes**
-
-Run: `pytest tests/path/test.py::test_name -v`
-Expected: PASS
-
-- [ ] **Step 5: Commit**
-
-```bash
-git add tests/path/test.py src/path/file.py
-git commit -m "feat: add specific feature"
-```
-````
-
-## No Placeholders
-
-Every step must contain the actual content an engineer needs. These are **plan failures** — never write them:
-- "TBD", "TODO", "implement later", "fill in details"
-- "Add appropriate error handling" / "add validation" / "handle edge cases"
-- "Write tests for the above" (without actual test code)
-- "Similar to Task N" (repeat the code — the engineer may be reading tasks out of order)
-- Steps that describe what to do without showing how (code blocks required for code steps)
-- References to types, functions, or methods not defined in any task
-
-## Remember
-- Exact file paths always
-- Complete code in every step — if a step changes code, show the code
-- Exact commands with expected output
-- DRY, YAGNI, TDD, frequent commits
-
-## Self-Review
-
-After writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself — not a subagent dispatch.
-
-**1. Spec coverage:** Skim each `[Sn]` section in the spec. Can you point to a task whose **Covers:** lists it? Every spec section must be covered by at least one task. Conversely, every `Covers:` ID must resolve to a real spec section. List any gap in either direction and add or fix the task.
-
-**2. Placeholder scan:** Search your plan for red flags — any of the patterns from the "No Placeholders" section above. Fix them.
-
-**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.
-
-If you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task.
-
-## Execution Handoff
-
-After saving the plan, determine execution approach:
-
-1. **Check memory** for a saved `execution-style` preference in the `compose-preferences` memory file. If found (`subagent` or `inline`), use it and skip to the handler below.
-
-2. **If no saved preference,** ask through `compose:ask`:
-   - header: `Execution`
-   - question: `Plan saved. How would you like to execute it?`
-   - options:
-     - label: `Subagent, always`, description: `Fresh subagent per task — remember for future sessions`
-     - label: `Subagent, this time`, description: `Fresh subagent per task — just this once`
-     - label: `Inline, always`, description: `Execute in this session — remember for future sessions`
-     - label: `Inline, this time`, description: `Execute in this session — just this once`
-
-   If no user is available, default to Inline for ≤ 3 tasks or tightly coupled tasks, Subagent for > 3 independent tasks.
-
-3. **If "always" variant:** Save to the `compose-preferences` memory file as `execution-style: subagent` or `execution-style: inline`.
-
-**If Subagent:** Use compose:subagent — fresh subagent per task + two-stage review.
-
-**If Inline:** Use compose:execute — batch execution with checkpoints

package/src/skill/compose/.bundle/plan/plan-document-reviewer-prompt.md

@@ -1,50 +0,0 @@
-# Plan Document Reviewer Prompt Template
-
-Use this template when dispatching a plan document reviewer subagent.
-
-**Purpose:** Verify the plan is complete, matches the spec, and has proper task decomposition.
-
-**Dispatch after:** The complete plan is written.
-
-Dispatch a `general` subagent via the `actor` tool, following the syntax in that
-tool's own description. Use a title like "Review plan document" with this prompt:
-
-~~~
-    You are a plan document reviewer. Verify this plan is complete and ready for implementation.
-
-    **Plan to review:** [PLAN_FILE_PATH]
-    **Spec for reference:** [SPEC_FILE_PATH]
-
-    ## What to Check
-
-    | Category | What to Look For |
-    |----------|------------------|
-    | Completeness | TODOs, placeholders, incomplete tasks, missing steps |
-    | Spec Alignment | Plan covers spec requirements, no major scope creep |
-    | Task Decomposition | Tasks have clear boundaries, steps are actionable |
-    | Buildability | Could an engineer follow this plan without getting stuck? |
-    | Spec Coverage | Build a matrix of spec `[Sn]` sections vs task **Covers:** lists. Flag any spec section covered by no task, and any `Covers:` ID that resolves to no spec section. |
-
-    ## Calibration
-
-    **Only flag issues that would cause real problems during implementation.**
-    An implementer building the wrong thing or getting stuck is an issue.
-    Minor wording, stylistic preferences, and "nice to have" suggestions are not.
-
-    Approve unless there are serious gaps — missing requirements from the spec,
-    contradictory steps, placeholder content, or tasks so vague they can't be acted on.
-
-    ## Output Format
-
-    ## Plan Review
-
-    **Status:** Approved | Issues Found
-
-    **Issues (if any):**
-    - [Task X, Step Y]: [specific issue] - [why it matters for implementation]
-
-    **Recommendations (advisory, do not block approval):**
-    - [suggestions for improvement]
-~~~
-
-**Reviewer returns:** Status, Issues (if any), Recommendations

package/src/skill/compose/.bundle/report/SKILL.md

@@ -1,180 +0,0 @@
----
-name: compose:report
-hidden: true
-description: "Use after implementation is verified and before merge — consolidates multiple spec iterations into a single final-state report, marks related specs, and records key lessons"
----
-
-# Writing Final Reports
-
-## Overview
-
-Consolidate a feature's spec history into a single human-readable final report. The report presents the final implemented state as its primary content — what WAS BUILT, not what was tried. A brief Journey Log at the end captures notable failures and pivots for future designers.
-
-**Core principle:** Final state first. The reader should understand the feature from this report alone, without reading any spec.
-
-**Announce at start:** "I'm using the report skill to write the final report for this feature."
-
-**Save reports to:** the `reports/` directory given in the `<compose_docs_dir>` block of your prompt, as `<feature-name>.md`
-- No date in filename — the report is overwritten in place when the feature evolves
-- Git history tracks revisions
-- User preferences for report location override this default
-
-## Update Semantics
-
-Specs are **accumulative** (new file per iteration). Final reports are **overwrite** (same file updated in place):
-- If a report already exists for this feature, read it first, then overwrite with updated content
-- Append new Journey Log entries from this iteration (don't discard previous entries)
-- Update the `specs` and `plans` lists to include any new entries
-
-## When to Use
-
-Standard step after implementation is complete and verified — write a final report summarizing what was delivered.
-
-**Skip when:**
-- User explicitly asks to skip the report
-- Change is trivially small (single bug fix, typo, config tweak) and not worth documenting
-
-## Checklist
-
-1. **Identify all related specs and plans** — find every iteration of this feature's design in specs/ and plans/
-2. **Read the implemented code** — understand what actually shipped (code is truth, not specs)
-3. **Draft main sections** — What Was Built, Architecture, Usage, Verification (scale each section to complexity: a few sentences if straightforward, detailed for complex features, but never longer than the plan)
-4. **Draft Journey Log** — brief flat bullet list, max 5 items
-5. **Assemble report** — combine sections, add frontmatter, save to reports/
-6. **Self-review** — verify report against code (not specs), check for placeholders, confirm length is proportional to feature complexity
-7. **Mark specs and plans** — prepend NOTE header to each spec and plan file
-8. **Commit and transition** — commit report + markers, invoke compose:merge
-
-## Report Document Structure
-
-Every report MUST use this structure:
-
-```markdown
----
-feature: <feature-name>
-status: delivered
-specs:
-  - <spec-1-path>
-  - <spec-2-path>
-plans:
-  - <plan-path>
-branch: <branch-name>
-commits: <first-sha>..<last-sha>
----
-
-# [Feature Name] — Final Report
-
-## What Was Built
-
-[1-3 paragraph executive summary. What does the feature do? What problem
-does it solve? Written for first contact — no "v1 tried X" narrative.]
-
-## Architecture
-
-[Final architecture as implemented. Components, boundaries, data flow,
-key interfaces. Self-contained — reader needs no spec file.]
-
-### Design Decisions
-
-[Important choices and rationale. Frame as "we chose X because Y" —
-never "we tried A, then B, then settled on X".]
-
-## Usage
-
-[How to use/configure/interact. Commands, config options, API surface.
-Concrete examples.]
-
-## Verification
-
-[How the feature was verified. Test summary, manual testing, edge cases.]
-
-## Journey Log
-
-> Brief notes on what informed the final design. Not required reading.
-
-- [dead end] Tried X — failed because Y
-- [pivot] Switched from A to B after discovering C
-- [lesson] Transferable insight here
-
-## Source Materials
-
-| File | Role | Notes |
-|------|------|-------|
-| `path/to/spec-1.md` | Initial design | See §3 for context on constraint X |
-| `path/to/spec-2.md` | Revised after Y | Superseded by this report |
-| `path/to/plan.md` | Implementation plan | Complete |
-```
-
-## Marking Specs and Plans
-
-For each file listed in `specs` and `plans`, insert this NOTE block between the document title (H1) and the rest of the content:
-
-```markdown
-> [!NOTE]
-> This document may not reflect the current implementation.
-> See the final report for up-to-date state:
-> [Final Report](../reports/<feature-name>.md)
-```
-
-**Rules:**
-- Place between the H1 title and remaining content
-- Do NOT move or delete files (git history and links preserved)
-- Do NOT modify the body below the marker
-- The marker is idempotent (can be re-applied safely)
-- Use GitHub-compatible admonition syntax (`[!NOTE]`, not `[!CAUTION]`)
-
-## Writing Guidelines
-
-**Scale to complexity:**
-- Simple feature: each main section is 1-2 paragraphs
-- Complex feature: detailed sections, but the report should never exceed the plan in length
-- If it's getting longer than the plan, you're over-documenting
-
-**"What Was Built" section:**
-- Write as if this feature always existed in its current form
-- No historical narrative, no "originally we planned..."
-- A new team member should understand the feature from this section alone
-
-**"Architecture" section:**
-- Derive from CODE, not from specs (specs may have drifted)
-- If code and spec disagree, document what the code does
-- Include file paths, key types, data flow
-
-**"Design Decisions" section:**
-- Only include decisions that would surprise a reader or that have non-obvious rationale
-- "We chose X because Y" format — NOT "we tried A, B, C and settled on X"
-- If a decision's rationale is obvious from the code, skip it
-
-**"Journey Log":**
-- Flat bullet list, max 5 items total
-- Each item prefixed with `[dead end]`, `[pivot]`, or `[lesson]`
-- Each item is 1-2 sentences
-- Only include items that would help a FUTURE designer avoid the same mistakes
-
-## Self-Review Checklist
-
-After assembling the report, check:
-1. **Accuracy** — Does the report match the code? (grep key function names, verify file paths exist)
-2. **Self-contained** — Can a reader understand the feature without reading any spec?
-3. **No placeholders** — No "TBD", "TODO", or "fill in later"
-4. **Length proportional** — Not longer than the plan, not shorter than 1 paragraph per section
-5. **Journey Log brief** — Max 5 items, each 1-2 sentences
-
-## Key Principles
-
-- **Final state first** — Report describes "what is", not "what was tried"
-- **Self-contained** — Reader needs only this report to understand the feature
-- **Code is truth** — When specs and code diverge, document what code does
-- **Journey is secondary** — Journey Log serves future designers, not understanding
-- **Non-destructive** — Specs and plans get soft markers, never deleted or moved
-- **Machine-readable** — Frontmatter `specs`/`plans` lists enable tooling
-- **Bidirectional** — Report links to specs/plans, they link back to report
-
-## Integration
-
-**Preceded by:** compose:verify (feature must be verified before documenting)
-**Followed by:** compose:merge (the terminal workflow step)
-
-After saving the report and marking specs, offer transition:
-
-> "Final report written and committed to `<path>`. Related specs marked. Ready to finish the branch — invoking compose:merge."

package/src/skill/compose/.bundle/review/SKILL.md

@@ -1,104 +0,0 @@
----
-name: compose:review
-hidden: true
-description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements
----
-
-# Requesting Code Review
-
-Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.
-
-**Core principle:** Review early, review often.
-
-## When to Request Review
-
-**Mandatory:**
-- After each task in subagent-driven development
-- After completing major feature
-- Before merge to main
-
-**Optional but valuable:**
-- When stuck (fresh perspective)
-- Before refactoring (baseline check)
-- After fixing complex bug
-
-## How to Request
-
-**1. Get git SHAs:**
-```bash
-BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-**2. Dispatch code reviewer subagent:**
-
-Use the `actor` tool to dispatch a `general` subagent (follow that tool's own description for the call syntax), building its prompt from the `code-reviewer.md` template
-
-**Placeholders:**
-- `{DESCRIPTION}` - Brief summary of what you built
-- `{PLAN_OR_REQUIREMENTS}` - What it should do
-- `{BASE_SHA}` - Starting commit
-- `{HEAD_SHA}` - Ending commit
-
-**3. Act on feedback:**
-- Fix Critical issues immediately
-- Fix Important issues before proceeding
-- Note Minor issues for later
-- Push back if reviewer is wrong (with reasoning)
-
-## Example
-
-```
-[Just completed Task 2: Add verification function]
-
-You: Let me request code review before proceeding.
-
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
-HEAD_SHA=$(git rev-parse HEAD)
-
-[Dispatch code reviewer subagent]
-  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
-  PLAN_OR_REQUIREMENTS: Task 2 from plans/deployment-plan.md
-  BASE_SHA: a7981ec
-  HEAD_SHA: 3df7661
-
-[Subagent returns]:
-  Strengths: Clean architecture, real tests
-  Issues:
-    Important: Missing progress indicators
-    Minor: Magic number (100) for reporting interval
-  Assessment: Ready to proceed
-
-You: [Fix progress indicators]
-[Continue to Task 3]
-```
-
-## Integration with Workflows
-
-**Subagent-Driven Development:**
-- Review after EACH task
-- Catch issues before they compound
-- Fix before moving to next task
-
-**Executing Plans:**
-- Review after each task or at natural checkpoints
-- Get feedback, apply, continue
-
-**Ad-Hoc Development:**
-- Review before merge
-- Review when stuck
-
-## Red Flags
-
-**Never:**
-- Skip review because "it's simple"
-- Ignore Critical issues
-- Proceed with unfixed Important issues
-- Argue with valid technical feedback
-
-**If reviewer wrong:**
-- Push back with technical reasoning
-- Show code/tests that prove it works
-- Request clarification
-
-See template at: `<compose:review>/code-reviewer.md`