The skills layer on over your first weeks: start with the day-one loop, add meetings, then the session-start briefings and the weekly cycle. You don't need all of it at once.
The whole system, on day one, is three commands: /new-worklog at the start of a session, work in the worklog as you go, /end-session at the end. Don't reach for anything else yet: meetings, planning, weekly cycles all layer on later. Get this rhythm first.
/new-worklog "fix flaky integration test in the auth flow"Creates a dated file under worklogs/ (e.g. worklogs/2026-05-22_fix_flaky_auth_test.md) pre-filled with Goal/Outcome, Tasks, an empty Work log, and a Summary. If a recent worklog has open tasks or a "next session" pointer, /new-worklog offers to carry that forward. Most days, say yes. Then read the Goal back and tighten it: it should answer "what did you do today?" in five seconds.
Keep the worklog open as you go and lean on Claude to maintain it. The rhythm is conversational: something happens, Claude proposes what to capture and where, you confirm or edit, Claude writes it. Done well, you barely think about the worklog as a separate artifact: it's a running transcript of the session's reasoning that Claude keeps for you.
CLAUDE.md to prompt this propose-confirm pass after each meaningful action. (Recommended snippets ship separately.)When you want something at a specific location (a Decision: bullet under a specific task, a numeric result in a specific subsection), reference a line number: "add a Decision: bullet at line 47 under the test-strategy task." Claude follows spatial pointers well and guesses badly from "add a note somewhere reasonable." The only universal: don't end a session with an empty Work log. Even three terse bullets give future-you traction.
Both keep you in control; they differ in how much you do by hand. Most days, reach for the agent-assisted close; drop to the fully-manual one when you want to sit in every edit.
1 · Agent-assisted: close with confidence (recommended). The agent does the drafting and a second, independent agent checks it before anything is written; you approve once. Not automated: you keep the final say, just not edit-by-edit. The win isn't speed; it's that you don't have to sit through it: while the review agent works, you can step away, then take one final look and verify at the end before all those edits land.
/audit end-sessionRun /audit end-session in place of /end-session. It's the close, double-checked before anything is written: one subagent drafts the full set of updates (writing nothing to your notes), a second, independent subagent reviews that draft against your actual notes, and you get a single approval at the end: a verdict, a summary of what would change, and any calls that need your decision. Approve, answer the open calls, or reject; only then are the writes applied.
sonnet) and a stronger one reviews (opus); override with --proposer-model / --reviewer-model. /audit wraps any write-heavy skill (its first argument is the skill you're checking, later /process-meeting or /build-week), and it adds little on read-only briefings like /catchup, so it'll say so.2 · Fully in the loop. When you'd rather be involved in every change (a 15–20 minute wind-down where you review and confirm each edit yourself), close with plain /end-session.
/end-session/end-session walks the worklog you wrote and helps you close it out. It drafts two things for your review: a Distilled information corner, the durable takeaways (what changed, the decisions you made and why, key findings), and the Summary, a handoff for next time (a "start here" pointer with files to open and commands to run, in-progress tasks, blockers, and next actions). Along the way it asks a couple of quick questions (what's blocked? the top next actions?), ticks off the tasks you finished, and proposes updates it noticed for your planning/ backlog and state/ items: a finished task flips to done; a decision or finding worth keeping becomes a state item. Every step pauses for you to confirm or edit, and it never rewrites your Work log or Goal.
/catchup and watch what you wrote come back as a tight briefing. That's usually when the system clicks.This is the human–agent co-working workflow. Reach for /co-work in two situations. The first is a bigger piece of work: a multi-step build, an investigation, anything you'd want decomposed and double-checked. It adopts a collaboration mode for the rest of the session: Claude works as your collaborator (breaking the task into pieces, dispatching subagents to build, review, and verify, and flagging its own soft spots) while you keep deciding scope, direction, and when it's good enough.
The second is working in parallel. Run two or three Claude Code sessions on the same project at once and they'll otherwise all write the same day's worklog, clobbering each other's edits. /co-work gives each session its own sublog (a separate file that links back to the day's main worklog), so parallel sessions never collide on one file, while the day's work still threads together in one place.
Once the worklog loop feels natural, meetings are the next thing worth structuring. Without a place for them, decisions made in a meeting either get re-typed into the worklog (and re-discovered later as a source-of-truth problem), or they evaporate. Meetings get their own short-lived file under meeting/, with a skill to pull the meeting's output into the rest of your trail.
Creates meeting/2026-05-22_weekly-sync.md from a template: attendees, agenda, notes, and a Decisions / Action items / Open questions block. Take live notes into it, or paste a transcript afterward.
Reads the note and proposes structured updates: decisions → state items, action items → planning items, open questions → state items (typed as questions). Links the meeting back to the same-day worklog. Pauses before writing: you confirm each.
Meetings produce outputs (decisions, action items, open questions) that are first-class artifacts of the project, not session-scoped notes. Routing them through /process-meeting means a decision made on Tuesday is queryable as a decision state item on Friday, alongside every other decision, without you remembering which day's worklog mentioned it.
/process-meeting extracts before confirming. Transcribers slip on technical terms, get names wrong, and occasionally invert a decision ("we agreed to ship X" vs. "we agreed not to ship X" can come out the same). The proposal step is your safety net. Don't skim it.These two are read-only and self-explanatory once you've tried them: they just read the trail you've been building. The distinction is which question you're asking.
Start-of-session briefing. Summarizes your recent worklogs, surfaces incomplete tasks, and points at where to start. Reach for it when you're returning to a project after a gap and need your head back in the game.
Prioritization dashboard built from the planning and state indices: what's active, what's up next, what's blocked, plus open questions worth attention. Reach for it when you know where you are but need to decide what to pick up.
Rule of thumb: /catchup re-loads your memory; /status chooses your next move. Many sessions start with one, then the other.
Honest framing: this is a layer-on-later habit, not a day-one one. Adopt it once the daily loop is automatic and you have enough planning items that a weekly focus actually helps.
Reads the planning and state indices (not every item, just the indices, for speed), folds in recent meeting signals, confirms priorities with you, then writes a focused weekly plan file.
Reviews the week against that plan, fills in a review-notes section, and catches planning items whose status drifted during the week so your backlog stays honest.