From kiln
Orchestrates Kiln's 7-step autonomous software creation pipeline: onboarding, brainstorm, research, architecture, iterative build, validation, report. Activates on /kiln-fire.
npx claudepluginhub fredasterehub/kiln --plugin kilnThis skill is limited to using the following tools:
Orchestrate the full Kiln software creation pipeline. This skill is the conductor — it manages state, sequences steps, spawns pre-defined agent teams, handles Build looping and Validate correction cycles.
data/agents.jsondata/brainstorming-techniques.jsondata/elicitation-methods.jsondata/lore.jsondata/spinner-verbs.jsonreferences/artifact-flow.mdreferences/blueprints/step-1-onboarding.mdreferences/blueprints/step-2-brainstorm.mdreferences/blueprints/step-3-research.mdreferences/blueprints/step-4-architecture.mdreferences/blueprints/step-5-build.mdreferences/blueprints/step-6-validate.mdreferences/blueprints/step-7-report.mdreferences/brand.mdreferences/design/design-patterns.mdreferences/design/design-qa.mdreferences/design/design-review.mdreferences/design/design-system.mdreferences/design/jit-brief-template.mdreferences/design/standing-contract-template.mdOrchestrates adversarial plan-implement-review pipeline by spawning role-specific agents with separate contexts. Run after /brainstorm, /repo-eval, /repo-health, or /doc-health.
Orchestrates development pipelines by classifying tasks, selecting skills and order, adapting to context, ensuring critical steps, and tracking progress. Use for new tasks or pipeline transitions.
Deploys iterative swarms of AI agent teams to autonomously build full projects from holistic descriptions. Requires CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.
Share bugs, ideas, or general feedback.
Orchestrate the full Kiln software creation pipeline. This skill is the conductor — it manages state, sequences steps, spawns pre-defined agent teams, handles Build looping and Validate correction cycles.
Environment scaffolding (git init, .kiln/ structure, hook-gated seed files) runs in the engine between the ignition banner and alpha's spawn. Alpha handles the conversation: working directory, project name, description, preferences.
Codex CLI canonical invocation (all agents that call Codex must use this exact pattern):
codex exec --sandbox danger-full-access -C "{working_dir}" < /tmp/kiln_prompt.md
Prompt file creation: Create prompt files via Bash heredoc (cat <<'EOF' > /tmp/kiln_prompt.md), not the Write tool. Write requires a prior Read on the file path, which fails on new files and wastes a tool call.
7 steps, executed sequentially. Each step = a team of pre-defined agents.
Read ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/lore-engine.md for the full presentation protocol (banners, transitions, event-to-lore-key mapping, spinner install).
Read ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/brand.md for visual vocabulary and brand tokens.
Read .kiln/STATE.md to determine pipeline state. If it doesn't exist, start from step 1.
STATE.md fields:
skill: absolute path to this skill file under the active plugin root. On resume, use the stored path if it is readable; otherwise recover to ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/SKILL.mdroster: absolute path to current step's blueprint under the active plugin root. On resume, use the stored path if it is readable; otherwise recover from stage using the deterministic blueprint map belowstage: current step name (onboarding, brainstorm, research, architecture, build, validate, report, complete)build_iteration: current Build iteration countmilestone_count: total milestones from Architecturemilestones_complete: completed milestone countcorrection_cycle: Validate->Build correction count (max 3)run_id: pipeline run identifierpath: working directory pathstarted: run start dateupdated: last state update datestep_N_start: ISO 8601 timestamp when step N began (written at each step transition)step_N_end: ISO 8601 timestamp when step N completed (written when step signals done)Deterministic blueprint map for recovery:
onboarding -> ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/blueprints/step-1-onboarding.mdbrainstorm -> ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/blueprints/step-2-brainstorm.mdresearch -> ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/blueprints/step-3-research.mdarchitecture -> ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/blueprints/step-4-architecture.mdbuild -> ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/blueprints/step-5-build.mdvalidate -> ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/blueprints/step-6-validate.mdreport -> ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/blueprints/step-7-report.mdOn resume:
.kiln/STATE.md and extract stage, skill, and roster.stage is missing or not one of onboarding, brainstorm, research, architecture, build, validate, report, complete, fail with: Kiln resume failed: .kiln/STATE.md is missing a valid stage. Expected one of onboarding, brainstorm, research, architecture, build, validate, report, complete. Fix .kiln/STATE.md or remove it to start fresh.skill: prefer the stored path when it is readable; otherwise recover to ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/SKILL.md.skill path is still unreadable, fail with: Kiln resume failed: the stored skill path is stale or missing, and the active kiln-pipeline skill was not found at ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/SKILL.md. Reinstall or repair the Kiln plugin, then retry /kiln-fire.stage: complete, inform the operator the pipeline already finished. Do not fail because of a stale roster path when no blueprint read is needed.roster: prefer the stored path when it is readable; otherwise recover from the deterministic blueprint map for the current stage.roster path is unreadable, fail with: Kiln resume failed: the stored roster path is stale or missing, and no active blueprint was found for stage '{stage}' at the expected Kiln plugin path. Verify the plugin install at ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/blueprints/ and retry /kiln-fire.skill or roster was recovered, rewrite .kiln/STATE.md immediately so it stores the recovered active-plugin-root paths and refresh updated with the current UTC timestamp before continuing.stage. Stage maps directly to step number — onboarding = 1, brainstorm = 2, research = 3, architecture = 4, build = 5, validate = 6, report = 7.For each step, follow this exact pattern. No shortcuts, no improvising.
Version check (resume only — fresh runs have no baseline to compare against): On resume, compare the active plugin version against the version recorded in STATE.md at onboarding:
PLUGIN_VERSION=$(cat ${CLAUDE_PLUGIN_ROOT}/.claude-plugin/plugin.json | jq -r '.version')
STATE_VERSION=$(grep -oP '(?<=\*\*plugin_version\*\*: )\S+' .kiln/STATE.md 2>/dev/null || echo "")
If $STATE_VERSION is non-empty and differs from $PLUGIN_VERSION, emit a loud warning:
⚠️ PLUGIN VERSION CHANGED
Onboarding: {STATE_VERSION} | Current: {PLUGIN_VERSION}
If you updated the plugin intentionally, this is expected.
If not, run `/plugin update` to get the latest version.
Then update STATE.md with the current version so the warning doesn't repeat. Continue the pipeline — do not halt.
Cache health check: Handled automatically by check-cache.sh SessionStart hook. No engine action needed.
On fresh run (no .kiln/STATE.md), before step 1:
.kiln/STATE.md (confirm missing) + lore.json (select ignition quote) in parallel.settings.local.json, run scaffolding:
if [ ! -d .git ]; then git init && git add -A && git commit -m "kiln: project initialized"; fi
mkdir -p .kiln/docs .kiln/docs/research .kiln/plans .kiln/archive .kiln/archive/step-3-research .kiln/archive/step-4-architecture .kiln/archive/step-5-build .kiln/archive/step-6-validate .kiln/validation .kiln/tmp .kiln/design
echo '<!-- status: writing -->' > .kiln/docs/architecture.md
echo '<!-- status: writing -->' > .kiln/docs/codebase-state.md
echo '<!-- status: writing -->' > .kiln/docs/patterns.md
timeout 15 codex exec --sandbox danger-full-access "echo kiln-preflight-ok" 2>/dev/null && echo "codex:true" || echo "codex:false"
Capture codex result for STATE.md (codex:true → codex_available: true).On resume (.kiln/STATE.md exists with stage != complete):
.kiln/STATE.md + .kiln/resume.md + lore.json in parallel.skill/roster when readable; recover from active plugin root if stale. Read resolved blueprint + write spinner verbs in parallel. If either path was recovered, update .kiln/STATE.md. Fail only when stage is invalid or the active plugin file is missing.Read the blueprint for the current step:
${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/blueprints/step-{N}-{name}.md — three-phase agent roster, communication model, spawn order.The blueprint tells you WHO to spawn and in which PHASE. The agent .md files (loaded via subagent_type) tell each agent WHAT to do. Step definitions and signal vocabulary are in ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/team-protocol.md (§ Step Definitions).
(Step 1's blueprint is read during Pipeline Start.)
Before creating the team, render the step's transition. Visual vocabulary from lore-engine.md and brand.md on transitions, exact formats in § Engine Banners. Two parts:
settings.local.json via Bash heredoc to install spinner verbs, then output the transition banner as markdown text. For Build iterations, output the kill streak banner format instead of the standard transition.No extra narration around the banner. The banner text IS the presentation. Any surrounding summary should add new information, not repeat the banner.
Then:
TeamCreate(team_name="{run_id}-{step_name}", description="Kiln {step_name}")
You are the conductor — you spawn agents and wait for signals. You never perform step work yourself. Never create .kiln/, STATE.md, or any pipeline artifact yourself. Never skip spawning.
Follow ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/team-protocol.md § "Three-Phase Spawn" exactly. The engine-specific additions are:
During a milestone, KRS-One may request fresh workers between iterations via CYCLE_WORKERS instead of REQUEST_WORKERS. This replaces the current builder+reviewer pair without tearing down the team — persistent minds (rakim, sentinel, thoth) and KRS-One stay alive throughout the milestone.
CYCLE_WORKERS payload format:
CYCLE_WORKERS: scenario={default|fallback|ui}, reason="{why cycling}", chunk="{chunk summary}"
Engine protocol on receiving CYCLE_WORKERS:
Validate scenario — map to builder+reviewer pair:
| Scenario | Builder | Reviewer |
|---|---|---|
| default | codex | sphinx |
| fallback | kaneda | sphinx |
| ui | clair | obscur |
If the scenario is unrecognized, reject:
SendMessage(type: "message", recipient: "krs-one", content: "CYCLE_REJECTED: Unknown scenario '{scenario}'. Valid scenarios: default, fallback, ui.")
Shutdown current workers — send shutdown_request to the current builder and reviewer (if any exist). Wait for shutdown_response or teammate_terminated from both (60s timeout). Force-terminate on timeout. Do NOT shut down persistent minds or KRS-One.
Spawn fresh pair — spawn the new builder+reviewer on the existing team using the same validation rules as Phase C. Use canonical type names (name: "codex", not cosmetic names). Each fresh worker starts with a clean context — this is the point of cycling.
Confirm to KRS-One — send WORKERS_SPAWNED with the new agent names:
SendMessage(
type: "message",
recipient: "krs-one",
content: "WORKERS_SPAWNED: {builder_name} (subagent_type: {builder_type}), {reviewer_name} (subagent_type: {reviewer_type}). Fresh context, awaiting assignment."
)
Update progress beat — output a one-line progress beat for the operator:
◆ Cycling workers — {reason}. Spawning {builder_name}+{reviewer_name} ({scenario})...
CYCLE_WORKERS vs REQUEST_WORKERS: REQUEST_WORKERS is the initial Phase C spawn at the start of build. CYCLE_WORKERS is the mid-milestone replacement that shuts down existing workers first. Both use the same scenario validation table. The key difference: CYCLE_WORKERS always sends shutdown_request to existing workers before spawning, and it is initiated by KRS-One (not as a response to an initial team setup).
For every agent, use ALL of these parameters:
Agent(
name: "{agent_name}", # from blueprint roster — EXACT name, no prefix
description: "{personality}", # random quote from agents.json — vary each spawn
team_name: "{team_name}", # the team from step 2 — REQUIRED
subagent_type: "{agent_name}", # matches the .md file in agents/
prompt: "<lean runtime prompt>",
run_in_background: true/false, # interactive steps (1,2,4): boss=false; background steps (3,5,6,7): true
)
Naming: The name parameter controls what the operator sees in the UI header for every agent spawn. It should read like a character entering the scene — just their name and personality quote. Adding prefixes, namespaces, or team identifiers to name pollutes the operator's view with plumbing they don't need. The blueprint roster has the exact names — use them as-is.
Every parameter is required. Without team_name, agents spawn as isolated subagents — no SendMessage, no shutdown, no team pattern.
Bootstrap plumbing is invisible — batch prerequisite reads in parallel, output the banner as the first visible text. Interactive steps (1, 2, 4): banner → spawning indicator → spawn boss in foreground → operator greeting (text in lore-engine.md) → engine goes silent. Background steps (3, 5, 6, 7): banner → one-line progress beats at each phase transition surfacing real information from READY signals.
The engine waits for the boss's completion signal. Messages from the team arrive automatically. Do not read files, create tasks, or intervene.
INTERACTIVE steps (Steps 1, 2, 4) — HANDS OFF. The boss talks to the human. Wait silently and indefinitely — never nudge, re-spawn, take over, or assume the boss is stuck.
Non-interactive steps (Steps 3, 5, 6, 7) — Watchdog Protocol:
Every idle_notification is a health check opportunity. Do NOT waste it on poetry. On each idle notification:
in_progress task? What signal are you waiting for?{signal}, received {what_they_sent}. Please resend in the correct format."Stagnation rule: If the current in_progress task has not changed across 3 consecutive idle notifications, the pipeline is stalled. Report the stall clearly to the operator with the task name, the agent you're waiting on, and the last message received from that agent. Then STOP — do not loop.
Idle voice (fallback only): If the health check finds everything normal (agent is actively working, just slow), THEN output a brief lore-flavored one-liner. But health check comes first — every time.
shutdown_request to each agent individually, in parallel. Do not use broadcast — shutdown is an orderly per-agent protocol, not an announcement.shutdown_request. An agent is cleared from the wait set when EITHER:
shutdown_response (confirmation), ORteammate_terminated event is observed for that agent (system already killed it).
Wait until ALL agents are cleared. If any agent has neither confirmed nor terminated after 60 seconds, treat it as terminated and proceed — do not wait indefinitely.Based on the boss's done signal, determine next action:
Step 1 done -> validate onboarding artifacts BEFORE shutdown (Alpha is still alive):
.kiln/STATE.md via Bash: verify ## Flags section exists and contains codex_available AND arch_review.kiln/resume.md exists
If validation fails: send error to Alpha describing what is missing, wait for Alpha to fix and re-signal ONBOARDING_COMPLETE. Do NOT shut down the team yet.
If validation passes: proceed to shutdown and transition to step 2.
Step 1 blocked (ONBOARDING_BLOCKED) -> render halt banner, inform operator of the blocker details, stop pipeline
Step 2 done (BRAINSTORM_COMPLETE) -> verify .kiln/docs/VISION.md exists and is non-empty before proceeding to step 3. If missing, wait up to 30s (check every 5s), then nudge the vision curator if still missing.
Step 3 done (RESEARCH_COMPLETE) -> proceed to step 4
Step 4 done (ARCHITECTURE_COMPLETE) -> proceed to step 5
Step 4 blocked (PLAN_BLOCKED) -> render halt banner, inform operator, stop pipeline
Step 5 signals:build_iteration in STATE.md.phase_complete banner, increment build_iteration in STATE.md. This signal carries no scenario information, so wait for KRS-One's next CYCLE_WORKERS to determine the scenario. Loop back to wait.milestone_complete banner. Increment milestones_complete in STATE.md.<!-- status: complete --> in their owned files (codebase-state.md, patterns.md). If any missing, wait 30s and re-check (max 3 times), then proceed with warning.shutdown_request to ALL agents (PMs, KRS-One, any remaining workers). Wait for responses (60s timeout, force-terminate on timeout).milestones_complete < milestone_count:
a. Create new team (TeamCreate with next kill-streak name).
b. Re-spawn persistent minds (rakim, sentinel, thoth) — fresh context, they read their files on bootstrap.
c. Re-spawn krs-one with updated milestone context.
d. Wait for READY from PMs, then resume build loop.phases_complete banner, proceed to step 6
Step 6 signals:validation_passed banner, proceed to step 7validation_failed banner, check correction_cycle:
correction_start banner, increment correction_cycle in STATE.md, loop back to step 5. Correction dispatch follows the same structure as a normal Build iteration — KRS-One bootstraps persistent minds, reads the correction report at .kiln/validation/report.md, scopes a targeted fix, dispatches to a builder. Do NOT inline the correction tasks or give KRS-One a vague "execute this." He scopes and delegates like any other iteration.halt banner, escalate to operator, stop pipeline
Step 7 done (REPORT_COMPLETE) -> render project_complete banner, pipeline completeWhen writing STATE.md at step transitions, always include the skill and roster bootstrap paths from the active plugin root. Set skill to ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/SKILL.md and set roster to the next step's blueprint path under ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/blueprints/. Never preserve a stale cache or previous install path when writing new state. These fields enable cold-start resume after session breaks.
Step timing: At the start of each step, write step_N_start: {ISO 8601 timestamp} to STATE.md. When the step signals done, write step_N_end: {ISO 8601 timestamp}. Use date -u +%Y-%m-%dT%H:%M:%SZ via Bash for consistent formatting. Omega uses these timestamps to build the pipeline timing table in REPORT.md.
Gate log: gate-log.md is optional. If alpha seeded it during onboarding, the engine may append a one-line entry at step transitions. Do not let gate-log writes block or delay the transition flow.
When KRS-One sends MILESTONE_QA_READY: {milestone_name}, the engine orchestrates independent dual-model QA via three dedicated agents (maat, anubis, osiris). KRS-One blocks on QA_VERDICT (300s timeout).
Engine protocol on receiving MILESTONE_QA_READY:
Pre-package PM context for anubis — Read the TL;DR headers from rakim's .kiln/docs/codebase-state.md and sentinel's .kiln/docs/patterns.md (first 30 lines of each). Anubis is a thin Codex CLI wrapper that does NOT consult PMs directly — the engine pre-packages this context into its runtime prompt.
Spawn maat + anubis (parallel, background):
Agent(name: "maat", subagent_type: "kiln:maat", team_name: "{team_name}",
run_in_background: true,
prompt: "You are 'maat' on team '{team_name}'. Step 5: Build — Milestone QA.
Milestone under review: {milestone_name}.
Working dir: {working_dir}. Master plan: .kiln/master-plan.md.
{protocol_injection_full}
Run your QA analysis. Consult rakim and sentinel as needed.")
Agent(name: "anubis", subagent_type: "kiln:anubis", team_name: "{team_name}",
run_in_background: true,
prompt: "You are 'anubis' on team '{team_name}'. Step 5: Build — Milestone QA.
Milestone under review: {milestone_name}.
Working dir: {working_dir}. Master plan: .kiln/master-plan.md.
Codebase state summary:\n{rakim_tldr}
Patterns summary:\n{sentinel_tldr}
{protocol_injection_worker}
Construct your QA prompt for GPT-5.4 and invoke codex exec.")
Wait for TWO distinct QA_REPORT_READY signals — create two separate wait tasks:
Spawn osiris (background) after both reports are ready:
Agent(name: "osiris", subagent_type: "kiln:osiris", team_name: "{team_name}",
run_in_background: true,
prompt: "You are 'osiris' on team '{team_name}'. Step 5: Build — Milestone QA Synthesis.
Milestone: {milestone_name}. Working dir: {working_dir}.
Two QA reports are ready: .kiln/tmp/qa-maat-report.md and .kiln/tmp/qa-anubis-report.md.
{protocol_injection_full}
Read both reports, synthesize, and signal QA_PASS or QA_FAIL.")
Wait for QA_PASS or QA_FAIL from osiris — single wait task. 300s timeout.
Shutdown QA agents — send shutdown_request to maat, anubis, and osiris. Wait for confirmations (60s timeout). Force-terminate on timeout.
Relay verdict to KRS-One:
SendMessage(type: "message", recipient: "krs-one",
content: "QA_VERDICT: {PASS or FAIL}. {osiris's findings summary}")
Return to signal wait loop — do NOT transition steps. KRS-One decides next action (MILESTONE_COMPLETE on PASS, re-scope on FAIL).
Every agent spawn MUST include a role-appropriate protocol block in its runtime prompt. This is Layer 2 enforcement (Layer 1 = agent.md bootstrap Read, Layer 3 = enforce-pipeline.sh hook).
Full protocol — for bosses, persistent minds, QA agents (maat, osiris, aristotle, krs-one, rakim, sentinel, etc.):
## Kiln Protocol (Runtime)
- SendMessage is the ONLY way to reach teammates. Plain text is invisible to agents.
- After sending a message expecting a reply, STOP your turn. Never sleep-poll.
- One message per wake-up. Process it fully before acting.
- Signal format: SendMessage(type:"message", recipient:"team-lead", content:"SIGNAL_NAME: context")
- On shutdown_request: approve immediately — SendMessage(type:"shutdown_response", request_id:"{id}", approve:true). No delay, no summary.
- Consult persistent minds when uncertain: rakim (codebase state), sentinel (patterns).
- Consultation: send question → STOP → wait for reply → continue. Use sparingly.
- Chunk scope is immutable after dispatch. New info goes in the next assignment.
- NEVER read/write: .env, *.pem, *_rsa, *.key, credentials.json, secrets.*, .npmrc
Worker protocol — for builders, reviewers (codex, kaneda, clair, sphinx, obscur, anubis):
## Kiln Protocol (Runtime)
- SendMessage is the ONLY way to reach teammates. Plain text is invisible to agents.
- After sending a message expecting a reply, STOP your turn. Never sleep-poll.
- One message per wake-up. Process it fully before acting.
- Signal format: SendMessage(type:"message", recipient:"{name}", content:"{SIGNAL}: {context}")
- On shutdown_request: approve immediately — SendMessage(type:"shutdown_response", request_id:"{id}", approve:true). No delay, no summary.
- Consult persistent minds when uncertain: rakim (codebase state), sentinel (patterns). Send question → STOP → wait → continue.
- NEVER read/write: .env, *.pem, *_rsa, *.key, credentials.json, secrets.*, .npmrc
Fire-and-forget protocol — for thoth:
## Kiln Protocol (Runtime)
- SendMessage is the ONLY way to reach teammates. Plain text is invisible to agents.
- One message per wake-up. Process it fully before acting.
- On shutdown_request: approve immediately — SendMessage(type:"shutdown_response", request_id:"{id}", approve:true). No delay, no summary.
- NEVER read/write: .env, *.pem, *_rsa, *.key, credentials.json, secrets.*, .npmrc
Select the variant matching the agent's role. Include it verbatim in the prompt parameter — do not summarize or abbreviate.
At each step transition, create a private TaskCreate chain for the current step. Use blockedBy so every task is either a Spawn ... action or a Wait for ... action, and the chain advances strictly in order.
On every turn, check TaskList and find the current in_progress task. If it is a Wait for X task, scan ALL received teammate messages for signal X. Process EVERY teammate-message block in the input; do not stop after the first match. If the signal is found, mark the task complete and immediately continue to the next unblocked task. If not found, STOP and wait for more messages.
After receiving any teammate message, check TaskList first to identify your current in_progress task. Match the incoming message against the expected signal. Then act on the result.
Malformed signal recovery: If a teammate message does NOT match the expected signal but DOES contain a recognizable intent (e.g. READY when you expected REQUEST_WORKERS, or a signal with wrong casing, or a signal buried in prose), do NOT silently ignore it. Send a corrective reply: "I received your message but expected signal {expected}. You sent {what_they_sent}. Please resend as exactly: {expected}: {format}." This prevents the deadlock where both sides think they communicated correctly.
Use the exact signal names from ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/team-protocol.md (§ Signal Vocabulary). Rebuild the tasklist at every step transition; Build iterations also rebuild the full chain. The tasklist is engine-only: agents never touch it and use SendMessage only. When transitioning between steps, delete all previous tasks (TaskUpdate status: deleted) before creating the new step's chain.
Read the current step's blueprint for the step-specific spawn/wait sequence. Each blueprint defines the Phase A/B/C roster, the signals to wait for, and any conditional branches (e.g. brownfield scout requests in step 1, argus→hephaestus branch in step 6). The blueprint is the authoritative task chain for that step.
Read ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/kill-streaks.md for Build step team naming (required at every Build step entry). The kill streak announcement is rendered as part of step 2 (Render Transition and Create Team) — bold orange banner with the streak name in ALL CAPS.
Before each step, verify required input artifacts exist (see ${CLAUDE_PLUGIN_ROOT}/skills/kiln-pipeline/references/artifact-flow.md). If critical artifacts are missing, inform the operator rather than proceeding blind.