build

name	build
description	Plan, approve, implement, verify, and record a software change. Use when the user explicitly invokes the build pipeline.

Build pipeline

Use this pipeline for repository changes that should leave an auditable plan, result, and history entry. Treat the user's invocation text as the task; do not invent a separate objective.

Use the task supplied alongside this explicitly invoked skill. Record the actual runtime, codex or copilot, as harness in the run ledger.

1. Intake

Clarify the requested outcome from available context. Inspect the repository before asking questions that the files can answer. Create the run folder and write task.md containing the outcome, constraints, assumptions, and acceptance checks. Reserve an empty evidence/ folder.

2. Plan

Write plan.md in the run folder. Name the files or components to change, the intended behavior, the verification commands, and material risks. Keep the plan executable by another capable agent.

Gate: plan-approval

STOP after completing this stage. Do not execute until the user explicitly approves the written plan. Request the verdict by writing approvals/plan-approval.md.request in the run folder describing what needs approval, then stop. The verdict is recorded from outside the session: base approve <run-slug> plan-approval (or --deny) writes approvals/plan-approval.md — a standing directive counts only when recorded that way, with --note citing it. Never create the verdict artifact yourself. If the recorded verdict is denied, skip to record with outcome aborted.

3. Execute

Implement the approved plan without widening scope. Run the planned checks and capture a concise result.md with changed paths, verification results, and any remaining limitations. Put durable proof files under evidence/ when useful.

4. Verify

Run the acceptance checks named in task.md and the approved plan. Capture the commands and their real output as files under evidence/; reference them from result.md with a pass or fail verdict per check. A failing check means the run is not completed — fix it or record the honest outcome. Never substitute a claim for a captured result.

Verifier: base

Run base verify base --run <run-slug>. A fail or inconclusive verdict is not passing evidence and must be reported before proceeding.

5. Record

Always run this stage, including after rejection, failure, or abort. Append exactly one compact JSON object line to .base/history.jsonl with slug, date, pipeline, harness, outcome, and paths. Use completed, aborted, or failed for outcome; never rewrite previous lines.