Fog log
During implementation, log deviations and newly discovered fog to the ledger instead of stopping or silently improvising. Use whenever implementing against a plan.From its SKILL.md
npx -y skills add leoncuhk/defog --skill fog-logAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 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.
SKILL.md
1.4 KB, 256 tokens by cl100k_base, as published. Nobody here has run it
Fog Log
First act: if FOG.md or PLAN.md exists, read both and announce the open count — a launch packet only works if the receiving session opens it.
When the territory contradicts the map: take the most reversible option, log it, update the plan line it invalidates, and keep going — do not block on the user. Stop and ask only for architecture, data migration, security, cost, or anything that changes what the user was promised — even if the response shape looks the same. Stop at a coherent checkpoint (stub, don't half-build); unrelated work may continue while you wait.
Feeling certain is not evidence of safety. Before touching a running service, shared resource, or config other components depend on, re-read the ledger's constraints and deviations — straightforward-sounding steps are where sessions do silent damage.
Log to FOG.md under ## Deviations (create the section on first write): what the plan said, what was done instead, why, what revisiting costs — 2–3 lines each. New unknowns discovered mid-build go to Open with resolvers, even if resolved seconds later.
An unlogged deviation is worse than none — the ledger claims completeness.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.