Most people use Claude Code the same way: open a repo, ask it to patch a bug, skim the diff. That is the front door and most never look further. But spend real time with the tool and a different shape emerges. Developer Zach Dissington spent the last few months living inside that second shape and published his field notes in an MIT-licensed handbook on DEV.to.

The Task Store: Plain Markdown as a Database

Dissington's core insight is deceptively simple: keep your task list as plain markdown files with YAML frontmatter. Status, priority, due date, project assignmentβ€”all readable by humans and parseable by scripts. No API calls, no separate database to sync, no vendor lock-in. Because the tasks live in git, your entire work history is just the commit log. Claude reads the same files you do, so it can plan your day without any special integration.

Hooks That Enforce Instead of Just Propose

This is where it gets interesting from an ops perspective. Dissington uses PreToolUse and PostToolUse hooks to transform Claude Code from a chat box into something closer to a policy enforcement layer. A PreToolUse hook can block an action before it runsβ€”a safeguard against destructive commands or two terminals editing the same file simultaneously. A PostToolUse hook records what just happened, auto-committing finished work scoped exactly to the files that session touched. The agent proposes; the hooks enforce.

Memory That Survives the Session

The third primitive closes the loop on institutional knowledge. When Dissington corrects Claude Code mid-session, that correction gets promoted into a small markdown file that future sessions load on demand. Over time, the system accumulates judgment calls instead of forgetting them at the end of every conversation. A lesson taught once does not need to be relearned in every new context.

What This Actually Looks Like in Practice

The full pattern set includes task storage, daily workflow routing, hook configurations for enforcement and audit trails, session capture, memory management, and multi-terminal or multi-agent coordination. Dissington scrubbed real examples from his own workflows before publishing them. The repo lives at github.com/zachdissington/claude-code-operators-handbook for anyone who wants to fork it.

Key Takeaways

  • Task lists as markdown with YAML frontmatter eliminate the need for a separate database or API integration
  • PreToolUse and PostToolUse hooks turn Claude Code into an enforcement layer rather than just a conversational partner
  • Corrections promoted to persistent memory files let the system accumulate institutional knowledge across sessions
  • Git history doubles as work history, making audit trails automatic and native to the workflow

The Bottom Line

This is not about hypeβ€”it is about recognizing that the same primitives that make an LLM useful for code editing (filesystem access, hooks on actions, cross-session memory) are exactly what you need to run a back office. Dissington built his ops layer out of markdown files and shell scripts because that is all it required. The interesting question now is whether more developers will start treating these tools as infrastructure rather than chat interfaces.