An implementation diary captures the narrative of your work: what you did, why, what worked, what broke, what was tricky, and what needs review. The concept of "diary" activates existing behavioral patterns without requiring much engineering -- the model already knows what a diary is.

Follow this cycle for each meaningful unit of progress:

A "step" is a logical chunk of work, not necessarily a single commit. Examples: "wire up the API endpoint", "debug the flaky test", "research how the auth middleware works".

Diary files live at relative to the project root.

Examples:

Brief description of the goal and context for this task.

Verbatim prompt: <the exact user prompt that initiated this step> Interpretation: <what the assistant understood from the prompt> Inferred intent: <the underlying goal behind the prompt>

<factual description of actions taken, files touched, commands run>

<tacit knowledge that isn't obvious from the code>

<friction points, hidden complexity, sharp edges>

<implied follow-ups that naturally fell out of the work, not a wishlist>

...

undefined

This skill activates proactively during non-trivial implementation work:

Do not activate for: