@event4u/agent-config 5.10.1 → 6.1.0

package/.agent-src/skills/song-to-script/SKILL.md

@@ -1,216 +0,0 @@
----
-model_tier: inherit
-name: song-to-script
-description: "Turn an audio track into a timed `## Scene N` script: song sections → per-scene durations, auto mode adds mood + lip-sync lines. Triggers 'music video', 'from the song', 'cut to the beat'."
-personas:
-  - hollywood-director
-domain: product
-workspaces:
-  - small-business
-packs:
-  - ai-video
-lifecycle: experimental
-trust:
-  level: experimental
-install:
-  default: false
-  removable: true
----
-
-# song-to-script
-
-> Turn a song into `<project>/script.md` — a sequence of `## Scene N`
-> blocks whose `duration:` values sum to the track length and whose cut
-> points land on real section boundaries. Consumed by
-> [`/video:from-song`](../../commands/video/from-song.md), then handed
-> to [`scene-expander`](../scene-expander/SKILL.md) and
-> [`video-director`](../video-director/SKILL.md). Never invents timing —
-> every boundary comes from the audio probe, and the probe's `method`
-> tells this skill how musical (or not) those boundaries actually are.
-
-## When to use
-
-- A music-video run needs scenes cut to the song (`/video:from-song`).
-- An existing script must be **re-timed** to a track after the edit
-  drifted from the beat (the named second consumer — re-time without a
-  full re-author).
-
-Do NOT use when:
-
-- The operator already supplies a `## Scene N` script with `duration:`
-  values — feed it straight to `scene-expander`.
-- There is no audio — use the operator brief with `scene-expander`
-  directly.
-
-## Inputs
-
-- **Audio probe** — JSON from
-  [`scripts/ai-video/lib/probe-audio.sh`](../../../../scripts/ai-video/lib/probe-audio.sh):
-  `{duration, method, warning?, sections:[{start,end,energy,label}]}`.
-  - `method: silence` — boundaries are real quiet gaps; trust them as cuts.
-  - `method: rms` — boundaries are energy-delta inflections; usable but
-    coarse.
-  - `method: interval` — **the track is structurally flat** (brick-walled
-    / sustained); sections are fixed-interval, NOT musical. When `method`
-    is `interval` (or `warning` is set), the emitted script header states
-    that timing is interval-based and the operator should pass
-    `--scene-durations` for musical sync. Never present interval cuts as
-    beat-synced.
-- **Mode** — `brief` (operator text is the creative source) or `auto`
-  (infer mood + action from energy).
-- **Brief** (brief mode only) — free text: story, settings, look.
-- **Character lock** (optional) — `<project>/character.json` if a human
-  subject was locked. **Absent is normal** — abstract / landscape /
-  visualiser videos have no locked subject; see Step 2.
-
-## Procedure
-
-### Step 1: Map sections → scenes
-
-One `## Scene N` per probe section. `duration:` = `end - start`
-(rounded to 0.5 s). Merge any section shorter than the provider's
-`min-duration` into its neighbour; split any section longer than the
-provider's `max-duration` into equal sub-scenes so no single clip
-exceeds the backend limit (read both from the resolved provider tuning).
-
-### Step 2: Assign mood + action
-
-First decide the **subject mode**:
-
-- **Character mode** — `character.json` exists: every scene's `action:`
-  names the locked subject, never a fresh description.
-- **Style mode** — no `character.json`: scenes describe setting, palette,
-  and motion continuity (the recurring *look*), not a person. This is the
-  valid abstract / landscape / visualiser path — do not invent a human
-  subject to fill the slot.
-
-Then assign per scene:
-
-- **Brief mode** — distribute the brief's beats across scenes in order;
-  energy only modulates pacing (low energy → slow push-in, high energy →
-  fast cuts / motion). Do not add story the brief did not state.
-- **Auto mode** — derive mood per section from `energy` and `label`:
-
-  | label / energy | default scene intent |
-  |---|---|
-  | intro / low | establishing wide, slow camera, calm subject/scene |
-  | build / rising | approach, tightening framing |
-  | drop / peak | dynamic motion, weather/FX, fast push |
-  | breakdown / dip | close-up / detail, quiet, single light source |
-  | outro / fade | pull-back, resolve, hold |
-
-### Step 3: Vocal map — transcribe, never guess (vocal tracks)
-
-```
-LYRIC TIMING AND SINGER COME FROM THE TRANSCRIBED AUDIO, NEVER FROM A
-BRIEF / STORY SKELETON OR A GUESSED STRETCH. NEVER PUT ONE SINGER'S
-LINE ON ANOTHER SINGER'S SCENE.
-```
-
-Track has vocals and the run intends lip-sync → build a **vocal map**
-from the real audio before assigning any `dialogue:`:
-
-1. **Transcribe** audio to timestamped lines — OpenAI
-   `/v1/audio/transcriptions` (`response_format=verbose_json` →
-   `segments[].{start,end,text}`) or local whisper. Only source of lyric
-   timing.
-2. **Label the singer** per line. Operator who-sings reference (roster, a
-   brief naming who sings which line, or a character cast) → match each
-   line to its singer. Genuinely ambiguous → mark `singer: "?"` and
-   surface; never guess a singer to fill the slot.
-3. **Emit** `<project>/vocal-map.json`: `[{start, end, text, singer}]`,
-   timing verbatim from the transcript.
-4. **Place lines into the matching scene's** `dialogue:` block using
-   transcript timing, tagged with the singer (`singer: "<line>"`). A
-   scene's lip-sync subject MUST be the line's labelled singer.
-
-No vocals / no transcript / no lip-sync intent → leave `dialogue:` empty;
-scene is performance / B-roll. **Never fabricate lyrics**, **never
-re-time a line off the brief**, and in style mode `dialogue:` stays empty
-(lip-sync needs a character subject). The `/video:from-song` sign-off
-gate (its Step 6) shows this map for approval before any render.
-
-### Step 4: Emit + reconcile
-
-Write `<project>/script.md` (and `<project>/vocal-map.json` when the
-track has vocals). Report the delta, the section→scene map, **the probe
-`method`** (silence-derived, energy-derived, or interval-fallback), **and
-whether lyric timing is transcript-derived** (it must be — never
-brief-derived). If the sum cannot be reconciled (e.g. provider
-max-duration forces more time than the song has), **halt and surface the
-conflict** — do not pad silently.
-
-### Step 5: Validate before handoff
-
-Concrete checks (all must pass before the script is handed to
-`scene-expander`):
-
-- **Assert** `Σ(duration) == probe.duration` within ±1.0 s; report the
-  exact delta. A larger delta → halt, do not pad.
-- **Verify** every scene boundary equals a probe section boundary (or a
-  `--scene-durations` value) — no invented cut points.
-- **Confirm** no scene `duration:` exceeds the provider `max-duration`
-  or falls below `min-duration`.
-- **Ensure** every `## Scene N` carries all five keys (`duration` ·
-  `mood` · `action` · `camera` · `dialogue`), and that `dialogue:` is
-  empty in style mode.
-
-## Output format
-
-```markdown
-# <project> — derived from <song-file> (<mode> mode · cuts: <method>)
-
-## Scene 1
-duration: 6.0
-mood: establishing, cold, pre-storm
-action: <subject from character.json, OR style description in style mode>
-camera: slow push-in
-dialogue:
-
-## Scene 2
-duration: 4.5
-mood: build, rising tension
-action: close on <subject / detail>, wind picking up
-camera: handheld tighten
-dialogue:
-  - "<subject>: \"<lyric line for this section, if any>\""
-```
-
-`scene-expander` consumes this verbatim — keep the keys
-(`duration` · `mood` · `action` · `camera` · `dialogue`) exact.
-
-## Gotcha
-
-- **`method: interval` is the brick-walled-master signal, not a bug.**
-  A compressed modern master has near-constant RMS and no silence, so the
-  probe degrades to fixed intervals. That is the honest floor — surface
-  it and point the operator at `--scene-durations`; never dress interval
-  cuts up as beat-synced.
-- **A vocal section without supplied lyrics is B-roll, not lip-sync.**
-  Detected vocal energy alone does not authorise `dialogue:` — only
-  operator-supplied lyrics do.
-- **Style mode is the default for a no-character run**, not an error
-  path. Landscape / abstract / visualiser videos never get a fabricated
-  human subject.
-
-## Do NOT
-
-- **Do NOT invent timing.** Every cut maps to a probe boundary or a
-  `--scene-durations` value — never to taste.
-- **Do NOT present `interval`-fallback cuts as beat-synced.** Always
-  surface the probe `method`.
-- **Do NOT emit a clip outside the provider's min/max duration** —
-  split/merge in Step 1 instead.
-- **Do NOT fabricate lyrics or story** beyond the brief / detected vocals.
-- **Do NOT invent a human subject** in style mode; defer identity to
-  `character.json` only when a lock exists.
-- **Do NOT pad a unreconcilable timing sum** — halt and surface it.
-
-## See also
-
-- [`/video:from-song`](../../commands/video/from-song.md) — the command
-  that drives this skill
-- [`scene-expander`](../scene-expander/SKILL.md) — consumes the emitted
-  script
-- [`character-consistency`](../character-consistency/SKILL.md) — supplies
-  the locked subject referenced in `action:` (character mode only)

package/.agent-src/skills/sql-writing/SKILL.md

@@ -1,79 +0,0 @@
----
-model_tier: medium
-name: sql-writing
-description: "Use when writing raw SQL — MariaDB/MySQL syntax, parameterization, raw migrations, seeders with `DB::statement` — even when the user just pastes a query and asks 'why is this slow' without naming SQL."
-domain: engineering
-workspaces:
-  - engineering
-packs:
-  - engineering-base
----
-
-# sql
-
-## When to use
-
-Use when writing or reviewing raw SQL queries, migrations with raw statements, or seeders with raw SQL.
-
-Do NOT use when:
-- Eloquent/Query Builder queries (use `eloquent` or `database` skill)
-- Schema design (use `database` skill)
-
-## Procedure: Write raw SQL
-
-1. **Inspect call site & choose approach** — identify every dynamic value flowing into the query, then pick: query builder when possible. Raw SQL only when query builder can't express the query.
-2. **Parameterize** — Every variable must use `?` binding or named `:param`. Never interpolate PHP variables into SQL strings.
-3. **Use MariaDB syntax** — Not PostgreSQL or MSSQL. Check `php/sql.md` for MariaDB-specific patterns.
-4. **Verify** — Run EXPLAIN on complex queries. Check that no PHP interpolation (`"$var"`, `'{$var}'`) appears in SQL.
-
-```
-NEVER build SQL strings with PHP variable interpolation or concatenation.
-ALWAYS use parameterized queries or query builder.
-```
-
-## Conventions
-
-→ See guideline `php/sql.md` for parameterization patterns, common mistakes, MariaDB syntax reference.
-
-## Quick reference
-
-```php
-// ✅ Safe
-DB::select('SELECT * FROM users WHERE email = ?', [$email]);
-
-// ❌ SQL injection
-DB::select("SELECT * FROM users WHERE email = '{$email}'");
-```
-
-### Validate
-
-1. Verify every variable in SQL uses parameter binding (`?` or named `:param`).
-2. Confirm MariaDB/MySQL syntax — not PostgreSQL or MSSQL.
-3. Run EXPLAIN on complex queries to check index usage.
-4. Check that no PHP variable interpolation (`"$var"`, `'{$var}'`) appears in SQL strings.
-
-## Output format
-
-1. Parameterized SQL query using MariaDB/MySQL syntax
-2. EXPLAIN output for performance-critical queries
-
-## Gotcha
-
-- MariaDB and MySQL have subtle syntax differences.
-- The model writes `$variable` in SQL strings instead of `?` placeholders.
-- `GROUP BY` with `ONLY_FULL_GROUP_BY` requires all non-aggregated columns.
-- Use SQL types (`NULL`, `1/0`, `JSON_ARRAY()`) — not PHP equivalents.
-
-## Do NOT
-
-- Do NOT interpolate PHP variables into SQL strings — always parameterize.
-- Do NOT use PHP syntax (arrays, booleans, null) in raw SQL — use SQL equivalents.
-- Do NOT write raw SQL when the query builder can express the same thing clearly.
-
-## Auto-trigger keywords
-
-- raw SQL
-- SQL query
-- parameterized query
-- MariaDB syntax
-- SQL injection

package/.agent-src/skills/subagent-orchestration/SKILL.md

@@ -1,349 +0,0 @@
----
-model_tier: inherit
-name: subagent-orchestration
-description: "Use when orchestrating implementer/judge subagents — seven modes (do-and-judge ±two-stage, do-in-steps/parallel/worktrees, do-competitively, judge-with-debate) — models from .agent-settings.yml."
-domain: process
-workspaces:
-  - agent-config-maintainer
-packs:
-  - meta
----
-
-# subagent-orchestration
-
-## When to use
-
-* A task benefits from a second agent reviewing before apply — safety,
-  regression risk, cross-layer change
-* A plan has clear, independent slices that can be worked on in
-  parallel — unrelated bug fixes, multi-file migrations
-* A solution space is broad enough that multiple candidate
-  implementations are worth producing and comparing
-* The user explicitly asks "have a second agent review this" or "try
-  this two different ways"
-
-Do NOT use when:
-
-* The task is small and the overhead of a second agent exceeds the
-  value — single file, one-liner fix
-* The user is still exploring — route to brainstorming / planning
-  skills first
-* Budget is the constraint — each subagent call multiplies cost
-* The implementer and judge would be the same model on the same
-  context — no added signal
-
-## Goal
-
-Land a verified change (or set of changes) by combining implementer
-and judge subagents in a mode chosen deliberately, with model pairing
-read from `.agent-settings.yml` — never silently improvised.
-
-## The Iron Law
-
-```
-NO JUDGE ON THE SAME MODEL AS THE IMPLEMENTER ON THE SAME CONTEXT.
-```
-
-Same model + same context = same blind spots. The whole point of a
-judge is a fresh pair of eyes. If `.agent-settings.yml` resolves to
-identical implementer and judge models, surface the mismatch before
-running — do not silently continue.
-
-## The seven modes
-
-Each mode has a decision row: when to use, when not, and the expected
-model pairing. Defaults come from
-[`subagent-configuration`](../../contexts/subagent-configuration.md).
-
-### Topology hints — per-mode communication shape
-
-Descriptive, not enforced. Documents the **expected agent-to-agent
-communication topology** so consumers can predict latency, failure
-modes, and where consensus is required. Cited from
-[`external-findings.md § 2`](../../../agents/runtime/council/sessions/audit-2026-05-14-north-star/external-findings.md) <!-- council-ref-allowed: ADR decision trace for topology anti-drift defaults -->
-row 7 (Ruflo's `hierarchical, 6–8 agents, raft consensus` anti-drift
-default).
-
-| Mode | Topology | Anti-drift default | Notes |
-|---|---|---|---|
-| do-and-judge | `hierarchical` | 1 implementer · 1 judge · session-orchestrated | Two-node hub-and-spoke; orchestrator owns the loop. |
-| do-and-judge-two-stage | `hierarchical` | 1 implementer · 2 sequential judges | Stages are serialized; spec-judge gates quality-judge. |
-| do-in-steps | `ring` | N steps · 1 judge between each | Step N output → judge → step N+1 input; cycle on revise. |
-| do-in-parallel | `star` | 6–8 implementers · 1 judge · session-hub | Capped by `subagents.max_parallel`; judge runs once on union. |
-| do-competitively | `mesh` | 2–4 implementers · 1 judge | Implementers do not see each other; judge sees all candidates. |
-| judge-with-debate | `hierarchical-mesh` | 2 judges · 1 meta-judge | Judges debate (mesh edge); meta-judge reconciles (hierarchical). |
-| do-in-worktrees | `adaptive` | per-step topology of the underlying mode | Each worktree picks its own shape; chain is hierarchical. |
-
-**Anti-drift default** (Ruflo convention, descriptive only):
-`hierarchical, 6–8 agents, raft consensus`. Consumers free to
-override per orchestration — the table is the **starting point**,
-not a constraint. Topology is metadata for capacity planning, not
-runtime-enforced.
-
-**Glossary:**
-- `hierarchical` — orchestrator hub; agents reply to hub only.
-- `mesh` — agents see each other's outputs (e.g. competing diffs).
-- `hierarchical-mesh` — peer debate followed by hub reconciliation.
-- `ring` — output of step N feeds input of step N+1 in order.
-- `star` — N agents fan out from a single hub; no peer comms.
-- `adaptive` — topology shifts per step; outer chain remains hub.
-
-### 1. do-and-judge
-
-Implementer produces a diff; judge reviews; loop applies, revises, or
-hands off. Hard ceiling: **two revision cycles**, then stop and hand
-back to the user.
-
-| When to use | When not | Model pairing |
-|---|---|---|
-| Single-change task with non-trivial risk | Tiny fix, or spike/exploration | implementer = session; judge = one tier up |
-
-### 2. do-and-judge-two-stage
-
-Implementer produces a diff; **two judges run sequentially** — first a
-spec-compliance reviewer (does the diff satisfy the stated spec /
-acceptance criteria?), then a code-quality reviewer (is the diff well-
-written for the codebase it lands in?). The orchestrator only proceeds
-to stage two if stage one returns `DONE` or `DONE_WITH_CONCERNS`. A
-stage-one `BLOCKED` shortcuts the loop — there is no point quality-
-reviewing a diff that does not satisfy the spec.
-
-| When to use | When not | Model pairing |
-|---|---|---|
-| Spec is contested or AC are detailed; diff size makes one judge prone to missing one axis (correctness vs craft) | Spec is one sentence, or the diff is one line (collapse to mode 1) | implementer = session; spec-judge = one tier up; quality-judge = same tier as spec-judge, fresh context |
-
-**Why two stages, not one judge with both rubrics:** combining the
-rubrics in one prompt reliably regresses one of them — the judge "spends
-attention" on whichever rubric appears last. Splitting the prompts
-forces each judge to commit fully to its rubric.
-
-**Stage-routing rule:**
-- Stage-1 returns `DONE` → run stage-2.
-- Stage-1 returns `DONE_WITH_CONCERNS` → run stage-2; concerns carry
-  forward to the final envelope.
-- Stage-1 returns `NEEDS_CONTEXT` → pause; stage-2 does not run.
-- Stage-1 returns `BLOCKED` → final verdict is `BLOCKED`; stage-2
-  does not run (saves cost).
-
-### 3. do-in-steps
-
-Plan is split into N steps; judge runs **between** steps. A step that
-fails judgment is revised before the next step starts. Used for
-multi-file changes where a mid-plan mistake would cascade.
-
-| When to use | When not | Model pairing |
-|---|---|---|
-| Multi-step plan with ordered dependencies | Single-step change, or when steps are independent (use `do-in-parallel`) | implementer = session; judge = one tier up |
-
-### 4. do-in-parallel
-
-Independent slices run concurrently. No judge per slice — judge runs
-once on the aggregated result. Parallelism capped by
-`subagents.max_parallel` in `.agent-settings.yml`.
-
-| When to use | When not | Model pairing |
-|---|---|---|
-| Independent slices (different files, non-overlapping) | Any slice touches shared state | implementer = session; judge = one tier up, run once |
-
-### 5. do-competitively
-
-Multiple implementers produce candidate diffs for the **same** slice.
-Judge picks the winner and rejects the losers. Expensive — use only
-when the solution space is genuinely broad.
-
-| When to use | When not | Model pairing |
-|---|---|---|
-| Broad solution space (algorithm choice, API shape) | Well-defined problem with one good answer | implementers = same tier (≥2 instances); judge = one tier up |
-
-### 6. judge-with-debate
-
-Two judges each produce a verdict; a meta-judge reconciles
-disagreements. Used for high-stakes changes (security, data
-migration, public API) where a single judge is too easy to fool.
-
-| When to use | When not | Model pairing |
-|---|---|---|
-| Security, data integrity, public API change | Routine internal refactor | judges = same tier (2x); meta-judge = one tier up |
-
-### 7. do-in-worktrees
-
-Cross-wing or cross-skill chain executed across isolated git
-worktrees — each handoff in the chain runs in its own worktree, so
-the workspace state of one step never leaks into the next. Operationalizes
-the worktree boundary clause in
-[`docs/contracts/cross-wing-handoff.md`](../../../docs/contracts/cross-wing-handoff.md)
-§ 3. State-machine layer only — worktree creation/destruction lives
-in [`using-git-worktrees`](../using-git-worktrees/SKILL.md) and
-[`finishing-a-development-branch`](../finishing-a-development-branch/SKILL.md).
-
-| When to use | When not | Model pairing |
-|---|---|---|
-| Multi-step cross-wing chain (≥2 senior skills, each ≥30 min) where one step's open files / branch state would confuse the next | Fast iteration where each step < 30 min — worktree overhead exceeds isolation benefit | implementers = same tier per step; judge = one tier up at chain end |
-
-**Handoff shape:** initiator-skill emits the typed output declared in
-its `## Output` block → control passes to delegated-skill in a fresh
-worktree → delegated-skill consumes the input shape declared in its
-`## Input` (or `## When the agent should load this`) block. The
-handoff is auditable; `lint_handoffs.py` validates the chain.
-
-**Example chain (W3 launch):** `positioning-strategy` (worktree A) →
-`messaging-architecture` (worktree B, consumes positioning's
-`positioning-statement.md`) → `gtm-launch` (worktree C, consumes
-both prior artifacts). Each worktree carries one branch; the chain
-end produces a single integration PR.
-
-**Anti-pattern:** do not use for fast iteration loops where each
-step is under ~30 minutes. The branch-creation, context-switch, and
-worktree-cleanup cost dominates. Stick with mode 1 (do-and-judge)
-or mode 3 (do-in-steps) for those.
-
-**Competitive variant — per-candidate isolation.** When mode 5
-(`do-competitively`) is combined with worktrees, each candidate
-implementer runs in its own worktree (so candidates cannot read each
-other's open files or branch state). Selection rules:
-
-- **No auto-merge.** The orchestrator never merges a candidate
-  branch. Hard Floor per [`non-destructive-by-default`](../../rules/non-destructive-by-default.md) —
-  applies even under standing autonomy. ADR-005 records the reasoning.
-- **Ranked presentation.** Judge ranks candidates (1..N) with a
-  one-line justification per rank; user picks the winner.
-- **Loser worktrees stay.** The orchestrator does not delete losing
-  worktrees automatically — the user keeps the option to harvest a
-  partial idea before cleanup.
-
-## Status taxonomy — every subagent return uses one envelope
-
-Every implementer or judge return must conform to
-[`schemas/subagent-status.json`](schemas/subagent-status.json). Four
-statuses, no free-form alternatives:
-
-| Status | Meaning | Required keys (beyond `status`, `summary`) |
-|---|---|---|
-| `DONE` | Work shipped, all gates green. | `evidence[]` |
-| `DONE_WITH_CONCERNS` | Work shipped but caller must act on concerns. | `evidence[]`, `concerns[]` |
-| `NEEDS_CONTEXT` | Paused; caller can unblock by answering. | `blocking_question` |
-| `BLOCKED` | No path forward exists. | `blocking_reason` |
-
-**Why a fixed taxonomy:** orchestrators (`/do-and-judge`, `/do-in-steps`)
-route on status. Free-form "kind of done" returns force the orchestrator
-to interpret prose, which silently regresses the two-revision ceiling and
-the judge-rejected-do-not-apply rule. The schema makes routing mechanical.
-
-**Tests:** `tests/test_subagent_status_schema.py` exercises all four
-statuses plus rejection cases (missing required keys, unknown status,
-extra fields, conditional-key violations).
-
-**Distinguishing `NEEDS_CONTEXT` from `BLOCKED`:** `NEEDS_CONTEXT` means
-*"you, the caller, can fix this by telling me X"*. `BLOCKED` means
-*"no input from you unblocks this — escalate or rescope"*. If a subagent
-is unsure, it picks `BLOCKED` and the caller can downgrade.
-
-## Dispatch prompts — externalized
-
-Each mode's literal dispatch template lives under
-[`prompts/{mode}.md`](prompts/README.md). The orchestrator loads the
-matching prompt at dispatch time and substitutes `{{placeholders}}`.
-Edits to a prompt do not bloat this skill against the 400-line sunset
-trigger; `tests/test_subagent_prompt_loading.py` confirms each of the
-seven modes resolves to a loadable prompt that cites all four taxonomy
-statuses.
-
-## Procedure
-
-### 1. Inspect the task shape
-
-Before picking a mode, check:
-
-* Is the task single-change or multi-step?
-* Are slices truly independent, or do they share state?
-* Is solution space narrow (one right answer) or broad (trade-offs)?
-* Is risk high enough to justify debate?
-
-Do not pick a mode until these four questions have concrete answers.
-
-### 2. Resolve models
-
-Read `.agent-settings.yml`:
-
-* `subagents.implementer_model` → empty = session model
-* `subagents.judge_model` → empty = one tier above implementer
-* `subagents.max_parallel` → integer, default 3
-
-If resolution produces an unknown alias or implementer == judge in the
-same context, **stop** and report. Do not improvise.
-
-### 3. Pick the mode
-
-Match task shape to one of the seven modes. When two modes could fit,
-prefer the cheaper one (`do-and-judge` < `do-and-judge-two-stage` <
-`do-in-steps` < `do-in-parallel` < `do-competitively` <
-`judge-with-debate` < `do-in-worktrees`).
-
-**Mode 6 (`do-in-worktrees`) is gated by `worktrees.mode`** from
-`.agent-settings.yml` (default: `ask`). Resolve before picking:
-
-| `worktrees.mode` | Mode 6 |
-|---|---|
-| `ask` | Eligible. `using-git-worktrees` will run the per-creation permission ask. |
-| `on` | Eligible. Per-creation ask suppressed. |
-| `off` | **Not eligible.** Fall back to mode 3 (`do-in-steps`) — same step-by-step chain, in-place on the current branch. Unless the user **explicitly asked this turn** for a worktree chain, in which case proceed with mode 6 and acknowledge the override per [`using-git-worktrees § Pre-flight`](../using-git-worktrees/SKILL.md). |
-
-### 4. Dispatch
-
-Hand off to the matching command:
-
-* `do-and-judge` → [`/do-and-judge`](../../commands/do-and-judge.md)
-* `do-in-steps` → [`/do-in-steps`](../../commands/do-in-steps.md)
-* `judge` (standalone) → [`/judge`](../../commands/judge.md)
-
-Modes without a dedicated command (`do-in-parallel`,
-`do-competitively`, `judge-with-debate`) are orchestrated inline via
-the skill — describe the dispatch explicitly in chat so the user can
-follow it.
-
-### 5. Report
-
-Follow the output format below. Never merge a diff without reporting
-the judge verdict.
-
-## Gotcha
-
-* **Identical model both sides** — same blind spots. The Iron Law
-  blocks this before dispatch.
-* **Judge drifts off-task** — judge reviews *the diff*, not the task
-  description. Always attach the diff to the judge prompt.
-* **Infinite revision loop** — hard ceiling of two revisions in
-  `do-and-judge`; then hand back to the user.
-* **`do-in-parallel` on overlapping slices** — race conditions,
-  conflicting diffs. Verify independence before splitting.
-* **Cost surprise on `do-competitively`** — N implementers + 1 judge =
-  N+1 subagent calls for one slice. Confirm budget before dispatch.
-
-## Output format
-
-1. **Mode chosen** — one of the seven, with the one-line reason
-2. **Model pairing** — implementer model / judge model (resolved)
-3. **Verdict** — applied / revised / handed back
-4. **Evidence** — diff summary, test output, or judge transcript
-5. **Next step** — what the user does now (review PR, pick winner, etc.)
-
-## Do NOT
-
-* NEVER run implementer and judge on the same model and same context
-* NEVER exceed the two-revision ceiling in `do-and-judge` without user
-  consent
-* NEVER run `do-in-parallel` on slices that touch shared files
-* NEVER apply a diff that the judge rejected without explicit user
-  override
-* NEVER silently resolve an unknown model alias to a fallback
-
-## Handover
-
-| Task                                 | Skill / command                      |
-|--------------------------------------|--------------------------------------|
-| Configuration reference              | [`subagent-configuration`](../../contexts/subagent-configuration.md) |
-| Do-and-judge loop                    | [`/do-and-judge`](../../commands/do-and-judge.md) |
-| Stepwise plan with judge gates       | [`/do-in-steps`](../../commands/do-in-steps.md) |
-| Standalone judge on an existing diff | [`/judge`](../../commands/judge.md)  |
-| External / networked second opinion  | [`ai-council`](../ai-council/SKILL.md) |
-| Verifying completeness               | [`verify-before-complete`](../verify-before-complete/SKILL.md) |