Menü
Discover, approve, implement, prove, review, and record a software change.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Turn a repetitive manual procedure into a proven, repeatable mechanism. Use when the user explicitly invokes the automation pipeline.
Plan, approve, implement, verify, and record a software change. Use when the user explicitly invokes the build pipeline.
Record a durable architecture decision with alternatives and consequences.
Discover, approve, implement, prove, review, and record a software change. Use when the user explicitly invokes the delivery pipeline.
Leave unfinished repository work safe for another human or agent to resume.
Evaluate whether retained evidence supports the delivery claims being made.
| name | delivery |
| description | Discover, approve, implement, prove, review, and record a software change. |
| disable-model-invocation | true |
| argument-hint | <task> |
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.
Task: $ARGUMENTS
Record harness as claude in the run ledger.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Run base verify delivery-foundation --run <run-slug>. A fail or inconclusive verdict is not passing evidence and must be reported before proceeding.
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.
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.
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.
