codealive-ai/code-that-fits-in-your-head
Software-engineering heuristics based on Mark Seemann's Code That Fits in Your Head (2021), updated for agent-driven development. Use when writing or reviewing code, refactoring accidental complexity or a Big Ball of Mud, controlling technical or architectural debt in generated code, designing APIs and invariants, adding a feature through a walking skeleton and acceptance tests, debugging a defect with reproducible tests or bisection, threat-modelling endpoints and trust boundaries with STRIDE, planning a legacy or Strangler migration with rollback, or setting up a maintainable codebase. Covers decomposition and cyclomatic complexity, cohesion, encapsulation, outside-in TDD, separation of concerns, Git/review discipline, safe evolution, and troubleshooting. Not for language syntax, framework tutorials, production incident response, or performance profiling.
npx skills add https://github.com/CodeAlive-AI/ai-driven-development --skill code-that-fits-in-your-head
Engineering heuristics for sustainable software, based on Mark Seemann's 2021 book and clearly labelled agent-era amendments.
Software development is principally a design activity, not construction. An agent may produce most of the text, but people still review, operate, extend, and own the resulting system. These heuristics make software sustainable: understandable, resistant to architectural erosion, and cheap to change after thousands of decisions.
Core mental model from Chapter 1:
| Metaphor | What it gets right | What it misses |
|----------|-------------------|-----------------|
| Building a house | Plans, structure | Software endures; there's no construction phase (compiling is free); dependencies can start anywhere |
| Growing a garden | Pruning, refactoring, tending | Code does not improve by itself; generated code still needs stewardship |
| Art / craft | Skill, mastery, situational knowledge | Doesn't scale; leaves newcomers without guidance |
| Engineering (the target) | Heuristics, review, sign-off, checklists | We're not there yet — physical-construction calculations don't apply |
> "The act of describing a program in unambiguous detail and the act of programming are one and the same." — Kevlin Henney
Practical implications for a code agent:
See references/foundations/ for more on sustainability, readability, and brain-limited design.
guidelines.md — it maps tasks and symptoms to specific reference filesreferences/practices-glossary/ for cross-references| Topic | Use when... |
|-------|-------------|
| references/foundations/ | Sustainability, readability, complexity control, and code as liability |
| references/codebase-setup/ | Starting or inheriting a code base — git, build automation, warnings-as-errors |
| references/outside-in-tdd/ | Writing new features test-first; walking skeleton, AAA, triangulation, devil's advocate, editing tests |
| references/encapsulation/ | Designing types with invariants; DTO vs Domain Model, always-valid, Postel's law, parse-don't-validate |
| references/decomposition/ | Controlling method and system complexity; cyclomatic complexity, cohesion, coupling, feature envy, fractal architecture |
| references/api-design/ | Designing a public API; affordance, poka-yoke, CQS, hierarchy of communication, naming over comments |
| references/separation-of-concerns/ | Adding cross-cutting concerns; Decorator pattern, logging, what to log, performance vs legibility |
| references/teamwork-git/ | Writing commits, reviewing changes, continuous integration, collective ownership |
| references/evolution/ | Changing running systems; feature flags, Strangler pattern, versioning, regular dependency updates, Conway's law |
| references/troubleshooting/ | Debugging a defect; scientific method, rubber ducking, reproduce-as-test, bisection, non-deterministic defects |
| references/security/ | Threat modelling; STRIDE (spoofing, tampering, repudiation, info disclosure, DoS, elevation) |
| references/code-navigation/ | Onboarding to a code base; big picture, file organisation, cycles, property-based testing, behavioural code analysis |
| references/practices-glossary/ | Looking up a named book practice and its current status |
The folder below is NOT content from Seemann's book. It contains our own additions covering agent-specific concerns the 2021 book does not address. Do not attribute these files to Seemann. See references/agent-native/knowledge.md.
| Topic | Use when... |
|-------|-------------|
| references/agent-native/ | Agent-specific verification integrity, hallucination and dependency grounding, executable guardrails, and accountable review |
Composite step-by-step processes live in workflows/:
| Task | Workflow |
|------|----------|
| Review a pull request / piece of code | workflows/review-code.md |
| Add a new feature from scratch | workflows/add-feature-outside-in.md |
| Investigate and fix a defect | workflows/debug-defect.md |
| Threat-model a new endpoint | workflows/threat-model.md |
See guidelines.md for the full routing layer (task → file, symptom → file, decision tree).
Take codealive-ai/code-that-fits-in-your-head from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.