| name | automation |
| description | Turn a repetitive manual procedure into a proven, repeatable mechanism. Use when the user explicitly invokes the automation pipeline. |
Automation pipeline
Use this pipeline when the deliverable is a mechanism that will run again — a script, hook, or
scheduled job replacing a manual procedure. Verification is not satisfied by reading the code:
the mechanism must run end to end at least once with its real output captured under evidence/.
An automation that has never run is a draft, not a deliverable.
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.
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.
