history-hygiene

Record final confirmed decisions to history.md for future agents.

2|1|Updated Mar 25, 2026

Search Tags:#documentation #audit #history #truth #team-collaboration #decision-tracking #record-keeping

Ready to run

npx skills add https://github.com/PlagueHO/plagueho.learn --skill history-hygiene-plagueho

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: history-hygiene
Source: https://github.com/PlagueHO/plagueho.learn/tree/main/.copilot/skills/history-hygiene
Command: npx skills add https://github.com/PlagueHO/plagueho.learn --skill history-hygiene-plagueho

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

History files (.md files tracking decisions, spawns, outcomes) are read cold by future agents. Stale or incorrect entries poison decision-making downstream. The Kobayashi incident proved this: history said "Brady decided v0.6.0" when Brady had reversed that to v0.8.17. Future spawns read the wrong truth and repeated the mistake.

Core Features & Use Cases

Record the final outcome to ensure history reflects actual decisions and not interim requests.
Wait for confirmation before writing to prevent premature entries; update entries when reversals occur.
One truth per history entry to prevent readers from cross-referencing multiple sources.
Use Case: When a product decision is finalized and later reversed, log the final state to history.md to preserve the correct record for future agents.

Quick Start

Log the final outcome to history.md once a decision is confirmed and no longer subject to change.

Frequently Asked Questions about history-hygiene

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

FAQPage Schema

How do I prevent stale decision logs from poisoning future agent spawns?▼

To prevent stale decision logs, record only the final outcome to history.md after confirmation. This ensures future agents read a single truth rather than intermediate requests or reversed decisions that no longer apply.

Why does my history file show incorrect decision tracking after a reversal?▼

Incorrect decision tracking occurs when history files log interim requests instead of final outcomes. Update history.md entries immediately when decisions are reversed so future agents read the actual final state rather than outdated requests.

What is the best way to maintain a single source of truth in team decision history?▼

The best way to maintain a single source of truth is to wait for confirmation before writing to history.md, then update the entry whenever a decision changes. This prevents readers from cross-referencing multiple conflicting sources.

When should I write to a history log to avoid premature entries?▼

Write to a history log only after a decision is finalized and no longer subject to change. Waiting for confirmation prevents premature entries that would need correction if the decision is later reversed.

Can I update history entries when a recorded decision is reversed later?▼

Yes, you can and should update history entries when decisions are reversed. Recording the ultimate decision to history.md ensures that future spawns read the correct final state rather than the stale original entry.

Does this approach work for team collaboration audit trails and record-keeping?▼

Yes, this approach suits team collaboration audit trails by ensuring record-keeping reflects the ultimate decision. History entries capture one truth per outcome, preventing downstream agents from acting on incorrect or stale information.