SKILL.md

Loop Run Log

Every serious loop needs an audit trail. A run without a record is a run that cannot improve, and a loop that only reports "done" is drifting whether you can see it or not.

When to log

Any recurring workflow: scheduled automations, lead discovery and outreach loops, publishing loops (newsletter, social, content), SEO or data refresh loops, coding and deployment loops, recurring client workflows. One-off debugging can live in a chat summary unless the loop will repeat. If it repeats, it logs.

The run record

Write this after every run, in the loop's project folder or wherever the loop's artifacts live:

run_id: <loop-name>-YYYY-MM-DD-HHMM
loop_name: <name>
trigger: <manual | schedule | webhook | user request | file change>
window_checked: <date/time range or source scope>
inputs:
  - <source checked>
skill_stack:
  - <skill used>
actions_taken:
  - <specific action>
outputs_written:
  - <file, URL, record, draft, post, PR, issue>
verification_evidence:
  - <command output, record ID, URL, API response, log excerpt>
blockers:
  - <none, or a concrete blocker>
risks:
  - <residual uncertainty>
next_trigger: <date/time/event>
next_action: <one concrete next move>
external_actions: <none | drafts only | sent | published | deleted | purchased>

Rules:

Evidence is external. A record ID, a URL, a command output. "It worked" is not evidence. Use behavior-validator to generate the evidence when possible.
`external_actions` is never omitted. It is the one field a reviewer checks first: did this run touch the outside world, and with what permission.
`next_trigger` and `next_action` are always concrete. A loop without a scheduled next step is a loop that silently died.
No secrets, no raw private transcripts, no inbox dumps, no unneeded personal data. Reference sources by name and scope, not by content.

Quality bar

A good run log answers six questions: what caused this run, what was checked, what changed, how do we know it worked, what is unresolved, what happens next. A bad run log says "completed", "done", or "no updates". If a reviewer cannot reconstruct the run from the log alone, the log failed.

Good vs bad

Bad: actions_taken: ran the outreach loop. outputs: done. blockers: none. Three weeks later nobody knows which prospects were contacted, whether sends happened, or why replies dried up.

Good: window_checked: prospects added <DATE_RANGE>, actions_taken: drafted 8 connection notes, outputs_written: drafts in <CRM_RECORD_IDS>, external_actions: drafts only, next_trigger: <NEXT_RUN_DATE>, next_action: human review of 8 drafts before send. A reviewer reconstructs the run in one read.

Verification

After writing the record, run the reconstruction test: read only the log and state what the run did, what evidence backs it, and what happens next. Expect a complete answer with no memory required. If any of the six quality-bar questions is unanswerable, the log is incomplete, fill the missing field now while the run is fresh.

Completion checklist

[ ] All fields present, none deleted for convenience
[ ] Every claim in actions_taken backed by an entry in verification_evidence
[ ] external_actions filled accurately
[ ] next_trigger and next_action concrete
[ ] No secrets or raw private data in the record
[ ] Stored with the loop's project artifacts

Any box unchecked: not done. Fix or say so.

Footguns

Post-hoc logging. Writing the record hours later from memory drops the failures and keeps the wins. Fix: record actions as they happen, finalize immediately after the run.
Evidence-free claims. "Published successfully" with no URL. Fix: every action that changed something external gets an ID, URL, or output excerpt.
Sensitive data creep. Convenience-pasting a full email thread into the log. Fix: reference by record ID and scope, redact before storing.

loop-run-log