claude-code-pilot 3.2.0 → 3.3.1

package/src/skills/mysql-patterns/SKILL.md

@@ -0,0 +1,412 @@
+---
+name: mysql-patterns
+description: MySQL and MariaDB schema, query, indexing, transaction, replication, and connection-pool patterns for production backends.
+origin: ECC
+---
+
+# MySQL Patterns
+
+Use this skill when working on MySQL or MariaDB schema design, migrations,
+slow-query investigation, queue-style transactions, connection pools, or
+production database configuration. Prefer exact version checks before applying a
+feature-specific pattern because MySQL and MariaDB have diverged in several SQL
+details.
+
+## Activation
+
+- Designing MySQL or MariaDB tables, indexes, and constraints
+- Reviewing migrations before they run on large production tables
+- Debugging slow queries, lock waits, deadlocks, or connection exhaustion
+- Adding keyset pagination, upserts, full-text search, JSON columns, or queues
+- Configuring application connection pools, read replicas, TLS, or slow logs
+
+## Version Check
+
+Start by identifying the engine and version:
+
+```sql
+SELECT VERSION();
+SHOW VARIABLES LIKE 'version_comment';
+```
+
+Keep MySQL and MariaDB guidance separate when syntax differs:
+
+- MySQL documents row aliases as the replacement for `VALUES(col)` in
+  `ON DUPLICATE KEY UPDATE`; `VALUES(col)` is deprecated there.
+- MariaDB documents `VALUES(col)` as the supported way to reference inserted
+  values in `ON DUPLICATE KEY UPDATE`; use it for cross-engine compatibility.
+- `SKIP LOCKED` is appropriate for queue-like work only. It skips locked rows
+  and can return an inconsistent view, so do not use it for general accounting
+  or integrity-sensitive reads.
+
+## Schema Defaults
+
+```sql
+CREATE TABLE orders (
+    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
+    account_id BIGINT UNSIGNED NOT NULL,
+    status VARCHAR(32) NOT NULL,
+    total DECIMAL(15, 2) NOT NULL,
+    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
+    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
+    deleted_at DATETIME NULL,
+    PRIMARY KEY (id),
+    KEY idx_orders_account_status_created (account_id, status, created_at),
+    KEY idx_orders_active (account_id, deleted_at)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
+```
+
+Default choices:
+
+| Use Case | Prefer | Avoid |
+| --- | --- | --- |
+| Surrogate primary keys | `BIGINT UNSIGNED AUTO_INCREMENT` | `INT` for tables that can grow beyond 2B rows |
+| UUID lookup keys | `BINARY(16)` with conversion helpers | `VARCHAR(36)` primary keys on hot tables |
+| Money and exact quantities | `DECIMAL(p, s)` | `FLOAT` or `DOUBLE` |
+| User-facing text | `utf8mb4` tables and indexes | MySQL `utf8` / `utf8mb3` defaults |
+| Application timestamps | `DATETIME` with UTC managed by the app | Assuming `DATETIME` stores time zone metadata |
+| Soft deletes | `deleted_at DATETIME NULL` plus scoped indexes | Filtering soft-deleted rows without an index |
+| Extensible status values | lookup table or constrained `VARCHAR` | `ENUM` when values change often |
+
+## Indexing
+
+Composite index order usually follows equality predicates first, then range or
+sort columns:
+
+```sql
+CREATE INDEX idx_orders_account_status_created
+    ON orders (account_id, status, created_at);
+
+SELECT id, total
+FROM orders
+WHERE account_id = ?
+  AND status = 'pending'
+  AND created_at >= ?
+ORDER BY created_at DESC
+LIMIT 50;
+```
+
+Use `EXPLAIN` before adding or changing an index:
+
+```sql
+EXPLAIN
+SELECT id, total
+FROM orders
+WHERE account_id = 123 AND status = 'pending'
+ORDER BY created_at DESC
+LIMIT 50;
+```
+
+Signals to investigate:
+
+| Field | Risk Signal |
+| --- | --- |
+| `type` | `ALL` on a large table |
+| `key` | `NULL` when a selective predicate exists |
+| `rows` | Very high row estimate for an interactive path |
+| `Extra` | `Using temporary`, `Using filesort`, or broad `Using where` |
+
+Avoid adding indexes blindly. Each index increases write cost, migration time,
+backup size, and buffer-pool pressure.
+
+## Query Patterns
+
+### Upsert
+
+Cross-engine-compatible form:
+
+```sql
+INSERT INTO user_settings (user_id, setting_key, setting_value)
+VALUES (?, ?, ?)
+ON DUPLICATE KEY UPDATE
+    setting_value = VALUES(setting_value),
+    updated_at = CURRENT_TIMESTAMP;
+```
+
+MySQL row-alias form:
+
+```sql
+INSERT INTO user_settings (user_id, setting_key, setting_value)
+VALUES (?, ?, ?) AS new
+ON DUPLICATE KEY UPDATE
+    setting_value = new.setting_value,
+    updated_at = CURRENT_TIMESTAMP;
+```
+
+Use the row-alias form only after confirming the target is MySQL. Use
+`VALUES(col)` for MariaDB or mixed MySQL/MariaDB fleets.
+
+### Keyset Pagination
+
+```sql
+SELECT id, name, created_at
+FROM products
+WHERE (created_at, id) < (?, ?)
+ORDER BY created_at DESC, id DESC
+LIMIT 50;
+```
+
+Back it with an index that matches the cursor:
+
+```sql
+CREATE INDEX idx_products_created_id ON products (created_at, id);
+```
+
+Do not use deep `OFFSET` pagination on large tables; it makes the server scan
+and discard rows before returning the page.
+
+### JSON Fields
+
+Use JSON columns for extension data, not for fields that need heavy relational
+filtering or constraints.
+
+```sql
+CREATE TABLE events (
+    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
+    payload JSON NOT NULL,
+    event_type VARCHAR(64)
+        GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(payload, '$.type'))) STORED,
+    KEY idx_events_type (event_type)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+```
+
+For frequently queried JSON paths, expose a generated column and index that
+column. Keep foreign keys, ownership, tenancy, and lifecycle fields relational.
+
+### Full-Text Search
+
+```sql
+ALTER TABLE articles ADD FULLTEXT KEY ft_articles_title_body (title, body);
+
+SELECT id, title, MATCH(title, body) AGAINST (? IN NATURAL LANGUAGE MODE) AS score
+FROM articles
+WHERE MATCH(title, body) AGAINST (? IN NATURAL LANGUAGE MODE)
+ORDER BY score DESC
+LIMIT 20;
+```
+
+Use external search when you need typo tolerance, complex ranking, cross-table
+facets, or language-specific analysis beyond built-in full-text behavior.
+
+## Transactions
+
+Keep transactions short and lock rows in a consistent order:
+
+```sql
+START TRANSACTION;
+
+SELECT id, balance
+FROM accounts
+WHERE id IN (?, ?)
+ORDER BY id
+FOR UPDATE;
+
+UPDATE accounts SET balance = balance - ? WHERE id = ?;
+UPDATE accounts SET balance = balance + ? WHERE id = ?;
+
+COMMIT;
+```
+
+Deadlock and lock-wait checklist:
+
+- Lock rows in a deterministic order across code paths.
+- Do external API calls before opening the transaction, not inside it.
+- Add indexes for predicates used in `UPDATE`, `DELETE`, and locking reads.
+- On deadlock, roll back and retry the whole transaction with a bounded retry
+  budget.
+- Capture `SHOW ENGINE INNODB STATUS\G` soon after a deadlock; it is overwritten
+  by later events.
+
+Queue-style worker claim:
+
+```sql
+START TRANSACTION;
+
+SELECT id
+FROM jobs
+WHERE status = 'pending'
+ORDER BY created_at
+LIMIT 1
+FOR UPDATE SKIP LOCKED;
+
+UPDATE jobs
+SET status = 'processing', started_at = CURRENT_TIMESTAMP
+WHERE id = ?;
+
+COMMIT;
+```
+
+Use `SKIP LOCKED` only for queue-like workloads where skipping a locked row is
+acceptable. It is not a replacement for normal transactional consistency.
+
+## Connection Pools
+
+SQLAlchemy example:
+
+```python
+from sqlalchemy import create_engine
+
+engine = create_engine(
+    "mysql+mysqlconnector://app:secret@db.internal/app",
+    pool_size=10,
+    max_overflow=5,
+    pool_timeout=30,
+    pool_recycle=240,
+    pool_pre_ping=True,
+    connect_args={"connect_timeout": 5},
+)
+```
+
+Node.js `mysql2` example:
+
+```javascript
+import mysql from 'mysql2/promise';
+
+const pool = mysql.createPool({
+  host: process.env.DB_HOST,
+  user: process.env.DB_USER,
+  password: process.env.DB_PASSWORD,
+  database: process.env.DB_NAME,
+  waitForConnections: true,
+  connectionLimit: 10,
+  queueLimit: 0,
+  enableKeepAlive: true,
+  keepAliveInitialDelay: 30000,
+});
+
+const [rows] = await pool.execute(
+  'SELECT id, total FROM orders WHERE account_id = ? LIMIT 50',
+  [accountId],
+);
+```
+
+Keep application pool recycling below the server `wait_timeout`. If the server
+uses `wait_timeout = 300`, a `pool_recycle` around 240 seconds is coherent;
+`pool_pre_ping` still helps recover from network and failover events.
+
+## Diagnostics
+
+Useful first-pass commands:
+
+```sql
+SHOW FULL PROCESSLIST;
+SHOW ENGINE INNODB STATUS\G;
+SHOW VARIABLES LIKE 'slow_query_log';
+SHOW VARIABLES LIKE 'long_query_time';
+```
+
+Enable the slow log in a controlled environment:
+
+```sql
+SET GLOBAL slow_query_log = 'ON';
+SET GLOBAL long_query_time = 1;
+SET GLOBAL log_queries_not_using_indexes = 'ON';
+```
+
+Use `EXPLAIN ANALYZE` only when it is safe to execute the query. It runs the
+statement and can be expensive on production-sized data.
+
+## Replication
+
+Read replicas can lag. Do not route read-your-own-write paths, checkout flows,
+permission checks, or idempotency-key reads to a replica immediately after a
+write.
+
+```sql
+-- MySQL legacy terminology, still common in existing fleets
+SHOW SLAVE STATUS\G;
+
+-- Newer terminology where supported
+SHOW REPLICA STATUS\G;
+```
+
+Check the engine/version before standardizing on one command. Monitor replica
+SQL thread health, IO thread health, and lag, not just whether the TCP
+connection is alive.
+
+## Security
+
+```sql
+CREATE USER 'app'@'%' IDENTIFIED BY 'use-a-secret-manager';
+GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'app'@'%';
+
+ALTER USER 'app'@'%' REQUIRE SSL;
+
+SELECT user, host
+FROM mysql.user
+WHERE user = '';
+
+DROP USER IF EXISTS ''@'localhost';
+DROP USER IF EXISTS ''@'%';
+```
+
+Security review points:
+
+- Do not grant `ALL PRIVILEGES` or `*.*` to application users.
+- Require TLS for application users when traffic crosses hosts or networks.
+- Store credentials in the platform secret manager, not in examples, scripts, or
+  repository files.
+- Separate migration/admin users from runtime application users.
+- Audit public network exposure and bind addresses before tuning performance.
+
+## Configuration
+
+Example starting point for a dedicated database host:
+
+```ini
+[mysqld]
+innodb_buffer_pool_size = 4G
+innodb_flush_log_at_trx_commit = 1
+sync_binlog = 1
+
+max_connections = 300
+thread_cache_size = 50
+
+wait_timeout = 300
+interactive_timeout = 300
+innodb_lock_wait_timeout = 10
+
+slow_query_log = ON
+long_query_time = 1
+log_queries_not_using_indexes = ON
+
+log_bin = mysql-bin
+binlog_format = ROW
+binlog_expire_logs_seconds = 604800
+```
+
+Treat configuration values as a prompt for review, not a universal preset. Size
+memory, connections, log retention, and durability settings from workload,
+hardware, backup policy, and recovery objectives.
+
+## Anti-Patterns
+
+| Anti-Pattern | Risk | Better Pattern |
+| --- | --- | --- |
+| `SELECT *` in hot paths | Over-fetching and brittle clients | Select explicit columns |
+| Deep `OFFSET` pagination | Linear scans and slow pages | Keyset pagination |
+| No index on foreign-key joins | Slow joins and lock-heavy deletes | Index FK columns intentionally |
+| Long transactions | Lock waits and large undo history | Commit small units of work |
+| Direct DML against `mysql.user` | Grant-table corruption risk | Use `CREATE USER`, `ALTER USER`, `DROP USER` |
+| Application user with admin grants | High blast radius | Least-privilege runtime user |
+| Pool recycle above `wait_timeout` | Stale pooled connections | Recycle below timeout and pre-ping |
+| Replica reads after writes | Stale user-facing state | Pin read-after-write flows to primary |
+
+## Output Expectations
+
+When this skill is used for review, return:
+
+1. Engine/version assumptions.
+2. Highest-risk correctness, lock, security, and migration issues.
+3. Exact SQL or code changes for the safe path.
+4. Validation plan: `EXPLAIN`, migration dry run, lock/deadlock check, and
+   rollback criteria.
+5. Any MySQL/MariaDB syntax differences that affect the recommendation.
+
+## Related
+
+- Skill: `postgres-patterns` - PostgreSQL-specific schema and query patterns
+- Skill: `database-migrations` - migration planning and rollout safety
+- Skill: `backend-patterns` - API and service-layer patterns
+- Skill: `security-review` - secret handling, auth, and least privilege
+- Agent: `database-reviewer` - broader database review workflow

package/src/skills/plan-orchestrate/SKILL.md

@@ -0,0 +1,220 @@
+---
+name: plan-orchestrate
+description: Read a plan document, decompose it into steps, design a per-step agent chain from the CCP catalogue, and emit ready-to-paste /orchestrate custom prompts. Generative only — never invokes /orchestrate itself. Use when the user has a multi-step plan and wants to drive it through orchestrate without composing chains by hand.
+origin: ECC
+---
+
+# Plan Orchestrate
+
+Bridge a plan document to `/orchestrate custom` by emitting one ready-to-paste invocation per step. The skill is generative only — it never executes `/orchestrate`. The user pastes each line when ready.
+
+## When to Activate
+
+- User has a multi-step plan document (PRD, RFC, implementation plan) and wants to drive it through `/orchestrate`.
+- User says "orchestrate this plan", "give me orchestrate prompts for each step", "compose chains for this plan".
+- A step-by-step plan exists but the user does not want to manually pick agents per step.
+
+Skip when:
+- The work is one ad-hoc step → call `/orchestrate custom` directly.
+- The plan is unreadable or empty. Lack of explicit numbering alone is not a skip condition — see the "No clear steps" edge case below.
+
+## Inputs
+
+```
+<plan-doc-path> [--lang=python|typescript|go|rust|cpp|java|kotlin|flutter|auto] [--scope=all|step:<n>|range:<a>-<b>] [--dry-run]
+```
+
+- `<plan-doc-path>` — required; relative or absolute path (`@docs/...` accepted).
+- `--lang` — reviewer language variant; defaults to `auto` (detected from project).
+- `--scope` — limits emitted steps; defaults to `all`.
+- `--dry-run` — print decomposition + chain rationale only; do not emit final prompts.
+
+## Authoritative `/orchestrate` shape (do not deviate)
+
+```
+/orchestrate custom "<agent1>,<agent2>,...,<agentN>" "<task description>"
+```
+
+- `custom` is a sequential chain; each agent's HANDOFF feeds the next.
+- Comma-separated agent list. No spaces preferred; one space tolerated.
+- No `--mode` / `--gate` / `--agents=...` flags exist — never invent them.
+- Agent names come from the catalogue in this skill. Embedded double quotes in the task description are escaped as `\"`.
+- Agent names are bare (`<name>`), matching how CCP installs them into `<claude-home>/agents/`.
+
+## Available agent catalogue (must pick from these)
+
+General:
+- `planner` — requirement restatement, risk decomposition, step planning
+- `architect` — architecture, system design, refactor proposals
+- `tdd-guide` — write tests → implement → 80%+ coverage
+- `code-reviewer` — generic code review
+- `security-reviewer` — security audit, OWASP, secret leakage
+- `refactor-cleaner` — dead code, duplicates, knip-class cleanup
+- `doc-updater` — documentation, codemap, README
+- `docs-lookup` — third-party library API lookups (Context7)
+- `e2e-runner` — end-to-end test orchestration
+- `database-reviewer` — PostgreSQL schema, migration, performance
+- `harness-optimizer` — local agent harness configuration
+- `loop-operator` — long-running autonomous loops
+- `chief-of-staff` — multi-channel triage (rarely a fit for plan steps)
+
+Build error resolvers:
+- `build-error-resolver` (generic) / `cpp-build-resolver` / `go-build-resolver` / `java-build-resolver` / `kotlin-build-resolver` / `rust-build-resolver` / `pytorch-build-resolver`
+
+Code reviewers:
+- `python-reviewer` / `typescript-reviewer` / `go-reviewer` / `rust-reviewer` / `cpp-reviewer` / `java-reviewer` / `kotlin-reviewer` / `flutter-reviewer`
+
+A misspelled agent name fails `/orchestrate`. Cross-check against this list before emitting.
+
+## How It Works
+
+### Phase 0 — Detect language
+
+1. Read `<plan-doc-path>`. If missing or empty, report and stop.
+2. Resolve `--lang`. When `auto`, run a polyglot-aware detection:
+   - Probe markers: `pyproject.toml` / `uv.lock` / `requirements.txt` → python; `package.json` → typescript; `go.mod` → go; `Cargo.toml` → rust; `CMakeLists.txt` or top-level `*.cpp` → cpp; `pom.xml` / `build.gradle` (Java) → java; `build.gradle.kts` or top-level Kotlin → kotlin; `pubspec.yaml` → flutter.
+   - **Polyglot tie-break**: if more than one marker matches, pick the language whose source files outnumber the others (count via `git ls-files`, excluding `vendor/`, `node_modules/`, `dist/`, `build/`, `.venv/`, generated files, and obvious test fixtures). On a tie or when no language exceeds 60% of source files, set `lang=unknown`.
+   - No marker matched → set `lang=unknown`.
+   - `lang=unknown` is a sentinel — it is **not** an agent name. Phase 2 rules 4 and 5 turn it into `code-reviewer` / `build-error-resolver` at chain composition time.
+4. Detect a **PyTorch sub-profile**: when `lang=python` and any of `pyproject.toml` / `requirements.txt` / `uv.lock` declares a dependency on `torch`, set `pytorch=true`. This only affects `build` chain selection (Phase 2 rule below); the reviewer remains `python-reviewer`.
+5. **Normalize any agent names declared in the plan**: if the plan text references agents by a plugin-prefixed form (e.g. `<namespace>:tdd-guide`), strip the prefix to get the bare catalogue name before validating or composing chains. CCP emits bare names only; never let a pre-prefixed name flow into the output.
+
+### Phase 1 — Decompose steps
+
+Identify "step units" in priority order:
+
+1. Explicit numbering: `## Step N` / `### Phase N` / `## N. ...` / top-level ordered list.
+2. A "Step" column in a table.
+3. `---`-separated blocks with verb-led headings.
+4. Otherwise treat each H2 as one step.
+
+Per step extract `id` (1-based), `title` (≤ 80 chars), `intent` (1–3 sentences), `tags`.
+
+### Phase 2 — Tag and pick chain
+
+Tag by intent (multi-tag allowed; chain built from primary + stacked secondaries):
+
+Trigger words below are matched case-insensitively. Multilingual plans are supported by matching the word stems in any language as long as the meaning aligns with the listed English trigger words.
+
+| Tag | Trigger words | Default chain |
+|---|---|---|
+| `design` | architecture, design, choose, evaluate, RFC | `planner,architect` |
+| `plan` | plan, breakdown, milestone | `planner` |
+| `impl` | implement, build, add, create, port | `tdd-guide,<lang>-reviewer` |
+| `test` | test, coverage, e2e, integration | `tdd-guide,e2e-runner` |
+| `refactor` | refactor, cleanup, dedupe, split | `architect,refactor-cleaner,<lang>-reviewer` |
+| `migration` | migrate, upgrade, rewrite, port | `architect,tdd-guide,<lang>-reviewer` |
+| `db` | schema, migration, index, SQL, Postgres, alembic, sqlmodel | `database-reviewer,<lang>-reviewer` |
+| `security` | encrypt, auth, secret, OWASP, PII | `security-reviewer,<lang>-reviewer` |
+| `build` | build, compile, lint failure, CI | `<lang>-build-resolver` (falls back to `build-error-resolver`) |
+| `docs` | docs, readme, codemap, changelog | `doc-updater` |
+| `lookup` | lookup, reference, API usage | `docs-lookup` |
+| `review` | review, audit, verify | `<lang>-reviewer,code-reviewer` |
+| `loop` | loop, autonomous, watchdog | `loop-operator` |
+
+Chain composition rules:
+1. **Primary tag selection**: when a step matches multiple tags, the **first one in table order** (top of the table = highest priority) is the primary; the rest are secondaries. Composition rules 2 and 3 below handle specific multi-tag combinations explicitly; otherwise, append secondary chains in tag table order.
+2. `impl` + `security` → `tdd-guide,<lang>-reviewer,security-reviewer`.
+3. `impl` + `db` → `tdd-guide,database-reviewer,<lang>-reviewer`.
+4. **Deduplicate** the resulting chain (preserve first occurrence). E.g. `review` + `lang=unknown` would yield `code-reviewer,code-reviewer` after rule 5; deduplication collapses it to `code-reviewer`.
+5. `<lang>-reviewer` resolves to `code-reviewer` when `lang=unknown`.
+6. `<lang>-build-resolver` resolves to `build-error-resolver` when `lang=unknown`. **Special case**: if Phase 0 set `pytorch=true`, use `pytorch-build-resolver` for `build` chains regardless of `<lang>`. There is no `python-build-resolver`; `--lang=python` without `pytorch=true` resolves to `build-error-resolver`.
+7. **Zero-tag steps**: if no trigger word matches, set chain to `code-reviewer` and write `no tag matched; default review-only chain` under "Chain rationale".
+8. Chain length ≤ 4 after deduplication. If exceeded, drop weakest tag (`lookup` and `docs` first).
+9. Do not pair `planner` and `architect` in an `impl` chain (token waste). Pair them only on `design` steps.
+10. Steps tagged `impl`, `refactor`, or `migration` end with a **reviewer-class** agent — any of `<lang>-reviewer`, `code-reviewer`, `security-reviewer`, or `database-reviewer`. The most domain-specific reviewer wins the tail position (e.g. rule 2's `impl+security` ends with `security-reviewer`; rule 3's `impl+db` ends with `<lang>-reviewer` because `database-reviewer` already gates the migration earlier in the chain). `test` and `build` steps are gated by their own validators (`e2e-runner` and the build resolver respectively) and do not require an additional reviewer.
+
+### Phase 3 — Compress task description
+
+Each emitted `<task description>` must:
+- Be self-contained (the first agent does not need the plan document open).
+- Start with `[Plan: <path>#step-<id>]`.
+- Include 1–3 verifiable Acceptance criteria.
+- Include a Scope guard (`Out of scope: ...`) **only if the plan declares one for this step**. Inherit verbatim. If the plan has no out-of-scope statement, omit the clause entirely — do not invent one.
+- Be 200–600 characters; one line; embedded `"` escaped as `\"`; no literal newlines.
+
+### Phase 4 — Output
+
+Emit Markdown using the bare-name form. The slash command is always `/orchestrate` and every agent name is rendered as a bare catalogue name (no namespace prefix).
+
+Output structure:
+
+````markdown
+# Plan-Orchestrate Result
+
+**Plan**: `<path>`
+**Lang**: `<detected-or-given>`
+**Steps**: <N>
+**Scope**: <all | step:n | range:a-b>
+
+## Steps overview
+
+| # | Title | Tags | Chain |
+|---|---|---|---|
+| 1 | ... | impl, db | `tdd-guide,database-reviewer,python-reviewer` |
+| ... | | | |
+
+---
+
+## Step 1 — <title>
+
+**Intent**: <1–3 sentences>
+**Tags**: <a, b>
+**Chain rationale**: <why this chain; which agent closes the loop>
+
+```bash
+/orchestrate custom "tdd-guide,database-reviewer,python-reviewer" "[Plan: docs/foo.md#step-1] <compressed task description>; Acceptance: <1–3 items>; Out of scope: <…>"
+```
+````
+
+Append a final "Batch execution" block aggregating every step's command in order so the user can paste them all at once. **Skip the Batch block in overview-only mode** (see "Large plan" edge case): when only the overview table is being emitted, there are no per-step commands to aggregate.
+
+### Phase 5 — Self-check (run before emitting)
+
+- [ ] Every agent in every chain comes from the catalogue (after stripping any plugin namespace prefix that appeared in the plan; see Phase 0 step 5).
+- [ ] All emitted agent names are bare (no namespace prefix) and the slash command is `/orchestrate`.
+- [ ] No invented `--mode` / `--gate` / `--agents=...` fields.
+- [ ] Each task description is single-line, double-quoted, with embedded `"` escaped.
+- [ ] Each task description begins with `[Plan: <path>#step-<id>]` and includes Acceptance (1–3 items). The `Out of scope:` clause is present only when inherited from the plan.
+- [ ] No duplicate agent in any chain after Phase 2 dedup.
+- [ ] Chain length ≤ 4.
+- [ ] Steps tagged `impl`/`refactor`/`migration` end with a reviewer-class agent (`<lang>-reviewer`, `code-reviewer`, `security-reviewer`, or `database-reviewer`). `test` and `build` are exempt — see Phase 2 rule 10.
+- [ ] Zero-tag steps emit `code-reviewer` with the rationale `no tag matched; default review-only chain`.
+- [ ] Overview table lists every step in the plan, regardless of `--scope`.
+- [ ] Per-step detail block count matches the resolved `--scope` (full plan when `--scope=all`; one block for `step:n`; range size for `range:a-b`). In overview-only mode, no per-step blocks and no Batch block are emitted.
+
+## Edge cases
+
+- **No clear steps**: prefer H2/H3 splitting; if still ambiguous, report "no structured steps detected" with the document outline and ask the user to confirm running by outline.
+- **Large plan (>1500 lines)**: enter **overview-only mode** — emit only the overview table and ask the user to narrow with `--scope` before re-running for details. In this mode, skip per-step detail blocks and skip the Batch execution block.
+- **Step too broad** (e.g. "complete all backend work"): do not force a single chain. Suggest splitting into N.a and N.b and propose a split.
+- **Plan declares agents** (rare): first **strip any plugin namespace prefix** (e.g. `<namespace>:tdd-guide`) to get the bare catalogue name (Phase 0 step 5), then validate against the catalogue. Replace invalid agents and explain under "Chain rationale".
+- **Polyglot project where `--lang=auto` cannot pick a winner**: set `lang=unknown`; reviewer resolves to `code-reviewer` and build resolver to `build-error-resolver`. Mention the fallback under "Chain rationale".
+
+## Examples
+
+### Example — Python plan
+
+Input:
+```
+plan-orchestrate @docs/plan/example-feature.md --lang=python
+```
+
+Excerpt of expected output:
+````markdown
+## Step 2 — Encrypt sensitive UserProfile fields
+
+**Intent**: Introduce an `EncryptedString` SQLAlchemy type and AES-GCM encrypt `birth_datetime` / `location` before persistence; load the key from an environment variable.
+**Tags**: impl, security, db
+**Chain rationale**: Security-sensitive write path, so `security-reviewer` closes the chain; `database-reviewer` validates the alembic migration; `python-reviewer` covers typing and PEP 8.
+
+```bash
+/orchestrate custom "tdd-guide,database-reviewer,python-reviewer,security-reviewer" "[Plan: docs/plan/example-feature.md#step-2] Implement EncryptedString SQLAlchemy type and migrate UserProfile.birth_datetime/location columns; key from ENV APP_DB_KEY; Acceptance: encrypt/decrypt roundtrip tests pass; alembic upgrade/downgrade clean on empty DB; no plaintext in DB after migrate; Out of scope: cross-tenant profile sharing logic"
+```
+````
+
+## Notes
+
+- Generative only. Never invoke `/orchestrate` from inside this skill.
+- Match the language of the plan document for task descriptions (agent names always remain English).
+- Do not insert "Co-Authored-By" lines or emoji in the output unless the user explicitly asks.