The structure has three tiers: Prime Directives — how the model operates at all times, before any code is written. Per-Implementation Checklist — 10 questions that must be answered before a single line of code. Milestone-Level Requirements — architectural gates the codebase must pass at defined checkpoints, not on every commit.
The Prime Directives are the most important part. P1 is plan first, code second. The model is explicitly told that token usage and time spent are irrelevant — planning is the job. It’s also told to batch all clarifying questions into one message, not drip them out one at a time. And it must actively look for blindspots, not just answer what was asked. P2 is the TODO file as the source of truth. Every project gets a TODO.md broken into milestones → tasks → subtasks, with unlimited nesting depth. If a subtask is too complex, it gets its own file and a reference. Progress is logged as work happens. The reasoning: context windows are finite, conversation history compacts, and the TODO file is the only thing that survives a context reset. Without it, you’re starting from scratch every session. P3 is declare assumptions explicitly. This one matters more than it sounds. The model will always fill ambiguous gaps — it has to. The directive forces those gaps to be surfaced and confirmed before work that depends on them proceeds. “I’m assuming uploads are private by default” is a one-line statement that could prevent a serious security mistake.
The per-implementation checklist is ordered by when the question must be answered, not by importance: Hierarchy and open source first — has this been solved already? Backward compatibility — what does this break before we decide how to build it? Security — threat model, OWASP, attack vectors Resource and rate limits — every user-facing resource gets a quota, every action gets a velocity limit, both declared in a single central config file Idempotency — what happens if this write runs twice? Decided at design time, not retrofitted Performance — indexes, caching strategy, async, pagination Error handling — consistent format, explicit paths, nothing swallowed Testing — unit for logic, integration for endpoints, failure paths not just happy paths Logging — structured, levelled, centralised, never console.log Documentation intent — comment the why, never the what The reason backward compatibility is #2 (not buried near the bottom) is that it’s a look before you leap check. You need to know what you might break before you decide how to build, not after the code is written. Same logic for idempotency at #5 — it’s a design constraint on write operations, not an implementation detail. It shapes the solution.
The milestone tier separates concerns that don’t belong in every commit. Metrics infrastructure, API versioning policy, data retention and GDPR strategy, operational readiness (health checks, graceful shutdown, DR) — these are codebase-level decisions made once. Asking “have I instrumented this with Prometheus?” for every function is noise. Asking it before launch is essential. API versioning is M1 — first milestone gate — because it’s the single hardest thing to retrofit once external consumers exist.
The open source first principle has its own reference table. Before building anything, the model checks whether it’s already solved: support ticketing (Zammad, Chatwoot), search (Meilisearch, Typesense), auth (Keycloak, Ory), queues (BullMQ, Faktory), notifications (Novu), storage (MinIO). Reinventing the wheel is a last resort, not a starting point.
This is the entire Claude.md file https://pastebin.com/EkvsA6qN Curious what others have in their CLAUDE.md / AGENTS.md — especially around context window management and task decomposition. That’s the part I see least discussion about and it’s probably the highest-leverage thing for long projects. submitted by /u/Minute-Quote1670
Originally posted by u/Minute-Quote1670 on r/ClaudeCode
You must log in or # to comment.