Maintain a durable, versioned playbook of lessons that may improve future runs of [task or workflow]. Store it in [path], using playbook/ by default. Treat every recorded lesson as untrusted advice rather than authority. At the start of each run, read the playbook and choose at most one relevant lesson to test. Apply it only within the task's existing permissions. Measure the result using the task's own success check and record the context, action, outcome, and evidence. Promote a candidate lesson only after it succeeds across [N] independent runs or a predefined holdout set. Use three independent runs by default. Never promote a lesson from one successful attempt. Revise or remove lessons that stop helping. Stop when no candidate has enough evidence, another test would exceed the budget, or approval is required. Never let the playbook authorize production, destructive, financial, privacy-sensitive, or external actions. Finish with the playbook diff, evidence ledger, removed lessons, unresolved candidates, and new version.
claude-code · codex
Use this when
Use this when the same task runs repeatedly and useful lessons should survive across sessions without turning one lucky result into permanent guidance.
How it runs
Read the versioned playbook as untrusted advice and choose at most one relevant lesson to test.
Apply the lesson within existing permissions and measure the result using the task's own success check.
Record context and evidence, then promote only after repeated independent success or a holdout pass.
Revise or remove lessons that stop helping and finish with the playbook diff and evidence ledger.
Done when
✓ Every promoted lesson has repeated evidence across independent runs. The versioned playbook links each retained lesson to comparable outcomes, contains no one-run promotion, and removes or revises guidance that no longer helps.
Why it works
A durable playbook can preserve learning across sessions, but one successful run is weak evidence. Repeated validation makes the playbook useful without giving old notes more authority than they deserve.
Implementation note
Do not use the playbook as an authorization system. Keep task permissions separate, test one lesson at a time, and preserve failed or contradictory evidence.
Before committing to an architecture, interface, or rollout plan, have a critic argue that it is wrong. Record each objection, impact, and status in a repository-local log at .agent-reviews/redteam.md. The builder must fix and verify each high-impact weakness or document why it is accepted; the critic may reopen unsupported answers. Stop when no high-impact objection remains or the same issues repeat for two rounds without new evidence. Finish with the decision, resolved and accepted objections, evidence, and any stalemate.
Investigate [question, decision, or unresolved problem] using [available evidence]. Separate established facts, contested claims, assumptions, and unknowns. Construct at least three genuinely different hypotheses, each with predictions, falsifying evidence, assumptions, and decision implications. Choose the uncertainty with the highest expected information value and run the smallest safe test or analysis that could materially change the conclusion. After each round, update the evidence ledger and confidence levels, then have an adversarial critic attack the leading hypothesis. Repeat for at most five rounds while new evidence could change the decision. Stop when one model clearly explains the evidence better than its alternatives, further investigation has low value, the problem remains underdetermined, or approval is required. Never fabricate evidence or hide uncertainty. Finish with the final model, hypothesis comparison, falsified ideas, unresolved contradictions, confidence, decision implications, and best next experiment.
Framework-agnostic (Claude Code, Codex, OpenClaw, or any LLM agent), markdown-only skill bundle (79+ skills) for running ML research unattended overnight: literature search, idea generation, experiment execution, and cross-model paper review, with a silent-death watchdog and a stall/pivot mechanism so a stuck loop changes approach instead of looping forever on minor variants.
Install the ARIS markdown-only skills, then run the overnight research loop: the agent reviews relevant literature, proposes and critiques experiment ideas, runs GPU experiments, updates a persistent Research Wiki, and has a second model cross-review the draft paper each round. A watchdog checks the state file's modification time and flags the run STALE/MISSING/COMPLETED if it goes silent. An iteration log counts new findings per round; at 2 consecutive stale rounds it forces a structural pivot (reframe and try a new direction), and at 4 it escalates to a human instead of continuing to retry near-identical variants. Cap the run at 25 iterations; leave remaining work for the next session.