Log deviation

Skill hiendinhngoc/unknowns/skills/log-deviation

Agent skills (SKILL.md) for discovering your unknowns across the dev lifecycle — from Thariq Shihipar's 'Know Your Unknowns'

Install

npx -y skills add hiendinhngoc/unknowns --skill log-deviation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.3 KB, as published. Nobody here has run it

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.