How do I install the Log Deviation skill?

Run npx skillmds@latest add trac3r00/log-deviation in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Log Deviation safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Log Deviation?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Log Deviation free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Log Deviation?

trac3r00 (@trac3r00) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Log Deviation by trac3r00 — Agent Skill

Name: Log Deviation
Author: trac3r00

Log Deviation

Record a place where the code forced a deviation from the agreed plan. Use mid-implementation whenever reality contradicts the plan, or when the user says "log this deviation". The log feeds future planning and the merge quiz.

trac3r00 bfbaf69 3 files · 3.5 KB Updated Sep 17, 2026

File contents

Deviation Log

The plan said one thing; the code demanded another. Record it while it's fresh — these entries are the highest-value input to the next plan.

Where the log lives

In a git repo: docs/deviations/YYYY-MM-DD-<task-slug>.md at the repo root (create docs/deviations/ if needed). <task-slug> = short kebab-case name of the current task. Slugs are minted freely, so two sessions will name the same task differently: before creating a new file, list what already exists in docs/deviations/ and reuse the slug of any file that is plausibly this task — appending to it even if it's from an earlier day/session — rather than minting a near-duplicate.
Outside a git repo: write to the session scratchpad instead and tell the user the path.

Entry format (append, newest last)

## <YYYY-MM-DD HH:MM> — <one-line summary>
- **Plan said:** <what the plan/spec assumed>
- **Code forced:** <what was actually done instead>
- **Why:** <the real-world constraint that made the plan wrong>
- **Ripple:** <other plan steps this invalidates, or "none">

The heading carries the full date: the file spans days by design, and HH:MM alone goes ambiguous on the second session.

Discovered drift

Not every deviation is caught live. When work reveals that plans or docs already disagree with the shipped code (a stale roadmap item, a doc promising a design the code abandoned), log it with the same fields plus one more:

- **Found while:** <the current activity that surfaced it>

Date the heading with the discovery time; if the deviation's original date is known, name it in Code forced.

Rules

One entry per deviation, logged at the moment it happens — not batched at the end.
"Why" names the constraint (API limitation, hidden coupling, wrong assumption), never just "it didn't work".
If invoked with no deviation to log, ask what deviated rather than inventing one.
Do not commit the log automatically; leave staging to the user's normal flow.

---name: log-deviationdescription: Record a place where the code forced a deviation from the agreed plan. Use mid-implementation whenever reality contradicts the plan, or when the user says "log this deviation". The log feeds future planning and the merge quiz.license: MIT---# Deviation LogThe plan said one thing; the code demanded another. Record it while it's fresh —these entries are the highest-value input to the next plan.## Where the log lives- In a git repo: `docs/deviations/YYYY-MM-DD-<task-slug>.md` at the repo root (create `docs/deviations/` if needed). `<task-slug>` = short kebab-case name of the current task. Slugs are minted freely, so two sessions will name the same task differently: before creating a new file, list what already exists in `docs/deviations/` and reuse the slug of any file that is plausibly this task — appending to it even if it's from an earlier day/session — rather than minting a near-duplicate.- Outside a git repo: write to the session scratchpad instead and tell the user the path.## Entry format (append, newest last)```markdown## <YYYY-MM-DD HH:MM> — <one-line summary>- **Plan said:** <what the plan/spec assumed>- **Code forced:** <what was actually done instead>- **Why:** <the real-world constraint that made the plan wrong>- **Ripple:** <other plan steps this invalidates, or "none">```The heading carries the full date: the file spans days by design, and `HH:MM`alone goes ambiguous on the second session.## Discovered driftNot every deviation is caught live. When work reveals that plans or docsalready disagree with the shipped code (a stale roadmap item, a doc promisinga design the code abandoned), log it with the same fields plus one more:```markdown- **Found while:** <the current activity that surfaced it>```Date the heading with the *discovery* time; if the deviation's original dateis known, name it in **Code forced**.## Rules- One entry per deviation, logged at the moment it happens — not batched at the end.- "Why" names the constraint (API limitation, hidden coupling, wrong assumption), never just "it didn't work".- If invoked with no deviation to log, ask what deviated rather than inventing one.- Do not commit the log automatically; leave staging to the user's normal flow.

Frequently asked questions