history-hygiene

Record confirmed final outcomes to history files instead of intermediate or reversed decisions.

Updated Jun 2, 2026
One-click install
npx skills add https://github.com/codebytes/btt --skill history-hygiene-codebytes
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: history-hygiene
Source: https://github.com/codebytes/btt/tree/main/.squad/templates/skills/history-hygiene
Command: npx skills add https://github.com/codebytes/btt --skill history-hygiene-codebytes

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? History files tracking decisions and outcomes are read cold by future agents, so stale or premature entries poison downstream decision-making. This Skill prevents recording intermediate requests or reversed decisions as if they were final truth. ## Core Features & Use Cases - Final-outcome recording: Write only confirmed results to history.md, never intermediate or "for now" states. - Reversal handling: Update entries immediately when a decision is reversed so no stale data remains. - Single-source-of-truth discipline: Ensure one read gives one truth, with no cross-referencing required by future readers. - Use Case: A migration target is discussed as v0.6.0 but later corrected to v0.8.17; the history entry records "Migration target: v0.8.17 (initially discussed as v0.6.0, corrected by Brady)" so future agents act on the real decision. ## Quick Start Apply the history-hygiene skill to review my history.md entries and rewrite any that record unconfirmed requests or reversed decisions.

Frequently Asked Questions about history-hygiene

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I keep decision history files accurate for future readers?

Record only confirmed final outcomes, not initial requests or intermediate states. Wait for explicit confirmation before writing, and if a decision reverses, update the entry immediately so no stale data remains.

What should I write in a history file when a decision is reversed?

Write the final outcome with brief context, for example: "Migration target: v0.8.17 (initially discussed as v0.6.0, corrected by Brady)". Never leave the superseded decision standing as if it were final.

Why is logging intermediate states to history files harmful?

Future agents read history files cold and treat them as truth without cross-referencing other sources. Intermediate or unconfirmed entries cause them to repeat mistakes, as happened in the Kobayashi v0.6.0 incident.

When should I write a decision to history.md?

Write only after the outcome is confirmed by the decision-maker. Do not log requests, proposals, or "for now" states; history is the source of truth, not a draft.

What are the limitations of relying on history files for decisions?

History files only work if every entry reflects one confirmed truth. They fail when writers attribute decisions without confirmation or assume readers will verify against other files, which readers will not do.