From fabrik
Writes and maintains implementation diaries for non-trivial tasks like features, bug fixes, refactors; captures changes, why, successes, failures with errors/commands, learnings, tricky parts, review notes in dated Markdown files.
How this skill is triggered — by the user, by Claude, or both
Slash command
/fabrik:diaryThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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:
git commit.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 docs/diary/YYYY-MM-DD-<slug>.md relative to the project root.
docs/diary/ directory if it doesn't existExamples:
docs/diary/2026-03-25-add-diary-skill.mddocs/diary/2026-03-20-fix-auth-race-condition.mddocs/diary/2026-03-18-PROJ-123.md# Diary: <task description>
Brief description of the goal and context for this task.
## Step 1: <short description>
**Author:** <agent name -- "main" if written by the main agent, otherwise the sub-agent name>
### Prompt Context
**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>
### What I did
<factual description of actions taken, files touched, commands run>
### Why
<connects the actions to the goal>
### What worked
<positive signals worth replicating>
### What didn't work
<failures recorded immediately with verbatim errors and commands>
### What I learned
<tacit knowledge that isn't obvious from the code>
### What was tricky
<friction points, hidden complexity, sharp edges>
### What warrants review
<tells a reviewer where to look and how to validate>
### Future work
<implied follow-ups that naturally fell out of the work, not a wishlist>
## Step 2: <short description>
...
/src/handler.go).**Author:** line right under each step heading you write so it's obvious who wrote it -- your sub-agent name if you're a named sub-agent, or main if you're the main agent.This skill activates proactively during non-trivial implementation work:
Do not activate for:
npx claudepluginhub maragudk/fabrik --plugin fabrikLogs daily development progress with project-isolated diary entries and optional sync to Notion/Obsidian. Invoke via /diary or when summarizing achievements.
Logs session accomplishments, file changes, commits, decisions, and next steps for future recall. Triggered by phrases like 'save diary' or 'wrapping up'.
Logs accomplishments from Claude Code sessions to dated markdown files at session end, context checkpoints, self-improve triggers, or user request.