agentleFS
orenluxyorenluxy/fable-method/skills/implementation-notes/SKILL.md

implementation-notes

Skill1 starsChanged 4 months agoMITView on GitHub

Maintain an IMPLEMENTATION_NOTES.md decision log during any multi-step implementation session. Use this in EVERY session that involves writing or modifying code across more than one file, or any session expected to run longer than a few tool calls. Records decisions, deviations from plan, and open questions so nothing is silently guessed.

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Deviation protocol: When an edge case or discovered constraint forces departure from the plan:

    line 35
  2. Distinctive:

    Deviations are a convergence signal: If the Deviations section is growing while tests are not converging, the plan is wrong — stop, …

    line 41
  3. Distinctive:

    End of session: Read back the file. Anything under Open questions must be either answered by the user or explicitly accepted.

    line 43

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Implementation Notes

Purpose: during long implementation runs, unknowns are discovered continuously. Without a log, they get resolved by silent guesses that the user never sees. This skill makes every guess visible and auditable.

Setup

At the start of implementation, create (or append to) IMPLEMENTATION_NOTES.md in the project root or the current working directory:

# Implementation Notes — <task name>
Session started: <date>

## Plan summary
<2–5 lines: what we agreed to build>

## Decisions
<!-- Choices made where alternatives existed. Format: what / why / alternative rejected -->

## Deviations
<!-- Any point where reality forced a departure from the plan. Format: what the plan said / what was found / conservative option taken -->

## Open questions
<!-- Unknowns deferred to the user. Must be empty or acknowledged before merge. -->

Rules during implementation

  1. Every non-obvious choice gets a Decisions entry. One line each. If you chose a library, a data structure, an error-handling strategy — log it.
  2. Deviation protocol. When an edge case or discovered constraint forces departure from the plan:
    • Take the most conservative option (least code changed, most reversible).
    • Log it under Deviations with: plan said → territory showed → what I did.
    • Continue. Do NOT stop the run for deviations resolvable conservatively.
    • Exception: if the deviation invalidates the plan's architecture, STOP and ask the user. Logging is not a license to rebuild the design silently.
  3. Deviations are a convergence signal. If the Deviations section is growing while tests are not converging, the plan is wrong — stop, summarize the deviations, and propose replanning instead of continuing to patch. Three or more deviations touching the same subsystem = automatic stop-and-replan.
  4. End of session. Read back the file. Anything under Open questions must be either answered by the user or explicitly accepted. Summarize the log in your final message — do not assume the user will open the file.

Anti-patterns

  • Logging trivia ("used a for loop"). Log only choices where a reasonable alternative existed.
  • Using the log as a diary. It is a contract-tracking device, not narration.

Download now (ZIP)

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. Neeeophytee/finding-unknowns-skills★ 339same name
    2. edenbuilds/agentloop★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository7 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.