DevDay

The problem nobody talks about

By Friday afternoon, I could not tell you what Tuesday was about. The commits were there — I could read them. But commits answer what changed. They never answer why I chose this, what I tried first, what was on fire at 11:30 that I forgot by 16:00.

I work in parallel across a stack of projects, some active, some dormant for weeks. When I came back to a repo cold, I wanted the project to tell me what we were doing — not in a heroic-narrative sense, but in a "here is the open question I left on the table" sense. Commits and grep do not give you that.

Practice came first

DevDay is not a new methodology. I have been writing little daily docs into my project repos for months, long before Claude Code shipped a way to call them out as "skills". By May 2026 I had hundreds of these files, in every git repo I work in. Not just software. Research repos. Writing projects. Infrastructure. Talks and lectures. Client work. Side experiments. If it lives in git, it gets a devlog. For me that is most things on my computer.

Their accumulated worth is immense — each one is a window onto a Tuesday afternoon I would otherwise have lost. What was new in May 2026 was packaging the habit as two slash commands, so the friction dropped to fifteen seconds and the convention became portable across the whole stack.

Two commands

The whole tool is two slash commands. /devday-log is the append-only data feed: run it whenever you finish a chunk, hit a wall, or make a decision worth remembering. It pulls your branch, your last few commits, and what changed recently, and writes a ## HH:MM — short summary block into today's log. /devday is the synthesiser: it reads the checkpoints, reads the git log for the day, and produces a clean structured report with sections for accomplishments, decisions made, next steps, and session quality.

Run /devday-log ten times during the day. Run /devday once. The synthesiser is idempotent — run it at noon to see the morning, run it at six to see the full day, run it twice in a row and get the same report. The checkpoint log inside the file is preserved verbatim; only the synthesis sections refresh.

Three design choices

Each came from a real failure I had with a previous attempt.

• Git is the only requirement. No database. No external app. No login. If you are in a git repository, DevDay works. If you are not, it refuses to run and tells you so in one line. Too many "knowledge management" experiments died on a second source of truth. Git is already the source of truth for code; the journal lives next to it.
• The skill orients itself on first run. Phase 0 detects the project name from package.json / pyproject.toml / Cargo.toml / go.mod / the repo basename — whichever it finds first. It probes for a sensible log directory (docs/devlogs/, .devlogs/, falling back to creating one). It writes .devday/config.json so it never has to ask again. From the second invocation onward, orient is a one-line cache hit.
• Append-only checkpoints, idempotent synthesis. /devday-log only ever appends — you cannot accidentally corrupt yesterday's notes. /devday rewrites today's file from scratch each time, preserving the checkpoint log verbatim.

The orchestrator field — responsibility as enactment

DevDay has one optional config field worth dwelling on: orchestrator. If set, the skill writes a signature line into every log header — the value is whatever string you choose: a name, an email, a handle, an internal ID, a team tag. On this site I use Magnus Smárason | smarason.is.

The point is not provenance metadata. The point is enactment. AI-assisted work is real work, and the human who set the prompt, accepted the suggestion, merged the PR remains responsible for what got built. The devlog is where that responsibility shows up in writing, day after day, in the orchestrator's own name. It is a small ritual — three words, a pipe, a domain. It is also a quiet contract with the future reader of the file: I did this. Push back on me, not the agent.

This is the same thread that runs through my Scite — Webinar talk and through Beyond Fragmentation — the irreducible human in AI-augmented work, the operator who cannot be issued by HR. The orchestrator field is what that thread looks like when it comes down out of the philosophy and into the file system. One line per devlog. Signed.

What an entry looks like

The site you are reading now uses DevDay. Yesterday's entry — the day I shipped the Scite — Webinar project page and retired a deprecated portal — lives at docs/devlogs/2026/05-may/devday_20260519.md. The structure that comes out of /devday is:

• Summary — two to four sentences with real PR hashes and specific numbers. What I read first when I come back from a weekend.
• Commits Today — table with hash, message, time, grouped by type.
• Decisions Made — the long-term value lives here. A commit says Merge #691. A decision says why we chose tar+npm-ci over docker exec and what we tried first that broke. Six months later, the difference is three minutes versus three hours.
• Session Quality — intentionally honest. Minor blockers is not a failure to disguise; it is a signal. Five "minor blockers" entries in a row about the same thing is a refactor waiting to happen.

What I use it for

Three patterns have emerged.

As a debugger for my own week. I scan the last seven daily logs on a Monday morning. Anything in Next Steps carried forward three days in a row gets done, dropped, or escalated. The journal makes drift visible.

As a handoff document. When a teammate jumps into a branch I have been on, I send them today's log. They get the context, the decisions, the things I tried and rejected — in five minutes of reading instead of fifteen minutes of explanation.

As input to higher-order analyses. The day-files are ingestible by an AI — feed a week of them to Claude and you get a surprisingly accurate "what did Magnús actually work on this week" summary, with the why preserved. Not possible from git alone.

A contribution to AI-assisted development

DevDay is small. Two commands, one file per day, markdown. It is also opinionated in a way that has shown up in months of accumulated logs. The opinions are: the journal lives next to the code, never apart from it. The same human who set the prompt signs the file. The decisions are written down on the day they were made, not reconstructed afterward. The friction is fifteen seconds — small enough that the habit survives.

None of that requires Claude Code specifically. The SKILL.md spec is self-contained and you can implement the same two commands in any agent or as plain shell scripts. Git is all the runtime you need. The skill is the friction-removal layer on top of a practice that already worked.

---

Status. Stable. Used daily across every active git repository I touch. The SKILL.md spec is available under MIT — if you try it, I want to hear what stuck and what did not. The skill is opinionated; those opinions came from real failures and they are open to revision.