oh-my-customcode 0.20.0 → 0.22.0

package/README.md

@@ -21,7 +21,7 @@ Like oh-my-zsh transformed shell customization, oh-my-customcode makes personali
 
 | Feature | Description |
 |---------|-------------|
-| **Batteries Included** | 41 agents, 55 skills, 22 guides, 18 rules, 2 hooks, 4 contexts, ontology graph - ready to use out of the box |
+| **Batteries Included** | 41 agents, 63 skills, 22 guides, 18 rules, 2 hooks, 4 contexts, ontology graph - ready to use out of the box |
 | **Sub-Agent Model** | Supports hierarchical agent orchestration with specialized roles |
 | **Dead Simple Customization** | Create a folder + markdown file = new agent or skill |
 | **Mix and Match** | Use built-in components, create your own, or combine both |
@@ -124,20 +124,20 @@ Claude Code selects the appropriate model and parallelizes independent tasks (up
 | **QA** | 3 | qa-planner, qa-writer, qa-engineer |
 | **Total** | **41** | |
 
-### Skills (58)
+### Skills (63)
 
 | Category | Count | Skills |
 |----------|-------|--------|
 | **Routing** | 4 | secretary-routing, dev-lead-routing, de-lead-routing, qa-lead-routing |
 | **Best Practices** | 18 | go-best-practices, python-best-practices, typescript-best-practices, kotlin-best-practices, rust-best-practices, react-best-practices, fastapi-best-practices, springboot-best-practices, go-backend-best-practices, docker-best-practices, aws-best-practices, postgres-best-practices, supabase-postgres-best-practices, redis-best-practices, airflow-best-practices, dbt-best-practices, kafka-best-practices, snowflake-best-practices |
-| **Development** | 5 | dev-review, dev-refactor, create-agent, intent-detection, web-design-guidelines |
+| **Development** | 6 | dev-review, dev-refactor, create-agent, intent-detection, web-design-guidelines, analysis |
 | **Data Engineering** | 2 | spark-best-practices, pipeline-architecture-patterns |
 | **Optimization** | 3 | optimize-analyze, optimize-bundle, optimize-report |
 | **Memory** | 3 | memory-save, memory-recall, memory-management |
 | **Package Management** | 3 | npm-publish, npm-version, npm-audit |
 | **Operations** | 7 | update-docs, update-external, audit-agents, fix-refs, sauron-watch, monitoring-setup, claude-code-bible |
 | **Utilities** | 5 | lists, help, status, result-aggregation, writing-clearly-and-concisely |
-| **Quality & Workflow** | 4 | multi-model-verification, structured-dev-cycle, model-escalation, stuck-recovery |
+| **Quality & Workflow** | 9 | multi-model-verification, structured-dev-cycle, model-escalation, stuck-recovery, dag-orchestration, task-decomposition, worker-reviewer-pipeline, pr-auto-improve, pipeline-guards |
 | **Deploy** | 2 | vercel-deploy, codex-exec |
 | **External** | 1 | skills-sh-search |
 
@@ -225,7 +225,7 @@ your-project/
     │   ├── be-fastapi-expert.md
     │   ├── mgr-creator.md
     │   └── ...
-    ├── skills/            # Skill modules (55 directories, each with SKILL.md)
+    ├── skills/            # Skill modules (63 directories, each with SKILL.md)
     │   ├── go-best-practices/
     │   ├── react-best-practices/
     │   ├── secretary-routing/

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-customcode",
-  "version": "0.20.0",
+  "version": "0.22.0",
   "description": "Batteries-included agent harness for Claude Code",
   "type": "module",
   "bin": {

package/templates/.claude/skills/dag-orchestration/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: dag-orchestration
+description: YAML-based DAG workflow engine with topological execution and failure strategies
+---
+
+# DAG Orchestration Skill
+
+Defines and executes directed acyclic graph (DAG) workflows. The orchestrator uses this skill to plan multi-step tasks with dependencies, execute them in topologically-sorted order, and handle failures.
+
+**Orchestrator-only** — only the main conversation uses this skill (R010). Subagents execute individual nodes.
+
+## Workflow Spec Format
+
+```yaml
+# .claude/workflows/<name>.yaml or inline in conversation
+workflow:
+  name: feature-implementation
+  description: Implement a new feature with tests and docs
+
+nodes:
+  - id: analyze
+    agent: Explore
+    model: haiku
+    prompt: "Analyze codebase for integration points"
+
+  - id: implement
+    agent: lang-typescript-expert
+    model: sonnet
+    prompt: "Implement the feature"
+    depends_on: [analyze]
+
+  - id: test
+    agent: qa-engineer
+    model: sonnet
+    prompt: "Write and run tests"
+    depends_on: [implement]
+
+  - id: review
+    agent: lang-typescript-expert
+    model: opus
+    prompt: "Code review"
+    depends_on: [implement]
+
+  - id: docs
+    agent: arch-documenter
+    model: sonnet
+    prompt: "Update documentation"
+    depends_on: [implement]
+
+  - id: commit
+    agent: mgr-gitnerd
+    model: sonnet
+    prompt: "Commit changes"
+    depends_on: [test, review, docs]
+
+config:
+  max_parallel: 4          # R009 limit
+  failure_strategy: stop   # stop | skip | retry
+  retry_count: 2           # Max retries per node (if strategy=retry)
+  timeout_per_node: 300    # Seconds per node (0 = no limit)
+```
+
+## Execution Algorithm — Kahn's Topological Sort
+
+```
+1. Parse workflow YAML
+2. Build adjacency list and in-degree map
+3. Validate: detect cycles (error if found)
+4. Initialize queue with nodes where in-degree = 0
+5. While queue is not empty:
+   a. Dequeue up to max_parallel nodes
+   b. Execute nodes in parallel via Task tool (R009)
+   c. On completion:
+      - Success → decrement in-degree of dependents
+      - Failure → apply failure_strategy
+   d. Enqueue newly-ready nodes (in-degree = 0)
+6. Verify all nodes executed (detect unreachable nodes)
+```
+
+## Execution Rules
+
+| Rule | Detail |
+|------|--------|
+| Max parallel | 4 concurrent nodes (R009) |
+| Agent Teams gate | 3+ parallel nodes → check R018 eligibility |
+| Orchestrator only | DAG scheduling runs in main conversation (R010) |
+| Node execution | Each node = one Task tool call to specified agent |
+| State tracking | `/tmp/.claude-dag-$PPID.json` |
+
+## Failure Strategies
+
+| Strategy | Behavior |
+|----------|----------|
+| `stop` | Halt entire DAG on first failure (default) |
+| `skip` | Mark failed node as skipped, continue dependents with warning |
+| `retry` | Retry failed node up to `retry_count` times, then stop |
+
+## State File Format
+
+```json
+{
+  "workflow": "feature-implementation",
+  "started_at": "2026-03-07T10:00:00Z",
+  "status": "running",
+  "nodes": {
+    "analyze": {"status": "completed", "started": "...", "completed": "..."},
+    "implement": {"status": "running", "started": "..."},
+    "test": {"status": "pending"},
+    "review": {"status": "pending"},
+    "docs": {"status": "pending"},
+    "commit": {"status": "blocked", "blocked_by": ["test", "review", "docs"]}
+  },
+  "execution_order": [["analyze"], ["implement"], ["test", "review", "docs"], ["commit"]]
+}
+```
+
+## Display Format
+
+```
+[DAG] feature-implementation — 6 nodes
+[Layer 0] analyze ← running
+[Layer 1] implement ← pending (depends: analyze)
+[Layer 2] test, review, docs ← pending (parallel, depends: implement)
+[Layer 3] commit ← blocked (depends: test, review, docs)
+```
+
+Progress:
+```
+[DAG Progress] 3/6 nodes completed
+  ✓ analyze (12s)
+  ✓ implement (45s)
+  → test (running)
+  → review (running)
+  → docs (running)
+  ○ commit (blocked)
+```
+
+## Common Workflow Templates
+
+### Feature Implementation
+```yaml
+nodes: [analyze → implement → [test, review, docs] → commit]
+```
+
+### Code Review + Fix
+```yaml
+nodes: [review → fix → re-review → commit]
+failure_strategy: retry
+```
+
+### Multi-Language Project
+```yaml
+nodes: [
+  analyze → [impl-frontend, impl-backend, impl-db] → integration-test → commit
+]
+```
+
+### Refactoring
+```yaml
+nodes: [
+  analyze → plan → [refactor-1, refactor-2, refactor-3] → test → review → commit
+]
+```
+
+## Integration
+
+| Rule | Integration |
+|------|-------------|
+| R009 | Max 4 parallel nodes; independent nodes MUST parallelize |
+| R010 | DAG scheduler runs only in orchestrator |
+| R015 | Display DAG plan before execution |
+| R018 | 3+ parallel nodes → check Agent Teams eligibility |
+| model-escalation | Node failures feed into task-outcome-recorder |
+| stuck-recovery | Repeated node failures trigger stuck detection |
+
+## Inline DAG
+
+For ad-hoc workflows without a YAML file:
+
+```
+[DAG Plan]
+1. analyze (Explore:haiku)
+2. implement (lang-typescript-expert:sonnet) ← depends: 1
+3. test (qa-engineer:sonnet) ← depends: 2
+4. review (lang-typescript-expert:opus) ← depends: 2
+5. commit (mgr-gitnerd:sonnet) ← depends: 3, 4
+
+Execute? [Y/n]
+```
+
+The orchestrator builds the DAG from this inline format and executes using the same algorithm.
+
+## Limitations
+
+- No cycles allowed (DAG = acyclic)
+- Max 20 nodes per workflow (complexity guard)
+- Nested DAGs not supported (flatten instead)
+- Cross-workflow dependencies not supported

package/templates/.claude/skills/pipeline-guards/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: pipeline-guards
+description: Safety constraints and quality gates for pipeline and workflow execution
+---
+
+# Pipeline Guards Skill
+
+Defines mandatory safety constraints for all pipeline, workflow, and iterative execution within the oh-my-customcode system. Prevents infinite loops, enforces timeouts, and establishes quality gates.
+
+**System-wide** — these guards apply to dag-orchestration, worker-reviewer-pipeline, and any iterative process.
+
+## Guard Limits
+
+| Guard | Default | Hard Cap | Applies To |
+|-------|---------|----------|------------|
+| Max iterations | 3 | 5 | worker-reviewer-pipeline |
+| Max DAG nodes | 20 | 30 | dag-orchestration |
+| Max parallel agents | 4 | 4 | R009 (all pipelines) |
+| Timeout per node | 300s | 600s | dag-orchestration nodes |
+| Timeout per pipeline | 900s | 1800s | worker-reviewer-pipeline |
+| Max retry count | 2 | 3 | Failure retry strategies |
+| Max PR improvement items | 20 | 50 | pr-auto-improve |
+
+## Enforcement
+
+Guards are enforced at two levels:
+
+### Level 1: Skill-Level (Soft)
+Each skill checks guard limits before execution:
+
+```
+Before starting pipeline:
+  1. Check max_iterations ≤ hard cap
+  2. Check timeout ≤ hard cap
+  3. Check node count ≤ hard cap
+  If any exceeded → warn user, use hard cap value
+```
+
+### Level 2: Hook-Level (Hard)
+The stuck-detector hook monitors for guard violations:
+
+```
+PostToolUse → check:
+  - Iteration count > max_iterations?
+  - Elapsed time > timeout?
+  - Same error repeated > max_retry?
+  If any → emit advisory to stderr
+```
+
+## Quality Gates
+
+### Pipeline Quality Gate
+```
+[Quality Gate Check]
+├── Critical issues: {count} (must be 0)
+├── Major issues: {count} (must be ≤ threshold)
+├── Minor issues: {count} (informational)
+└── Gate: PASS | FAIL
+```
+
+### DAG Completion Gate
+```
+[DAG Completion Gate]
+├── Nodes completed: {n}/{total}
+├── Nodes failed: {count}
+├── Nodes skipped: {count}
+└── Gate: PASS | PARTIAL | FAIL
+```
+
+## Escalation Integration
+
+When guards are triggered, they integrate with existing advisory systems:
+
+| Event | Action |
+|-------|--------|
+| Max iterations reached | → stuck-recovery advisory |
+| Repeated failures | → model-escalation advisory |
+| Timeout approaching (80%) | → warn user, suggest early termination |
+| Hard cap hit | → force stop, report to user |
+
+## Guard Configuration
+
+Pipelines can override defaults (within hard caps):
+
+```yaml
+# In pipeline/workflow spec
+guards:
+  max_iterations: 4          # Override default 3, cannot exceed 5
+  timeout_per_node: 120      # Override default 300s
+  timeout_pipeline: 600      # Override default 900s
+  quality_gate: all_pass     # all_pass | majority_pass
+```
+
+## Kill Switch
+
+When a pipeline or workflow must be terminated:
+
+```
+[Kill Switch] Activated
+├── Reason: {max_iterations | timeout | user_request | stuck_detected}
+├── Pipeline: {name}
+├── Progress: {completed}/{total} steps
+├── Preserved state: /tmp/.claude-pipeline-$PPID.json
+└── Action: Stopped gracefully, state saved for resume
+```
+
+The kill switch:
+1. Signals all running agents to complete current operation
+2. Does NOT terminate mid-write (waits for current tool call)
+3. Saves pipeline state for potential resume
+4. Reports final status to user
+
+## State Preservation
+
+On guard-triggered termination:
+
+```json
+{
+  "pipeline": "feature-review",
+  "terminated_at": "2026-03-07T10:15:00Z",
+  "reason": "max_iterations_reached",
+  "completed_iterations": 3,
+  "last_verdict": "FAIL",
+  "remaining_issues": [
+    {"severity": "major", "file": "src/auth.ts", "line": 42, "description": "..."}
+  ],
+  "worker_last_output": "...",
+  "resumable": true
+}
+```
+
+## Display Format
+
+Guard warnings appear inline:
+
+```
+[Guard] ⚠ Iteration 3/3 — final attempt
+[Guard] ⚠ Timeout 80% (240s/300s) — consider early termination
+[Guard] 🛑 Max iterations reached — pipeline stopped
+[Guard] 🛑 Hard timeout (600s) — force stop
+```
+
+## Integration
+
+| Rule/Skill | Integration |
+|------------|-------------|
+| R009 | Max parallel agents enforced (hard cap: 4) |
+| R010 | Guards run in orchestrator only |
+| R015 | Guard warnings displayed transparently |
+| dag-orchestration | Node count and timeout limits |
+| worker-reviewer-pipeline | Iteration and pipeline timeout limits |
+| pr-auto-improve | Improvement item count limits |
+| stuck-recovery | Guard triggers feed into stuck detection |
+| model-escalation | Repeated failures trigger escalation advisory |
+
+## Override Policy
+
+- Defaults can be overridden in pipeline spec (within hard caps)
+- Hard caps can ONLY be changed by modifying this skill file
+- User cannot bypass hard caps at runtime
+- All overrides are logged and displayed (R015)
+
+## Limitations
+
+- Guards are advisory at skill level, hard at hook level
+- Cannot prevent infinite loops in agent reasoning (only tool call patterns)
+- State preservation is best-effort (process crash = state loss)
+- Resume from saved state requires user confirmation

package/templates/.claude/skills/pr-auto-improve/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: pr-auto-improve
+description: Opt-in post-PR analysis and improvement suggestions for code quality enhancement
+---
+
+# PR Auto-Improvement Skill
+
+Analyzes pull requests after creation and suggests targeted improvements. **Strictly opt-in** — never runs automatically. User must explicitly request PR improvement.
+
+**Advisory-only** — suggests improvements, never force-pushes or modifies PRs without approval (R010).
+
+## Activation
+
+| Trigger | Behavior |
+|---------|----------|
+| User says "improve this PR" | Activate analysis |
+| User says "review PR #N" | Activate analysis |
+| PR created automatically | Do NOT activate (opt-in only) |
+| CI fails on PR | Suggest activation, do not auto-run |
+
+## Analysis Pipeline
+
+```
+1. Fetch PR diff (gh pr diff)
+2. Categorize changes by type:
+   - New code → check patterns, naming, structure
+   - Modified code → check consistency, regression risk
+   - Deleted code → check for orphaned references
+3. Run improvement checks (see checklist below)
+4. Generate improvement report
+5. User approves → create follow-up commit(s)
+```
+
+## Improvement Checklist
+
+| Category | Checks |
+|----------|--------|
+| **Code Quality** | Naming consistency, dead code, duplication, complexity |
+| **Type Safety** | Missing types, `any` usage, assertion safety |
+| **Error Handling** | Unhandled promises, missing try-catch, error propagation |
+| **Testing** | Missing test coverage for new functions, edge cases |
+| **Documentation** | Missing JSDoc for public APIs, outdated README refs |
+| **Security** | Hardcoded values, injection risks, permission checks |
+| **Performance** | Unnecessary re-renders, N+1 queries, missing indexes |
+
+## Report Format
+
+```
+[PR Auto-Improve] PR #{number} — {title}
+├── Files analyzed: {count}
+├── Improvements found: {count}
+│
+├── [Code Quality] ({count} items)
+│   ├── {file:line} — {description}
+│   └── {file:line} — {description}
+│
+├── [Testing] ({count} items)
+│   └── {file} — Missing test for {function}
+│
+├── [Documentation] ({count} items)
+│   └── {file:line} — {description}
+│
+└── Estimated effort: {low|medium|high}
+
+Apply improvements? [Y/n/select]
+```
+
+## Improvement Modes
+
+| Mode | Behavior |
+|------|----------|
+| `all` | Apply all suggested improvements |
+| `select` | User picks which improvements to apply |
+| `report` | Report only, no changes (default) |
+
+## Implementation Flow
+
+```
+User: "improve PR #215"
+  → Orchestrator activates pr-auto-improve
+  → Fetch PR diff via mgr-gitnerd
+  → Analyze with appropriate expert agent(s)
+  → Generate report
+  → User selects improvements
+  → Delegate fixes to specialist agents (R010)
+  → mgr-gitnerd creates follow-up commit
+```
+
+## Agent Selection for Fixes
+
+| File Type | Agent |
+|-----------|-------|
+| *.ts, *.tsx | lang-typescript-expert |
+| *.py | lang-python-expert |
+| *.go | lang-golang-expert |
+| *.kt | lang-kotlin-expert |
+| *.java | lang-java21-expert |
+| *.rs | lang-rust-expert |
+| Test files | qa-engineer |
+| Docs, README | arch-documenter |
+| Mixed | Multiple agents in parallel (R009) |
+
+## Integration
+
+| Rule | Integration |
+|------|-------------|
+| R009 | Multiple file fixes execute in parallel |
+| R010 | Orchestrator coordinates analysis and fix delegation |
+| R015 | Full transparency on what improvements are suggested and why |
+| R018 | 3+ fix agents → Agent Teams for coordination |
+| worker-reviewer-pipeline | Can chain: auto-improve → worker-reviewer for critical fixes |
+| pipeline-guards | Improvement count capped by guard limits |
+
+## Opt-In Safeguards
+
+- **NEVER** auto-activates on PR creation
+- **NEVER** pushes changes without user approval
+- **NEVER** modifies PR description or labels without approval
+- Report mode is default; changes require explicit "apply" command
+- All git operations go through mgr-gitnerd (R010)
+
+## Limitations
+
+- Analyzes only the PR diff, not the entire codebase
+- Cannot detect architectural issues (use dev-review for that)
+- Max 50 files per analysis (skip larger PRs with warning)
+- Does not run tests (delegates to qa-engineer if needed)

package/templates/.claude/skills/task-decomposition/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: task-decomposition
+description: Auto-decompose large tasks into DAG-compatible parallel subtasks
+---
+
+# Task Decomposition Skill
+
+Analyzes task complexity and decomposes large tasks into smaller, parallelizable subtasks compatible with the DAG orchestration skill. The orchestrator uses this as a planning frontend before execution.
+
+## Trigger Conditions
+
+Decomposition is **recommended** when any of these thresholds are met:
+
+| Trigger | Threshold | Rationale |
+|---------|-----------|-----------|
+| Estimated duration | > 30 minutes | Too long for single agent |
+| Files affected | > 3 files | Parallelizable across files |
+| Domains involved | > 2 domains | Requires multiple specialists |
+| Agent types needed | > 2 types | Cross-specialty coordination |
+
+## Decomposition Process
+
+```
+1. Analyze task scope
+   ├── Estimate duration, file count, domains
+   ├── Identify required agent types
+   └── Check trigger thresholds
+
+2. If thresholds met → decompose:
+   ├── Break into atomic subtasks (single agent, single concern)
+   ├── Identify dependencies between subtasks
+   ├── Map subtasks to agents (use routing skills)
+   └── Generate DAG workflow spec
+
+3. Present plan to user (R015 transparency)
+   ├── Show decomposed subtasks with agents
+   ├── Show dependency graph
+   ├── Show estimated parallel execution time
+   └── Request confirmation before execution
+
+4. Execute via dag-orchestration skill
+```
+
+## Decomposition Heuristics
+
+### By File Independence
+```
+Task: "Update auth module across 5 files"
+  ├── auth.ts → lang-typescript-expert
+  ├── middleware.ts → lang-typescript-expert
+  ├── config.ts → lang-typescript-expert (independent)
+  ├── auth.test.ts → qa-engineer (depends: auth.ts)
+  └── README.md → arch-documenter (depends: all above)
+
+DAG: [auth.ts, middleware.ts, config.ts] → auth.test.ts → README.md
+```
+
+### By Domain Separation
+```
+Task: "Add user profile feature with API and UI"
+  ├── API endpoint → be-express-expert
+  ├── Database schema → db-postgres-expert
+  ├── Frontend component → fe-vercel-agent
+  └── Integration test → qa-engineer
+
+DAG: [API, DB] → Frontend → Integration test
+     (API and DB are independent, Frontend needs both)
+```
+
+### By Layer
+```
+Task: "Implement order processing in Spring Boot"
+  ├── Domain model → lang-kotlin-expert
+  ├── Repository → be-springboot-expert (depends: domain)
+  ├── Service → be-springboot-expert (depends: domain, repository)
+  ├── Controller → be-springboot-expert (depends: service)
+  └── Tests → qa-engineer (depends: all)
+
+DAG: domain → [repository] → service → controller → tests
+```
+
+## Output Format
+
+### Decomposition Plan
+```
+[Task Decomposition]
+├── Original: "Add user authentication with JWT"
+├── Complexity: High (4 files, 3 domains, ~45 min)
+├── Decomposed into 5 subtasks:
+│
+│   [1] analyze (Explore:haiku)
+│       Scan codebase for existing auth patterns
+│
+│   [2] implement-auth (lang-typescript-expert:sonnet)
+│       Implement JWT signing and validation
+│       Depends: [1]
+│
+│   [3] implement-middleware (lang-typescript-expert:sonnet)
+│       Create auth middleware
+│       Depends: [1]
+│
+│   [4] write-tests (qa-engineer:sonnet)
+│       Write auth tests
+│       Depends: [2, 3]
+│
+│   [5] commit (mgr-gitnerd:sonnet)
+│       Commit all changes
+│       Depends: [4]
+│
+├── Parallel layers: 3 (max 2 concurrent in layer 2)
+├── Estimated time: ~20 min (vs ~45 min sequential)
+└── Proceed? [Y/n]
+```
+
+### Generated DAG Spec
+```yaml
+workflow:
+  name: auto-decomposed-auth
+  description: "Auto-decomposed: Add user authentication with JWT"
+
+nodes:
+  - id: analyze
+    agent: Explore
+    model: haiku
+    prompt: "Scan codebase for existing auth patterns"
+  - id: implement-auth
+    agent: lang-typescript-expert
+    model: sonnet
+    prompt: "Implement JWT signing and validation"
+    depends_on: [analyze]
+  - id: implement-middleware
+    agent: lang-typescript-expert
+    model: sonnet
+    prompt: "Create auth middleware"
+    depends_on: [analyze]
+  - id: write-tests
+    agent: qa-engineer
+    model: sonnet
+    prompt: "Write auth tests"
+    depends_on: [implement-auth, implement-middleware]
+  - id: commit
+    agent: mgr-gitnerd
+    model: sonnet
+    prompt: "Commit all changes"
+    depends_on: [write-tests]
+
+config:
+  max_parallel: 4
+  failure_strategy: stop
+```
+
+## Atomic Task Criteria
+
+A subtask is **atomic** when it meets ALL of:
+- Single agent can handle it
+- Single concern (one logical change)
+- Independently testable outcome
+- < 15 minutes estimated duration
+- < 3 files affected
+
+If a subtask is not atomic → decompose further (max 2 levels deep).
+
+## Skip Decomposition When
+
+| Condition | Reason |
+|-----------|--------|
+| Single file edit | Already atomic |
+| < 10 minutes estimated | Overhead not worth it |
+| User explicitly requests "just do it" | User override |
+| Single domain, single agent | No parallelization benefit |
+
+## Integration
+
+| Component | Integration |
+|-----------|-------------|
+| dag-orchestration | Generates DAG specs consumed by dag-orchestration |
+| Routing skills | Uses dev-lead/de-lead/qa-lead routing for agent mapping |
+| R009 | Maximizes parallelization within max-4 limit |
+| R010 | Decomposition happens in orchestrator only |
+| R015 | Plan displayed before execution for user approval |
+| R018 | 3+ agents in plan → check Agent Teams eligibility |

package/templates/.claude/skills/worker-reviewer-pipeline/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: worker-reviewer-pipeline
+description: Worker-Reviewer iterative pipeline for quality-critical code with review cycles
+---
+
+# Worker-Reviewer Pipeline Skill
+
+Defines an iterative Worker→Reviewer pipeline where one agent implements changes and another reviews them. The cycle repeats until quality criteria are met or max iterations reached.
+
+**Orchestrator-only** — only the main conversation activates this pipeline (R010). Worker and Reviewer are subagents.
+
+## When to Activate
+
+| Condition | Activate? |
+|-----------|-----------|
+| Quality-critical code changes (auth, security, payments) | Yes |
+| Complex refactoring touching 5+ files | Yes |
+| User explicitly requests review cycle | Yes |
+| Simple file edits, config changes | No |
+| Documentation-only changes | No |
+
+## Pipeline Spec Format
+
+```yaml
+pipeline:
+  name: feature-review
+  description: Implement and review a feature
+
+worker:
+  agent: lang-typescript-expert    # or appropriate specialist
+  model: sonnet
+  prompt: "Implement the feature based on requirements"
+
+reviewer:
+  agent: lang-typescript-expert    # can be same or different specialist
+  model: opus                      # often higher model for review
+  prompt: "Review implementation for correctness, security, performance"
+
+config:
+  max_iterations: 3          # Max review cycles (default: 3)
+  quality_gate: all_pass     # all_pass | majority_pass | custom
+  auto_commit: false         # Auto-commit on quality pass (via mgr-gitnerd)
+```
+
+## Execution Flow
+
+```
+1. Orchestrator activates pipeline
+2. Worker agent implements changes
+3. Reviewer agent reviews Worker's output
+4. Reviewer produces verdict:
+   - PASS → Pipeline complete, proceed to next step
+   - FAIL(issues) → Worker receives feedback, re-implements
+5. Repeat 3-4 until PASS or max_iterations reached
+6. If max_iterations reached without PASS:
+   - Report partial results to user
+   - Recommend manual review
+```
+
+## Review Verdict Format
+
+Reviewer MUST output a structured verdict:
+
+```
+[Review Verdict]
+├── Status: PASS | FAIL
+├── Iteration: {n}/{max}
+├── Issues Found: {count}
+│   ├── [Critical] {description} — {file:line}
+│   ├── [Major] {description} — {file:line}
+│   └── [Minor] {description} — {file:line}
+└── Summary: {one-line}
+```
+
+## Quality Gates
+
+| Gate | Criteria |
+|------|----------|
+| `all_pass` | Zero Critical or Major issues (default) |
+| `majority_pass` | Zero Critical, ≤2 Minor issues allowed |
+| `custom` | User-defined in pipeline spec |
+
+## Integration with Agent Teams (R018)
+
+When Agent Teams is enabled, the pipeline SHOULD use Agent Teams:
+
+```
+TeamCreate("review-pipeline")
+  Worker (team member) ←→ Reviewer (team member)
+  SendMessage for feedback exchange
+  Shared TaskList for tracking issues
+```
+
+When Agent Teams is NOT available, falls back to sequential Task tool calls:
+```
+Task(worker) → result → Task(reviewer) → verdict → Task(worker) → ...
+```
+
+## Display Format
+
+```
+[Pipeline] feature-review — Worker: lang-typescript-expert, Reviewer: lang-typescript-expert
+[Iteration 1/3] Worker implementing...
+[Iteration 1/3] Reviewer reviewing...
+[Review] FAIL — 2 issues (1 Major, 1 Minor)
+[Iteration 2/3] Worker fixing issues...
+[Iteration 2/3] Reviewer re-reviewing...
+[Review] PASS — 0 issues
+[Pipeline Complete] 2 iterations, quality gate passed
+```
+
+## Common Pipeline Templates
+
+### Security-Critical Feature
+```yaml
+worker: {agent: lang-typescript-expert, model: sonnet}
+reviewer: {agent: lang-typescript-expert, model: opus}
+config: {max_iterations: 3, quality_gate: all_pass}
+```
+
+### Cross-Language Integration
+```yaml
+worker: {agent: lang-golang-expert, model: sonnet}
+reviewer: {agent: be-go-backend-expert, model: opus}
+config: {max_iterations: 2, quality_gate: all_pass}
+```
+
+### Quick Review
+```yaml
+worker: {agent: lang-python-expert, model: sonnet}
+reviewer: {agent: lang-python-expert, model: sonnet}
+config: {max_iterations: 1, quality_gate: majority_pass}
+```
+
+## Integration
+
+| Rule | Integration |
+|------|-------------|
+| R009 | Worker and Reviewer can run in parallel with other pipelines |
+| R010 | Pipeline orchestration runs only in main conversation |
+| R015 | Display pipeline plan and review verdicts transparently |
+| R018 | Agent Teams preferred when available for Worker↔Reviewer messaging |
+| pipeline-guards | Max iterations and timeout enforced by pipeline-guards |
+| model-escalation | Worker failures feed into escalation tracking |
+| stuck-recovery | Repeated FAIL verdicts trigger stuck detection advisory |
+
+## Limitations
+
+- Max 3 iterations by default (configurable, hard cap at 5 via pipeline-guards)
+- Worker and Reviewer must be different agent instances (same type allowed)
+- Nested pipelines not supported (use dag-orchestration for complex flows)
+- Pipeline does not auto-commit; orchestrator decides post-pipeline actions

package/templates/manifest.json

@@ -18,7 +18,7 @@
       "name": "skills",
       "path": ".claude/skills",
       "description": "Reusable skill modules (includes slash commands)",
-      "files": 58
+      "files": 63
     },
     {
       "name": "guides",