| name | delivery |
| description | Discover, approve, implement, prove, review, and record a software change. Use when the user explicitly invokes the delivery pipeline. |
Delivery pipeline
Use for consequential repository work that must survive handoffs and preserve an evidence trail.
The attached delivery-foundation suite proves Base composition and generated-surface integrity.
The project must also define and run the behavior-specific verifier suite named in the plan; a
verifier is an executable contract, not a prose checklist.
Use the task supplied alongside this explicitly invoked skill.
Record the actual runtime, codex or copilot, as harness in the run ledger.
1. Delivery Discover
Run base state context, inspect repository guidance and the owning code, and bound the requested
outcome. Before any gate or implementation, atomically create
.base/runs/YYYY-MM-DD-<short-kebab-slug>/; if it already exists, retry with the next numeric
suffix (-2, -3, and so on). Reserve its empty evidence/ directory. Record assumptions,
constraints, acceptance checks, and unresolved proof obligations in that run's task.md. Use this
same run slug for every later base approve and base verify --run command.
Assigned agent: delivery-analyst
Delegate this stage to the repository agent delivery-analyst when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.
2. Delivery Plan
Write the run plan.md. Name owned files or components, behavior changes, the project verifier
suite, migration and compatibility risks, and evidence to retain. Identify the strongest viable
alternative and why it is not selected.
Assigned agent: delivery-analyst
Delegate this stage to the repository agent delivery-analyst when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.
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. Delivery Implement
Make the smallest cohesive implementation that satisfies the plan. Preserve unrelated work and
approved contracts. Update focused tests and documentation with the behavior they govern.
Assigned agent: delivery-implementer
Delegate this stage to the repository agent delivery-implementer when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.
4. Delivery Prove
Run the behavior-specific project verifier named in the approved plan with
base verify <suite> --run <run-slug>. The pipeline also attaches the generic
delivery-foundation verifier for Base composition and generated-surface integrity. Classify each
check as pass, fail, or inconclusive. Record unavailable infrastructure and external gates
separately from local proof; do not collapse them into a pass.
Assigned agent: delivery-implementer
Delegate this stage to the repository agent delivery-implementer when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.
Verifier: delivery-foundation
Run base verify delivery-foundation --run <run-slug>. A fail or inconclusive verdict is not passing evidence and must be reported before proceeding.
5. Delivery Review
Review the diff, acceptance checks, retained evidence, upgrade and rollback behavior, and target
adapter fidelity. State any residual risk or unverified claim. Update the durable handoff if safe
work remains.
Assigned agent: delivery-auditor
Run this stage in a distinct delivery-auditor agent context that did not implement the change. If this target cannot provide separate agent execution, report the review as assisted and do not claim independent maker/checker separation.
6. 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.
