Skills

The catalog of all 37 skills: 32 under skills/ and 5 repository-local ones under .agents/skills/. For each, the frontmatter, the engine step that invokes it, what it reads, what it writes, and whether it blocks.

A skill is a SKILL.md directory. The engine dispatches most of them by name at a step; the rest are invoked by an operator, by another skill, or not wired at all. The two plugins in this repository (json-stdout-subscriber, recorder-provider) define zero skills — they are a UI renderer and an LLM provider respectively.

Skills are grouped by their declared phase and, within a group, listed in flow order. The text under each skill name is its verbatim description frontmatter value — that string is what a host agent matches on when deciding to invoke the skill.

Frontmatter fields

Field	Required	Meaning
name	yes	Skill identifier; must match the directory name
description	yes	Model-facing trigger text — when to invoke this skill
enforcement	yes for skills/*	Declared strictness: advisory, gating, or structural. Advisory only. The engine’s step definition decides real skippability — see Known limitations
phase	yes for skills/*	understand, decide, build, ship, or all
standalone	no	Whether an operator can run the skill on its own. Absent means non-standalone
operator_only	no	true marks a skill an operator invokes from outside a run. bin/install still symlinks it into both user-space catalogs (~/.claude/skills, ~/.agents/skills), so the operator has it on either provider; the engine suppresses it per dispatch instead. Enforced — integrity check 5d fails on drift between this flag and OPERATOR_ONLY_SKILLS in worktree-prepare.ts. See operator-only suppression coverage for what each provider actually enforces
phase_active_policy	no	Operator-skill policy for .pipeline/phase-active. daemon-triage declares advisory: marker and daemon-status evidence may warn but never block read-only diagnosis
disable-model-invocation	invocation-dependent	Claude control. true keeps the skill operator/engine-invocable but removes it from model-initiated selection
implicit_invocation	invocation-dependent	Harness audit marker. required is allowed only for a verified same-session dependency that must remain model-invocable; it is not a host setting
requires	no	Prerequisite skills or artifact paths
model	no	Hand-authored model pin. Seven skills carry one; the rest inherit. See models

Invocation policy

Discovery is not activation. Every catalog entry is classified exhaustively by integrity check 2a:

• Explicit-only: Claude declares disable-model-invocation: true; Codex declares policy.allow_implicit_invocation: false in agents/openai.yaml. An operator or engine-rendered /skill-name or $skill-name prompt still works.
• Implicit-required: the shared frontmatter carries implicit_invocation: required, and neither host disable is present. This exception is reserved for a verified model-initiated caller inside an already active skill.

The 13 implicit-required shipped skills are:

Skill group	Skills	Why they cannot be explicit-only in the distributed catalog
/composer DECIDE composition	explore, prd, architecture-diagram, architecture-review, stories, conflict-check, plan, coherence-check	/composer must run the real workflows directly in its current chat; it does not launch a second CLI session for them
Other same-session handoffs	intake, debugging, simplify, verify-claims, code-removal	Called from an active skill: issue authoring, fresh debugging, batch simplification, load-bearing claim verification, or removal-shaped build work — /pipeline dispatches /code-removal in place of a RED cycle

Because these skills remain visible for same-session composition, each description carries a closed activation boundary: the active lifecycle/caller state that qualifies, plus nearby requests that do not. A generic feature, change, plan, review, bug, or question is not sufficient by itself. Explicit operator invocation remains available regardless of these implicit-selection boundaries.

The 19 explicit-only shipped skills are assess, bootstrap, build-review-security, build-review-test-quality, code-review, composer, conduct, daemon-triage, engineer, finish, manual-test, memory, pipeline, prd-audit, rebase, remediate, pr, tdd, and writing-system-tests. The five repository-local skills are also explicit-only: event-spine, maintain-documentation, release-disposition, scope-check, and write-tests.

code-review is intentionally explicit-only: pipeline embeds its three-stage evaluator contract and states that no separate code-review dispatch is needed. pr is likewise explicit-only because FINISH inlines its authoring contract and explicitly forbids delegating to /pr. Engine registry invocations are explicit prompts, including conditional remediate and rebase steps, so those skills do not need model discovery. A user may locally force any implicit-required skill to explicit-only, but composed callers that depend on it will no longer complete automatically.

Operator-only suppression coverage

operator_only: true is enforced per dispatch, not at install time — the operator keeps the skill on both providers. Catalog invocation policy now provides the same baseline on both hosts:

	Claude	Codex
Self-host build	Catalog disable-model-invocation, plus skillOverrides defense in depth	Catalog allow_implicit_invocation: false, plus pruning from the throwaway CODEX_HOME defense in depth
Any other repo	Catalog disable-model-invocation	Catalog allow_implicit_invocation: false

daemon-triage therefore remains available when an operator explicitly asks for it without being a model-selected response to an unrelated failure. Its phase-marker/liveness warning and per-mutation approval contract remain necessary for explicitly initiated triage.

The repository integrity suite checks that every skills/*/SKILL.md has name, description, enforcement, and phase. The five .agents/skills/ entries are outside that required-field check; they declare name, description, and the Claude invocation control. Check 2a covers invocation policy across both catalogs and both host metadata formats.

Index

Skill	enforcement	phase	model	Engine step	Gate role
bootstrap	advisory	understand	—	bootstrap (out-of-band)	Advisory
memory	gating	understand	—	memory (1)	Advisory
assess	gating	understand	sonnet	assess (out-of-band)	Advisory
conduct	gating	all	—	worktree (0), complexity (3)	Blocking via worktree (structural)
verify-claims	gating	all	—	none	Blocking, inside the calling skill
code-removal	advisory	all	—	none	Advisory
daemon-triage	advisory	all	—	none (operator-only)	None — read-only diagnosis; recovery only on per-action operator approval
architecture-diagram	gating	all	sonnet	architecture_diagram (5)	Advisory as a step; blocking at land time
explore	advisory	decide	—	explore (2)	Advisory
prd	gating	decide	—	prd (4)	Blocking
architecture-review	gating	decide	—	architecture_review (6), architecture_review_as_built (18)	Advisory at 6, blocking at 18
stories	gating	decide	—	stories (7)	Blocking
conflict-check	gating	decide	—	conflict_check (8)	Blocking
plan	gating	decide	—	plan (9)	Blocking
coherence-check	gating	decide	—	coherence_check (10)	Blocking
intake	gating	decide	—	none — operator-invoked	Neither
composer	advisory	decide	opus	none — operator-invoked	Neither as a step; the land gate blocks
engineer	advisory	decide	opus	none — operator-invoked	Neither as a step; the land gate blocks
writing-system-tests	gating	build	—	acceptance_specs (11)	Blocking
pipeline	structural	build	—	build (12)	Blocking; cannot be disabled
tdd	structural	build	—	none — runs inside build	Neither
code-review	gating	build	opus	none — pipeline batch boundary	Blocking in place
simplify	gating	build	sonnet	none — pipeline batch boundary	Blocking in place
debugging	gating	build	opus	none — on demand	Neither
manual-test	gating	ship	—	manual_test (16)	Blocking
prd-audit	gating	ship	opus	prd_audit (17)	Blocking
remediate	gating	ship	—	remediate (out-of-band)	Advisory — it is the unblocker
rebase	advisory	ship	—	rebase (19) — on conflict only	Blocking via the structural step
finish	gating	ship	—	finish (20)	Blocking
pr	advisory	ship	—	none — operator-invoked; /finish inlines it rather than calling it	Neither
maintain-documentation	(none)	(none)	—	custom step after rebase	Blocking, this repository only
release-disposition	(none)	(none)	—	custom step after maintain-documentation	Blocking, this repository only
write-tests	(none)	(none)	—	none — unwired	Neither

Gate roles: Blocking means a non-passing result stops progression. Advisory means it runs and records but never blocks. Neither means it has no gate role in the flow.

Cross-cutting skills

conduct

Use to guide a feature through the full SDLC. Checks artifact state, determines current phase, tells you what to run next, and blocks progression when gates aren’t met.

• Frontmatter — enforcement: gating, phase: all, standalone: true, requires: [], no model pin.
• Engine step — not a step itself. The engine dispatches it with an argument for two steps: /conduct worktree (index 0, structural) and /conduct complexity (index 3, advisory).
• Inputs — artifact-existence checks across CLAUDE.md, .memory/index.md, and the .docs/ subdirectories; .pipeline/conduct-state.json and the SHIP-tail evidence files; a grep of .docs/decisions/adr-*.md for Status: DRAFT.
• Outputs — .pipeline/conduct-state.json (complexity_tier, per-step status, feature_status); a clean-pass marker under .docs/conflicts/. Neither of its two steps has a completion glob.
• Gate role — the gate host. It directs; it does not run other skills.

verify-claims

Use only when an active workflow is about to rely on a nontrivial factual claim or assumption for a spec, plan, ADR, finding, or code decision. Do not invoke for casual questions, status reports, restatements, or trivially verifiable mechanics.

• Frontmatter — enforcement: gating, phase: all, standalone: true, requires: [], no model pin.
• Engine step — none. It is a discipline applied inside the calling skill’s context and model, not a separately dispatched agent. Fifteen skills declare it in requires.
• Inputs — whatever the calling skill’s load-bearing output is. One cheap read or grep is preferred over an estimate whenever it would settle the question.
• Outputs — .pipeline/verify-claims-<step>.md when invoked inside an engine step, otherwise inline in the artifact or response. On an autonomous block it writes .pipeline/HALT with the assumption ledger as its body.
• Gate role — blocking. Verdict CLEAR proceeds; ASSUMPTIONS_PENDING blocks. Interactive runs wait for operator approval; autonomous runs HALT and never guess a likely value.

daemon-triage

Use when a feature is stuck in daemon execution — halted, spinning, stalled, or silently not progressing — and an operator needs to know why. Diagnoses the failure and routes it to the right runbook. Operator-invoked only; never auto-dispatched, and never mutates anything without explicit per-action approval.

• Frontmatter — enforcement: advisory, phase: all, standalone: true, operator_only: true, phase_active_policy: advisory, requires: [verify-claims], no model pin.
• Engine step — none, by design. It is never dispatched. operator_only: true suppresses it for step sessions where the provider supports suppression (see Frontmatter fields). The skill treats .pipeline/phase-active and daemon status as advisory context: an apparently live step produces a warning, while read-only triage always continues. Recovery mutations remain individually operator-approved.
• Inputs — read-only evidence only: ai-conductor daemon status, .daemon/daemon.log, and the feature’s .pipeline/ state (HALT + HALT.class, events.jsonl, task-status.json, step-heartbeat, phase-active, gates/<step>.json), plus the branch’s commit log.
• Outputs — a triage report at .daemon/triage/<slug>-<timestamp>.md. Deliberately not under .pipeline/ — triage output is not feature evidence and must never be read as such by a gate.
• Gate role — none. Diagnosis is unconditionally read-only; gathering evidence never changes the state being measured. It may then carry out recovery, but every mutation — clearing a halt, park/unpark, editing .pipeline/, any writing git command — is presented with its blast radius and individually approved by the operator first. Approval is per-action and never standing consent, and it never relaxes the safety rails (an approved delete is still enumerated explicitly). Deliberately conservative while classification accuracy is being established.
• Runbooks — reached via skills/daemon-triage/runbooks, a symlink to docs/runbooks/. The symlink is what makes the reference resolve correctly in a consumer repo, where the harness’s docs/ tree is not present but the skill directory itself is symlinked in by bin/install.

architecture-diagram

Use only within an active harness lifecycle when its architecture-diagram step is current. Generates and maintains C4 Mermaid diagrams; do not invoke for ordinary code changes or general architecture questions.

• Frontmatter — enforcement: gating, phase: all, standalone: true, requires: [], model: sonnet.
• Engine step — architecture_diagram (index 5, DECIDE, skipped at tier S). Engine enforcement is advisory.
• Inputs — codebase structure (Procfile, docker-compose.yml, database.yml, routes, model definitions); the plan and stories on the update path; the mermaid_renderer config key.
• Outputs — .docs/architecture/system-context.md, containers.md, components.md, erd.md, and sequences/<flow-name>.md.
• Gate role — advisory as a step. Real enforcement is at land time: the spec-PR gate re-renders every authored Mermaid block and rejects the spec fail-closed if any block fails to render, or if diagrams exist but the renderer is unavailable.

UNDERSTAND-phase skills

bootstrap

Use when starting a new project, onboarding to an existing project, or setting up the harness for the first time. Detects project type, tech stack, and generates project-specific configuration.

• Frontmatter — enforcement: advisory, phase: understand, standalone: true, requires: [], no model pin.
• Engine step — bootstrap (out-of-band, UNDERSTAND). Runs in the prelude before the loop.
• Inputs — root indicator files (Gemfile, package.json, pyproject.toml, Cargo.toml, go.mod, database.yml, .rspec, Procfile); tech-context/<stack>/; existing CLAUDE.md, AGENTS.md, .claudeignore, and .claude/settings.json, which it preserves rather than overwrites; gh and git history.
• Outputs — bootstrap_mode in .pipeline/conduct-state.json; env boundary files; .claudeignore; a PR template; .claude/settings.json; the .pipeline/, .worktrees/, and .docs/ directory tree; DRAFT as-built stories; observed ADRs; a .memory/ seed; initial architecture diagrams and a styleguide; a registry entry. No completion glob.
• Gate role — advisory, but downstream skills depend on the directory structure it creates. Failures are surfaced and not silently swallowed: a rejected first push must never be forced.

memory

Use when the operator requests project recall, when the harness dispatches its memory step, or when an active harness workflow requires a memory checkpoint. Recall-before-act protocol with categorized persistence and staleness detection.

• Frontmatter — enforcement: gating, phase: understand, standalone: true, requires: [], no model pin.
• Engine step — memory (index 1, UNDERSTAND). Engine enforcement is advisory.
• Inputs — .memory/index.md; entries under .memory/decisions/, patterns/, gotchas/, and context/, read in full; referenced file paths, checked for drift.
• Outputs — kebab-case Markdown entries under .memory/, each with created, category, and related frontmatter; an updated .memory/index.md. No .docs/ or .pipeline/ artifact.
• Gate role — advisory. Its two in-skill rules (recall at invocation start, persist decisions at declared checkpoints) produce no verdict, no marker file, and block nothing downstream.

assess

Use for codebase health assessment. Dispatches 9 specialist agents + CTO orchestrator to evaluate security, data integrity, dependencies, architecture, duplication, testing, infrastructure, observability, and developer experience.

• Frontmatter — enforcement: gating, phase: understand, standalone: true, requires: [verify-claims], model: sonnet.
• Engine step — assess (out-of-band, UNDERSTAND prelude). Auto-skipped with a mode_skip event when bootstrap_mode is new.
• Inputs — a full file listing; session-loaded tech-context; existing ADRs under .docs/decisions/ for cross-reference and stale-ADR checks.
• Outputs — nine specialist reports under .pipeline/assessment/; the committed .docs/decisions/technical-assessment-<date>.md; the assess, assess_date, and assess_verdict state keys.
• Gate role — advisory. A CRITICAL verdict implies addressing findings before feature work but blocks nothing; findings become backlog.

DECIDE-phase skills

explore

Use only within an active engineer/conduct DECIDE workflow when approach selection and product-versus-technical track classification are still unresolved. Do not invoke for ordinary implementation, review, explanation, or an already-decided change or hotfix.

• Frontmatter — enforcement: advisory, phase: decide, standalone: true, requires: [verify-claims], no model pin.
• Engine step — explore (index 2, DECIDE). Always runs — it sets the track that gates prd and prd_audit.
• Inputs — .memory/; existing .docs/stories/; prior bootstrap exploration. At most two directory-partitioned exploration agents.
• Outputs — exactly one committed artifact, .docs/track/<slug>.md, carrying Track: product|technical and Scope boundary: <operator-confirmed breadth and exclusions>; ephemeral notes under .pipeline/; the selected approach and rejected alternatives promoted to .memory/decisions/. No completion glob, by design.
• Gate role — advisory, with four internal hard blocks: any unconfirmed assumption that would change the approach or track HALTs an autonomous run; the track must be operator-confirmed; the skill must ask the operator how comprehensive the fix should be and stop before approach confirmation if unanswered — it never defaults silently to minimal, balanced, or comprehensive scope; and the skill must never call ExitPlanMode, which would mark the step failed.

prd

Use only within active engineer/conduct DECIDE after explore confirmed the product track, when a committed product requirements document is required. Do not invoke for technical-track work, ordinary specifications, or general product discussion.

• Frontmatter — enforcement: gating, phase: decide, standalone: true, requires: [verify-claims], no model pin.
• Engine step — prd (index 4, DECIDE, prerequisite explore). Skipped on the technical track; a kickback target.
• Inputs — the explore track output, the design-doc and API-contract templates, and the original request.
• Outputs — .docs/specs/<date>-<topic>.md; a superseded prior doc renamed with a SUPERSEDED- prefix; an API response contract for API projects. It writes no files outside .docs/specs/.
• Gate role — blocking. A product-only audit runs before the PRD is presented: a PRD that names a new internal mechanism has failed and must be rewritten. Requires explicit operator approval.

architecture-review

Use only within an active harness lifecycle when pre-stories feasibility review, a pipeline batch drift check, or the SHIP as-built review is current. Do not invoke for ordinary implementation, code review, or general architecture questions.

• Frontmatter — enforcement: gating, phase: decide, standalone: true, requires: [verify-claims], no model pin.
• Engine step — two: architecture_review (index 6, DECIDE, engine enforcement advisory) and architecture_review_as_built (index 18, SHIP, engine enforcement gating), the latter invoked as /architecture-review --as-built. The DECIDE-time step skips at tier S; the as-built step runs at every tier.
• Inputs — .docs/decisions/, .docs/architecture/, CLAUDE.md, .memory/decisions/, existing code, and the PRD’s FRs or the explore output. As-built mode reads only Status: APPROVED ADRs, the feature diff, and the sealed .docs/stories/ criteria that anchor its plan-gap outcome judgement.
• Outputs — .docs/decisions/architecture-review-<date>-<feature>.md; ADRs under .docs/decisions/; .pipeline/architecture-review-as-built.md, which must be rewritten on every invocation or the engine reads it as stale and halts the SHIP tail.
• Gate role — the as-built half is blocking and fail-closed: APPROVED, APPROVED WITH DRIFT NOTES, and PLAN_GAP with Outcome delivered: yes satisfy it. A BLOCKED artifact contains exactly one ## Blocking Findings table with Finding, Class, Governing clause, and Summary columns. Class is REMEDIABLE or DESIGN; every REMEDIABLE row cites an approved ADR decision or an active plan task. An all-REMEDIABLE report can use the enabled, bounded remediation route; DESIGN, invalid, disabled, or exhausted reports halt needs-human. The DECIDE half is advisory at the step level; its DRAFT-ADR hard gate is enforced by the conduct state machine and by the land-time spec gate instead. The as-built half’s production reachability sweep derives root-to-caller-to-export chains from current shipped source, never from plan-declared callers.

stories

Use only within active engineer/conduct DECIDE after architecture approval, when a committed .docs/stories acceptance artifact is required. Do not invoke for general user-story examples, requirements discussion, or direct implementation requests.

• Frontmatter — enforcement: gating, phase: decide, standalone: true, requires: [verify-claims], no model pin.
• Engine step — stories (index 7, DECIDE, prerequisite architecture_review). A kickback target; no tier skip.
• Inputs — approved PRD FRs, or technical intent plus approved ADRs; existing .docs/stories/ for deduplication and DRAFT completion; tech-context; .memory/.
• Outputs — .docs/stories/<feature-name>.md, one file per feature area, appended if it exists.
• Gate role — blocking. No story is accepted without at least one concrete negative path per acceptance criterion. The verdict layer additionally requires ### Happy Path and ### Negative Path(s) sections with Given/When/Then bullets and no Status: DRAFT. The status marker is also a downstream hard gate: the land gate rejects stories lacking Status: Accepted.

conflict-check

Use only within active engineer/conduct DECIDE after accepted stories and before plan, or when that workflow explicitly rechecks remediated stories. Detects story interactions; do not invoke for Git conflicts, merge conflicts, or general requirements discussion.

• Frontmatter — enforcement: gating, phase: decide, standalone: true, requires: [verify-claims], no model pin.
• Engine step — conflict_check (index 8, DECIDE, prerequisite stories, skipped at tier S).
• Inputs — all .docs/stories/*.md; active .docs/specs/; prior .docs/conflicts/ reports; and approved ADRs. conflict_check.adr_corpus defaults to change_set; repo_wide narrows all approved ADRs to the stories’ subject and records the ADRs examined and narrowed out.
• Outputs — .docs/conflicts/<date>-<description>.md, overwritten on re-run; in-place edits to affected story files; superseding ADRs. An ADR-versus-story conflict quotes both opposing sentences verbatim; multi-sentence excerpts use […] for every omitted span.
• Gate role — blocking. It loops until zero blocking conflicts remain. Kickback routing is by root cause: contradictory FRs go to prd, incompatible design goes to architecture_review, pure phrasing is resolved in stories. In an unattended run a blocking conflict HALTs for a human — never a silent pass.

plan

Use only within active engineer/conduct DECIDE after accepted stories and a clean conflict-check, when a committed .docs/plans implementation artifact is required. Do not invoke for conversational planning, implementation checklists, or direct coding requests.

• Frontmatter — enforcement: gating, phase: decide, standalone: false, requires: [".docs/stories/ with both paths", ".docs/conflicts/ clean pass or no blocking conflicts", verify-claims], no model pin.
• Engine step — plan (index 9, DECIDE, prerequisite conflict_check). A kickback target; no tier skip.
• Inputs — all .docs/stories/; the clean conflict-check pass; the architecture review’s ## Wiring Surface section at tiers M and L.
• Outputs — .docs/plans/<date>-<feature>.md.
• Gate role — blocking. It refuses to produce a plan without stories, dependency lines, both paths, and a clean conflict-check; every acceptance criterion must map to at least one task, and every citable decision in a non-deleted land-accepted ADR (APPROVED or SUPERSEDED) in the current change set must have one Architecture Obligation Coverage disposition (task, existing, or no-change). Forty-one or more tasks is a hard stop; 21–40 warns. Every task carries a Done when: block with two to five nonblank, falsifiable completion checks, each on one physical line and naming a mechanism plus its observable assertion rather than merely restating the mapped criterion. Each changed cross-boundary behavior has exactly one integration-owning task whose checks state observable behavior through an appropriate project entry point; internal tasks do not each acquire an integration-test obligation. At land time, a missing, empty, underspecified, or oversized block rejects the whole spec; Markdown fenced-code examples do not count as task structure or checks. An unbounded quality word (“fail-closed”, “robust”, “comprehensive”) must be closed by an enumeration or a named mechanism in the same block, and completion review is bound by these checks (deeper concerns are filed as intake, not raised as blocking findings). Each Story: line takes one id — a comma-separated list silently registers only the first. Plans must not append a terminal catch-all task that re-proves the completed feature; scoped tests stay with their behavior-owning implementation task, while writing-system-tests and later BUILD/SHIP gates own whole-feature validation.
• Declared pattern replication — a plan may add **Pattern-source:** and **Rename-map:** header lines to declare that it replicates an existing source file under a rename map, so BUILD copies and verifies that source mechanically instead of deriving it from scratch. Both lines are required together; either line alone, an unresolvable source path, or a malformed rename-map pair is malformed and fails closed, distinct from the no-declaration absent case. See gates for how build_review verifies the declared copy.

coherence-check

Use only within active engineer/conduct DECIDE after plan for a Medium or Large spec. Authors the committed outcomes-to-requirements-to-stories-to-tasks mapping; do not invoke for Small work or ordinary traceability questions.

• Frontmatter — enforcement: gating, phase: decide, standalone: true, requires: [verify-claims], no model pin.
• Engine step — coherence_check (index 10, DECIDE, prerequisite plan, skipped at tier S).
• Inputs — .docs/complexity/ for the tier; staged outcomes or .docs/intake/<plan-stem>.md; .docs/specs/<plan-stem>.md for FRs; .docs/stories/<plan-stem>.md; .docs/plans/<plan-stem>.md; and accepted ADRs that constrain the stories.
• Outputs — .docs/coherence/<plan-stem>.md. The stem must match the plan filename stem exactly or the land validator rejects it as a missing coherence artifact. Applicable adr rows trace each accepted ADR to the stories that implement or must honor it, and independently judge every decision’s plan-level Architecture Obligation Coverage disposition. The sixth row class, criterion, maps each exact extracted happy- or negative-path criterion to cited plan tasks in a six-cell row: criterion text, task ids, verdict, a verbatim Done when quote, and diff-local or outside-diff.
• Criterion achievability — independently judges whether satisfying the cited task checks would produce the Then-clause within approved architecture (§4g). Checks must establish a mechanism; restating the outcome does not establish delivery. The pass sweeps approved ADRs in the change set for binding constraints. An established inability to deliver is fail, explained with CANNOT-DELIVER: prose below the table identifying the criterion, task, quoted check, and any binding ADR decision. Criterion rows retain six cells; no Notes cell or new gap-id vocabulary is added. The review also checks preserved/default-mode observables against new side effects across tasks, and verifies that closed state/result/reason sets can truthfully represent required negative paths. Checks over normalized inputs or exported subsets must establish the source boundary as well as the helper behavior; agreement within an incomplete subset does not establish complete coverage.
• PRD ↔ stories tie-out — the fr and story row classes are checked in both directions (SKILL.md §4e). Forward: no PRD FR-N without a citing story that a task covers. Reverse: no story citing an FR-N the PRD never declares, and no story citing no FR at all. Both directions are re-derived mechanically by the land-time gate from the real PRD and stories files, so the skill spends its judgement on whether a cited FR is actually delivered by that story’s scenarios — a correct citation the acceptance criteria contradict is fail, not covered. Story-versus-story contradictions stay with conflict-check; this skill compares each story against the PRD.
• Gate role — blocking. It authors the artifact the land-time coherence gate validates. Verdicts are exactly covered, gap, or fail — fail marks a row whose counterpart exists but contradicts it or whose cited task checks cannot deliver the criterion under approved architecture, which coverage alone cannot express. Criterion rows enforce that vocabulary mechanically; unknown values are malformed. The five legacy row classes retain affirmative-by-default parsing for backward compatibility. In an autonomous run an ambiguous row is marked gap and left for the fail-closed land gate — never silently passed. At tier S it does not run and must not author a stub.

intake

Use only when the requested deliverable is a GitHub intake issue, or when an active harness workflow hands an observation off for later DECIDE. Do not invoke merely because a bug, idea, or observation is being discussed.

• Frontmatter — enforcement: gating, phase: decide, standalone: true, requires: [verify-claims], no model pin.
• Engine step — none. Operator- or agent-invoked, in whatever session observed the problem.
• Inputs — verbatim commands and output, log excerpts with source path and timestamp, file:line and SHA references, repro steps, frequency, and environment facts.
• Outputs — a GitHub issue. No repository file artifact.
• Gate role — neither. Its gate is a pre-file checklist at authoring time; nothing downstream blocks on it. See intake for the filing procedure.

composer

Interactive, phone-drivable idea→spec loop: hands a raw idea to the right repo, runs the full DECIDE phase there, and opens a spec PR. Use when capturing and routing new work, NOT when building inside one repo (that is plain conduct).

• Frontmatter — enforcement: advisory, phase: decide, standalone: true, requires: [], model: opus.
• Engine step — none. It is a separate control plane with its own ai-conductor compose subcommands.
• Inputs — a claimed GitHub intake issue, or a launch argument or chat idea; the project registry.
• Outputs — in a per-idea worktree on a spec/<slug> branch: the track marker, the complexity marker whose stem must match the plan stem, and the full .docs/ DECIDE artifact set; an intake marker committed at land; the spec PR.
• Gate role — neither as an engine step, but the land gate is hard: no idea reaches a build without a merged spec PR, only the operator merges, no spec lands with a DRAFT ADR, and the tier must be recorded. See composer loop. The deprecated engineer skill is a thin compatibility delegate to this canonical composer skill.

engineer

Deprecated compatibility delegate to composer. It preserves existing explicit /engineer invocations while the canonical skill is /composer.

• Frontmatter — enforcement: advisory, phase: decide, standalone: true, requires: [], model: opus.
• Engine step — none. Use composer for new work.

BUILD-phase skills

writing-system-tests

Use BEFORE implementing any feature that has stories in .docs/stories/ — generates failing acceptance specs from acceptance criteria as the RED phase of TDD. Generates HTTP/request-level acceptance tests for headless/API projects, end-to-end UI tests for projects with a frontend, using the project’s own test framework and directory conventions.

• Frontmatter — enforcement: gating, phase: build, requires: [verify-claims], no model pin. It is the only skills/* entry with no standalone key, so it defaults to non-standalone.
• Engine step — acceptance_specs (index 11, BUILD, prerequisite plan, skipped at tier S).
• Inputs — happy and negative acceptance criteria from .docs/stories/*.md; the existing test suite and tech-context for framework and layout detection; the approved PRD FR list on the product track.
• Outputs — committed acceptance spec files in the project’s test directories, plus gitignored run evidence: .pipeline/acceptance-specs-red.json, .pipeline/fr-coverage.md, and .pipeline/acceptance-specs-run.json.
• Gate role — blocking. The gate rejects unless the RED evidence shows at least one failure, zero skips, zero errors, and at least one executed spec. Any unresolved FR-coverage row is a hard stop under the daemon.
• Declared pattern replication — when the plan header resolves a **Pattern-source:** / **Rename-map:** declaration, the skill copies and renames the source feature’s acceptance specs instead of deriving them. RED is still earned honestly: the copied specs fail because their target does not yet exist. An empty source spec set, a rename-map target-path collision, or an all-passing copied set all fail closed rather than falling back to derivation.

pipeline

Use when executing an implementation plan with multiple tasks. Factory orchestration with three autonomy levels, quality gates, rework budgets, and audit trails.

• Frontmatter — enforcement: structural, phase: build, standalone: false, requires: [".docs/plans/ with implementation plan"], no model pin.
• Engine step — build (index 12, BUILD, prerequisite plan). Checkpoint, loop gate, structural, never tier-skipped, never disableable.
• Inputs — the plan’s task dependency graph, file sets, and dependency lines; .pipeline/task-status.json; story acceptance criteria; prior batch reviews; ADRs and the approved PRD for the design-conformance check.
• Outputs — .pipeline/audit-trail/batch-N/review.json and the batch simplification records; .pipeline/progress.log; .pipeline/summary.json; .pipeline/halt-user-input-required and .pipeline/HALT on a stall; at least one .memory/ entry per batch; a pipeline_closeout record in .pipeline/pipeline-events.jsonl per completed evaluator gate, written via ai-conductor closeout-event. .pipeline/current-task and .pipeline/task-status.json are written by engine hooks and must not be hand-edited.
• Read-only SHIP verdicts — BUILD sessions, including remediation retries and every implementer dispatch, may read but never write, delete, rename, or recreate the SHIP validator verdict artifacts (prd-audit.md, architecture-review-as-built.md/.json) or their code-stamp sidecars. Only the validator’s next dispatch produces a new verdict; a fixed finding is proven through ai-conductor task done <id> --done-when <n>=<evidence>.
• Gate role — blocking. Evaluator dispatch at each batch boundary is mandatory; a missing or empty review.json halts and re-dispatches. A missing, malformed, or non-matching evaluator pipeline_closeout record is an independent second hard gate (waived for a batch already in flight before the closeout-event emitter shipped) — see ai-conductor closeout-event. BLOCK halts and escalates; REQUEST_CHANGES triggers rework against a three-cycle budget. Two consecutive zero-completion attempts trip a circuit breaker.
• Declared replication copy task — on a plan with a resolved **Pattern-source:** / **Rename-map:** declaration, exactly one task is the mechanical, zero-LLM copy: it writes only the targets its **Files:** declaration lists, fails closed naming an undeclared target or an unreadable source, and leaves no partial copy on failure. A later task the copy commit fully satisfies — every acceptance criterion and its scoped verification — may close through the existing Evidence: satisfied-by <sha> form; a task only partly satisfied always runs the full, unmodified RED → DOMAIN → GREEN → DOMAIN → COMMIT cycle instead of being split.
• Fan-out — Standard and Full derive a ready frontier from completed dependencies and non-overlapping file sets, then launch up to three tasks in one provider-native concurrent dispatch and join before verification. Claude Code uses multiple Agent tool calls in one response; Codex uses multiple collaboration.spawn_agent calls in one response. Conservative, dependent tasks, and overlapping-file tasks stay sequential. A selected host without native fan-out stops with an actionable capability diagnostic instead of silently serializing Standard or Full.
• Dispatches — agents/evaluator.md, agents/generator.md, agents/worktree-manager.md.

tdd

Use when implementing any feature or bugfix. Five-step cycle: RED → DOMAIN → GREEN → DOMAIN → COMMIT. Enforces test-first development with domain integrity review at every phase boundary.

• Frontmatter — enforcement: structural, phase: build, standalone: true, requires: [], no model pin.
• Engine step — none. It is the per-task cycle every pipeline implementer runs.
• Inputs — one acceptance criterion from the plan; test and source directory paths; tech-context lint and typecheck commands; .memory/decisions/.
• Outputs — git commits carrying Task: <id> trailers, including empty evidence commits; conditional .memory/gotchas/ and .memory/patterns/ entries. No .docs/ artifact.
• Gate role — neither in flow terms, but COMMIT is a hard in-cycle gate: scoped tests green, linter and type-check clean, clean tree, any cross-boundary integration check owned by the task proven through the appropriate project entry point (helper-level proof alone does not close that task), and an exact bare plan task id in the trailer. The domain reviewer holds veto authority back to RED or GREEN. Task: trailers are telemetry only — build completion is derived by build_review, not from trailer self-reports.
• Declared replication does not shorten the cycle — a declared replication’s copy task only establishes a baseline. A later task closes via Evidence: satisfied-by <copy-sha> only when the copy satisfies that task’s whole scope; any task introducing behavior the source lacks, or only partly covered by the copy, runs the identical unmodified cycle. A first test that passes immediately on a delta task does not permit skipping to implementation.
• Dispatches — agents/generator.md (RED and GREEN), agents/domain-reviewer.md (both DOMAIN phases).

code-removal

Use only when deletion is the requested deliverable inside an active change: removing a file, seam, flag, symbol, or code path. Do not invoke for additive work, renames, or refactors that merely edit or deprecate code.

• Frontmatter — enforcement: advisory, phase: all, no model pin. It is implicit-required: /pipeline activates it inside an already-running build session.
• Engine step — none. plan and stories route removal-shaped authoring to it, tdd defers its removal doctrine to it, and /pipeline’s DISPATCH step sends a removal-shaped task to it in place of opening a RED cycle.
• Inputs — the obsolete file, seam, flag, symbol, or code path; the behavior that must survive; and the source, test, configuration, and documentation references that mention it.
• Outputs — the deletion diff, any pre-deletion characterization tests needed to cover a non-obvious survivor, and passing scoped survivor tests. The test_suite step owns full surviving-suite proof.
• Gate role — advisory. It forbids absence tests: deletion task evidence is the diff plus passing scoped survivor tests. It requires a survivor inventory for non-obvious survivors, triages touching tests as DIRECT or INCIDENTAL, and finishes with a literal reference sweep.

code-review

Use after implementing a task, before merging, or when requesting quality verification. Dispatches an evaluator agent with fresh context for calibrated, skeptical review.

• Frontmatter — enforcement: gating, phase: build, standalone: true, requires: [verify-claims], model: opus.
• Engine step — none. The pipeline evaluator satisfies this gate at batch boundaries. The engine’s build_review step is a separate, engine-native grader, not this skill.
• Inputs — git diff <batch-start-commit>..HEAD, scoped to the batch rather than the full branch; the story and acceptance criterion; the plan task; affected-test results; the tech-context review checklist.
• Outputs — no committed artifact. The evaluator emits an in-band structured verdict, persisted to .memory/patterns/ and .memory/gotchas/ at the memory checkpoint.
• Gate role — blocking in place, with no kickback file: a BLOCK verdict prevents merge and REQUEST_CHANGES must be addressed before re-review.
• Dispatches — agents/evaluator.md in a fresh context, and agents/domain-reviewer.md.

simplify

Use only at an active pipeline batch boundary after code has changed. Reviews current-batch duplication, complexity, and over-engineering; do not invoke for ordinary refactors, code review, or requests that merely ask for simpler prose or code.

• Frontmatter — enforcement: gating, phase: build, standalone: false, requires: [], model: sonnet.
• Engine step — none. It runs inside pipeline’s post-batch checks and from tdd’s batch-boundary refactor rule.
• Inputs — the batch diff by name; the batch-start commit; existing tests at the same production seam; ADRs that justify an abstraction; linter output.
• Outputs — .pipeline/audit-trail/batch-N-simplification.md.
• Gate role — blocking within the batch. CLEAN proceeds; SIMPLIFY_REQUIRED must be fixed before the next batch and counts against pipeline’s three-cycle rework budget.
• Declared replication is informed, not silenced — a declared replication’s mapped source/target pair alone is not flagged as an extract-with-parameters finding. Undeclared duplication, and similarity outside the declared target set, is still flagged, and the skill retains authority to propose extraction on a declared pair when rationale beyond the replication itself merits it.

debugging

Use only when the requested task is diagnosis of an observed bug, test failure, or unexpected behavior, or when active BUILD encounters one. Do not invoke for feature implementation, proactive review, or speculative troubleshooting without a concrete failure.

• Frontmatter — enforcement: gating, phase: build, standalone: true, requires: [verify-claims], model: opus.
• Engine step — none. Invoked on demand, and by manual-test in a fresh sub-session when a failure’s cause is not self-evident.
• Inputs — the full error and stack trace and logs; .memory/gotchas/ and .memory/patterns/; recent git history; the governing Status: APPROVED ADR or the relevant FR.
• Outputs — a failing reproduction test and the fix; entries in .memory/gotchas/ and .memory/patterns/. No .docs/ or .pipeline/ artifact.
• Gate role — neither in flow terms, with two hard in-skill rules: no fix proposals before the investigation completes, and a design-conformance stop — if the buggy path violates or is superseded by an approved decision, the output is a conformance finding, not a patch. Three failed fixes escalate to the operator.

test-suite has no SKILL.md: test_suite is an engine-native BUILD verifier that obtains a current result from the repository-configured aggregate verifier. build_review dispatches the engine-managed test-quality rubric skills; their raw verdicts are joined before effective dispositions are applied. test_suite runs after build and before build_review.

BUILD implementation and repair activities (including implementation agents, code-removal, tdd, and debugging) run scoped affected tests. If scope is uncertain, they record the trigger and defer aggregate proof to test_suite, rather than running an intermediate aggregate verifier.

Bootstrap inventories tests without executing them. Acceptance-spec RED runs select only the feature’s generated or copied specs. Progression checks, batch boundaries, and worktree merges consume existing evidence; only concrete changed behavior or interaction risk justifies targeted checks. Full-suite or aggregate runs, as configured, belong to test_suite. Batch evaluators and code-review inspect supplied results without routine reruns; targeted runs are reserved for reproducing a specific suspected defect. Known scoped failures still block BUILD. On an auto-mode suite-failure kickback, the engine supplies failure diagnostics and the .pipeline/test-suite-evidence.json path to BUILD; repair sessions use that evidence, verify affected tests, and commit before the engine reruns the aggregate gate. Scoped success alone never satisfies that gate.

SHIP-phase skills

manual-test

Use after /finish to validate stories via curl (API) or browser (full-stack). Bugs found loop back through /tdd.

• Frontmatter — enforcement: gating, phase: ship, standalone: false, requires: [finish, verify-claims], no model pin.
• Engine step — manual_test (index 16, SHIP, prerequisite test_suite, skipped at tier S). Checkpoint and loop gate, and the only step that opts into configDisableAllowed.
• Inputs — story acceptance criteria; the running application; the absolute worktree .pipeline path supplied in the step’s system prompt.
• Outputs — .pipeline/manual-test-results.md, written solely by ai-conductor manual-test-record, append-only as numbered attempt sections with per-criterion PASS, WARN, or FAIL results; .pipeline/manual-test-fail-evidence.json.
• Gate role — blocking. Only the latest attempt is evaluated. The skill must never hand-write or fabricate the results file — an absent marker is the correct refusal signal. A whitewash guard requires new commits after a recorded FAIL before a later FAIL-free attempt is accepted. Missing or unlaunchable browser automation dependencies are recorded as non-blocking WARN without installing them during SHIP; available API criteria continue through curl. An application mismatch observed after the browser launches remains a blocking FAIL.
• This repository — manual_test is disabled in .ai-conductor/config.yml. See self-hosting.

prd-audit

Use at SHIP, after manual-test and before rebase/finish. Audits the shipped implementation against the feature stories’ acceptance criteria, using PRD functional requirements as intent context when a PRD exists; produces graded, criterion-level findings and never implements or routes work itself.

• Frontmatter — enforcement: gating, phase: ship, standalone: true, requires: [verify-claims], model: opus.
• Engine step — prd_audit (index 17, SHIP, prerequisite manual_test). Loop gate; runs on every feature, at every tier and on both tracks — the skill does not infer a skip from tier, track, or the absence of a PRD.
• Inputs — the feature’s committed stories (the audit key) via the active plan’s **Stories:** reference; the active plan and any coherence mapping; the matching non-SUPERSEDED- PRD when present (context, not the key); the implementation, changed tests, and BUILD Scope: trailers; operator reseal and Scope: trailer rationales as immutable OVER_SCOPE intent evidence; .pipeline/accepted-widenings.json when present — durable operator authority, including immutable original evidence and case/offer references. The engine may apply that authority to later wording only after it records a fresh relation; the auditor does not preserve it by copying a summary.
• Outputs — .pipeline/prd-audit.md, overwritten each run; a code-stamp sidecar on the pass path.
• Gate role — blocking. Each finding carries exactly one grade — PASS, FIXABLE, PLAN_GAP, or OVER_SCOPE — and the report needs exactly one graded verdict row per acceptance criterion. A FIXABLE row must name its owning plan task. FIXABLE findings appends a bounded remediation lap (capped tasks, see configuration); exceeding the cap, needing a second lap, a happy-path PLAN_GAP, or a user-visible out-of-intent OVER_SCOPE halts for the operator. A negative-path or edge-scenario PLAN_GAP, and an OVER_SCOPE widening within intent or with no user-visible effect, are recorded in the verdict and the shipped record and the feature ships.
• Dispatches — agents/prd-auditor.md, one dispatch for the whole audit.

remediate

Use when a SHIP gate blocks — a prd-audit FIXABLE finding, an all-REMEDIABLE as-built architecture-review BLOCKED verdict, or finish verification — or on a build stall. Emits a per-gap disposition and concrete tasks routed to the owning step, and HALTs only for gaps that need a human.

• Frontmatter — enforcement: gating, phase: ship, standalone: true, requires: [verify-claims], no model pin.
• Engine step — remediate (out-of-band, SHIP, prerequisite prd_audit). Engine enforcement is advisory. Deliberately outside the sequential list so the loop never dispatches it unconditionally.
• Inputs — .pipeline/prd-audit.md, .pipeline/architecture-review-as-built.md, .pipeline/test-failures.md, and .pipeline/build-stall-question.md. A build_review FAIL no longer dispatches /remediate: it routes straight back to build with its own best-effort plan contract: and prior attempts: pointer lines (see gates).
• Outputs — .pipeline/remediation.json, overwritten each run and the only write in gap-plan mode. The SHIP verdict inputs are read-only: a finding judged resolved is recorded in remediation.json, never by editing, deleting, or recreating a verdict artifact. The engine then appends each task into the feature’s plan. For a prd_audit finding without a PRD, its disposition ID is the report criterion S<story>.<ordinal> (for example, S5.1); the engine admits criterion IDs case-insensitively. An existing-task disposition binds the gap to task id(s) already in the active plan instead: the engine re-stages those rows and kicks back to build without appending or spending plan-growth allowance (see gates). No completion glob — the engine reads the JSON directly to route.
• Gate role — advisory; it is the unblocker rather than a blocker. HALT is reserved for exactly three categories: architectural clarity, product scope, and unanswerable. Every other gap must route to build, acceptance_specs, architecture_review, or plan. On absent, stale, or malformed input the engine falls back to deterministic gap classification. The engine also HALTs, independent of category, when a build gap carries no concrete task outside a build-stall question — a taskless build disposition is not dispatchable work.
• Dispatches — agents/remediation-planner.md.

rebase

Resolve an in-progress paused rebase conflict, stage fixes, and drive git rebase –continue to completion; invoked by the conductor’s finish-time rebase step or by an operator running /rebase.

• Frontmatter — enforcement: advisory, phase: ship, standalone: true, requires: [], no model pin.
• Engine step — rebase (index 19, SHIP, prerequisite architecture_review_as_built). Engine enforcement is structural. The engine rebases natively and dispatches this skill only on conflict.
• Inputs — live git state only: status, the rebase-merge or rebase-apply path, the unmerged file list, and the conflicted files.
• Outputs — no file artifact. Its output is the contract: the last stdout JSON line, either {"resolved": true} or {"resolved": false, "reason": "..."}, parsed by the step runner. When an engine-dispatched mergeable sweep explicitly enables Sweep Test-Only Judgement, a successful result instead includes a verdict with choice, rationale, and superseded replay SHAs. That exception is unavailable to finish-time and re-kick rebase resolution.
• Gate role — blocking through the structural step. An unresolved result or an unsafe hunk retries up to a cap and then HALTs. Non-negotiable prohibitions: never --abort, never push --force, never invoke mid-build. --skip remains prohibited except for a declared-superseded replayed test-only commit while that sweep-only judgement mode is enabled.
• Replay verification — before editing, the skill captures the replay source commit’s and upstream’s intent as an evidence ledger, and HALTs at the first semantic ambiguity rather than guessing. Before git rebase --continue, it reviews the complete staged diff (not just the conflicted hunks) and requires every staged change to be attributable to the source or a necessary upstream adaptation. After git rebase --continue, it inspects the resulting replay commit against the retained pre-continue identity and validated intent, and only emits {"resolved": true} once every replay commit — including the final one — has reconciled.

finish

Author and then judge reader-facing PR prose at the engine-owned FINISH boundary after deterministic publication prerequisites pass.

• Frontmatter — enforcement: gating, phase: ship, standalone: true, requires: [], no model pin.
• Engine step — finish (index 21, SHIP, prerequisite rebase). Loop gate, gating, no tier skip. The production coordinator dispatches this skill for exactly two bounded retained-PR title/body passes, and picks between them deterministically from its own observation of the PR body: author_pr_prose when the body is still the engine-seeded placeholder, judge_pr_prose for the quality verdict on prose that exists. The judgment pass is therefore never handed an unauthored body.
• Inputs — the retained PR identity plus its observed title and body. The authoring pass additionally reads the feature branch’s full diff against its base and the feature’s spec, plan, and story artifacts. Deterministic BUILD, SHIP, release-readiness, push, shipped-record, and outcome evidence stays engine-owned.
• Outputs — a rewritten reader-facing PR title/body (authoring), or an accepted verdict or bounded repair (judgment). Neither is trusted on self-report: the coordinator re-reads the PR and a body that still classifies as a placeholder is a failed pass. The coordinator separately persists state.pr_url, commits .docs/shipped/<slug>.md, and writes .pipeline/finish-choice through ai-conductor finish-record after verification.
• Gate role — blocking. Missing or invalid deterministic evidence stops before this skill is dispatched. A placeholder body routes back to authoring; halt boilerplate and a refused judgment require a human. No prose defect commits the shipped record, so the halt stays re-dispatchable.
• Interaction — attended default and interactive foreground conduct asks the operator for PR, keep, or defer before any publication observation or mutation. Explicit foreground-auto and daemon modes use engine policy. No FINISH transition has PR merge or auto-merge authority.

pr

Use when creating or updating a pull request. Analyzes the full diff against the base branch, writes a concise title and structured body, and creates or updates the PR via gh.

• Frontmatter — enforcement: advisory, phase: ship, standalone: true, requires: [], no model pin.
• Engine step — none. Operator-invoked. finish does not call it: the Push & PR path inlines the same title/body contract and pre-push checks so the finish turn survives to write its completion record.
• Inputs — the branch log and diff against the base; .docs/specs/ and .docs/stories/; .pipeline/conduct-state.json; the project’s PR-title conventions.
• Outputs — the GitHub PR title and body, a pushed branch, and the PR URL. No repository file artifact.
• Gate role — neither, with one internal rule: finish owns completion verification. If no current pass exists, this skill stops and routes back rather than running the aggregate command itself.

Repository-local skills

These live under .agents/skills/ rather than skills/, declare only name and description, and apply to this repository. See self-hosting.

event-spine

Use BEFORE designing any new way to observe, report, or coordinate something in the ai-conductor repository — a watcher, a poller, a sidecar file, an ad-hoc log, a second telemetry path, or a timestamp stamped into an artifact to be read back later. Also use when adding a member to the ConductorEvent union, introducing a new .pipeline/*.jsonl ledger, deciding whether something ‘should be an event’, or reaching for a channel outside the bus because the bus looks inconvenient. Decides whether the existing spine (ConductorEventEmitter → ConductorEvent → EventPersister → .pipeline/events.jsonl) already carries the concern, applies the schema-not-file test, and names the only three exceptions that justify a separate write. Invoke it even when the new mechanism looks small, obviously correct, or too minor to count as telemetry — a parallel channel is cheap to prevent at design time and near-impossible to remove once consumers depend on it.

• Frontmatter — name and description only. No enforcement, phase, standalone, requires, or model.
• Engine step — none. Invoked at design time, before an approach is written down. Symlinked from .claude/skills/event-spine so both supported hosts discover the same file.
• Inputs — the design under consideration, plus the spine itself: the ConductorEvent union in src/conductor/src/types/events.ts, EventPersister, and .pipeline/events.jsonl.
• Outputs — a four-line verdict (channel?, occurrence versus durable state, extend/sibling/new channel, and which exception applies). No repository file artifact.
• Gate role — neither. Advisory, with no marker file and no HALT. Its rule is stated as a Design Principle in AGENT_INSTRUCTIONS.md, which points here and makes reading it mandatory before any such design; a genuinely new channel is escalated to an ADR rather than blocked by this skill.

maintain-documentation

Review and maintain this repository’s human-facing documentation. Use when this repository invokes its maintain-documentation custom step or explicitly requests documentation maintenance.

• Frontmatter — name and description only. No enforcement, phase, standalone, requires, or model.
• Engine step — a custom step wired in .ai-conductor/config.yml with after: rebase, enforcement: gating, and completion_artifact: .pipeline/maintain-documentation-pass. It inherits rebase’s loop-gate flag, landing between rebase and finish.
• Inputs — the current implementation change plus repository evidence. Its authority rule: code, tests, generated help, schemas, and observed behavior outrank .docs/, which is context only.
• Outputs — .pipeline/maintain-documentation-review.md, overwritten at the start of every invocation; .pipeline/maintain-documentation-pass, written only after a PASS verdict; documentation and changelog commits. .docs/ is read-only to it.
• Gate role — blocking. On BLOCKED the pass marker stays absent. Blocking conditions include unverifiable claims, unresolved contradictions in authoritative evidence, dangling-link removals, and changelog validation failures.

release-disposition

Judge this repository’s implementation diff and write its authoritative structured release disposition to the retained SHIP draft PR before finish.

• Frontmatter — name and description only. No enforcement, phase, standalone, requires, or model.
• Engine step — a custom step wired in .ai-conductor/config.yml with after: maintain-documentation, enforcement: gating, and completion_artifact: .pipeline/release-disposition-pass. It lands before finish and inherits the SHIP loop-gate behavior. It pins llm_provider: codex and model: gpt-5.6-terra: the step judges a diff and writes a short structured disposition, so the standard Codex tier is sufficient; its structured output is validated by the required CI check.
• Inputs — the implementation diff, the retained SHIP draft PR, and the migration-surface classifier. The diff decides the disposition; the PR body is the authority once written.
• Outputs — structured metadata written directly to the PR body plus .pipeline/release-disposition-review.md and the PASS-only .pipeline/release-disposition-pass evidence marker. finish preserves the metadata while writing reader-facing PR content.
• Gate role — blocking. It fails closed when the draft cannot be read or updated, metadata is invalid, or a required migration is not runnable.

scope-check

Use before authoring any change to the ai-conductor harness repository, and before creating any new skill, to decide three things deterministically: whether the change is harness-repo-only or consumer-facing, whether a new skill belongs in the shipped skills/ catalog or this repository’s local .agents/skills/ catalog, and whether the change is provider-agnostic. Produces a placement verdict and the registration steps that verdict requires.

• Frontmatter — name and description only. No enforcement, phase, standalone, requires, or model.
• Engine step — none. Operator-invoked, before authoring. Symlinked from .claude/skills/scope-check so both supported hosts discover the same file.
• Inputs — the change under consideration, plus this repository’s own boundaries: HARNESS.md versus AGENT_INSTRUCTIONS.md, the two skill catalogs, and the registration gates in test/test_harness_integrity.sh and test/test_provider_skill_contracts.sh.
• Outputs — three verdicts (audience, catalog, provider) plus the registration list the verdicts require. No repository file artifact. The verdicts are an input to the author’s decision, not the decision itself: AGENT_INSTRUCTIONS.md → Scope Decisions requires a conflict between a verdict and the operator’s plain request to be surfaced before landing.
• Gate role — neither. Advisory, with no marker file and no HALT. Its value is that the registration cost of the two catalogs differs sharply: a skills/ addition must satisfy integrity checks 2, 4, 5, 5a, and 5b plus the provider contract audit and installs globally, while an .agents/skills/ addition is outside all of them.

write-tests

Use whenever adding, changing, reviewing, or debugging tests in the ai-conductor repository. Defines repository-specific test scope, isolation, mocking, fixture, performance, and CI-parity rules that prevent cyclic Conductor runs, leaked workers, real third-party calls, and slow aggregate suites. Complements the provider-neutral tdd skill, which controls implementation order rather than test design.

• Frontmatter — name and description only. It is the only skill in the repository with no enforcement field.
• Engine step — none. It is unwired: no step definition, no custom config step, no engine reference.
• Inputs — the test under authorship plus repository conventions.
• Outputs — none. It produces test files and prescribes commands.
• Gate role — neither. No verdict, no marker file, no downstream HALT. Its rules are stated as MUST and never, and the repository’s contributor instructions make it mandatory reading. See testing.

Agent personas

16 persona files live under agents/. A persona is a prompt template defining who does the work; a skill decides when to dispatch one and with what scoped context. Dispatch is by the host agent’s subagent facility, not by the engine — the engine dispatches skills, and skills dispatch personas.

Persona	Role	Dispatched by
generator.md	Writes tests (RED) and code (GREEN) under strict TDD in an isolated, focused context	tdd, pipeline
evaluator.md	Fresh-context quality evaluator over a scoped batch diff, with no shared state with the generator	pipeline at batch boundaries, code-review
domain-reviewer.md	Domain integrity reviewer with veto authority over tests and implementations	tdd at both DOMAIN phases, code-review
prd-auditor.md	Audits one FR-N against shipped code; finding authority, never fixes	prd-audit
remediation-planner.md	Emits per-gap dispositions and concrete tasks; planning authority, never edits code	remediate
worktree-manager.md	Git worktree lifecycle: creation, environment setup, merge-back, conflict resolution, proof-gated cleanup	pipeline
cto-security.md	Authn/authz, input validation, OWASP top 10, vulnerability surface	assess
cto-data-integrity.md	Transactions, event sourcing, race conditions, migrations	assess
cto-dependencies.md	Outdated packages, CVEs, license compliance, blocked upgrades	assess
cto-architecture.md	Decisions versus implementation, module consistency, coupling	assess
cto-duplication.md	Boilerplate and copy-paste clusters with blast-radius measurement	assess
cto-testing.md	Coverage gaps, layer balance, assertion quality, missing negatives	assess
cto-infrastructure.md	Connection pooling, caching, background jobs, production parity, secrets	assess
cto-observability.md	Error handling, logging quality, monitoring, debug context	assess
cto-devex.md	Onboarding, CI/CD, local development, documentation accuracy	assess
cto-orchestrator.md	Reads all nine specialist reports and produces one prioritized assessment	assess

assess therefore dispatches ten personas: the nine specialists plus the orchestrator.

Known limitations

The frontmatter is not always the truth. Where a skill’s declared enforcement disagrees with its engine step definition, the engine wins — isGatingStep and canSkipStep read the step definition, never the SKILL.md.

Known limitation. Six skills’ enforcement: frontmatter disagrees with the engine’s step definition. A reader who trusts the frontmatter will predict the wrong skippability.

Skill	SKILL.md enforcement	Engine step enforcement
memory	gating	advisory
assess	gating	advisory
architecture-diagram	gating	advisory
architecture-review	gating	advisory (the DECIDE step)
remediate	gating	advisory
rebase	advisory	structural

The sharpest case is architecture-review: the SKILL.md declares a HARD GATE — no feature proceeds past it with DRAFT ADRs — but the DECIDE-phase step is advisory, so canSkipStep('architecture_review') returns true. The real enforcement for that half lives in the land-time spec gate and in conduct’s DRAFT-ADR block, not in the step’s enforcement level. The as-built half at index 18 is genuinely gating and fail-closed. Tracked in #1018.

Known limitation. manual-test/SKILL.md declares requires: [finish, verify-claims] and its description says “Use after /finish”. The engine runs manual_test at index 16 with prerequisite test_suite, and finish at index 21 with prerequisite rebase. finish is not a prerequisite of manual_test in any code path — the declared dependency is inverted relative to execution order. Follow the engine order. Tracked in #1018.

Known limitation. conduct/SKILL.md’s tier table claims that tier S skips pipeline (“use direct /tdd”) and code-review (“domain review in TDD suffices”). Neither is implemented. build declares skippableForTiers: [] and is structural, so it can be neither tier-skipped nor config-disabled; code-review is not an engine step at all, and the engine’s separate build_review step is likewise never tier-skipped. The same file’s “Small flow” summary also omits complexity, worktree, build_review, test_suite, and rebase, all of which run at tier S. The authoritative tier-S skip set is the 8 steps listed in steps. Tracked in #1018.

Related pages

• steps — step order, enforcement, tier and track skips, gate behavior.
• models — how a model: pin resolves against engine defaults.
• artifacts — every artifact and state file these skills read and write.
• gates — what a gate is and why it fails closed.
• extending — adding a skill, step, gate, or hook.