automation

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.