Code that fits in your head

Skill CodeAlive-AI/ai-driven-development/skills/code-that-fits-in-your-head

Practices, protocols, and skills for AI-driven software development. Skills and safety hooks for Claude Code, Codex, OpenCode, Cursor, Antigravity, and any agent supporting the Agent Skills standard.

Install

npx -y skills add CodeAlive-AI/ai-driven-development --skill code-that-fits-in-your-head

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Software engineering heuristics from Mark Seemann's book Code That Fits in Your Head (2021). Use when writing new code, reviewing code, refactoring, designing APIs, handling validation and invariants, writing unit tests, debugging defects, performing security review (STRIDE), or setting up a new code base. Covers decomposition (cyclomatic complexity, 80/24 rule, cohesion, fractal architecture), encapsulation (invariants, parse-don't-validate, Postel's law), outside-in TDD (walking skeleton, AAA, triangulation, devil's advocate), API design (affordance, poka-yoke, CQS), git/PR hygiene (50/72 commits, small commits, code review), feature flags, Strangler pattern, bisection debugging, logging with decorators, and STRIDE threat modelling. Not for language-specific syntax, framework tutorials, production incident response, or performance profiling.

SKILL.md

6.1 KB, as published. Nobody here has run it

Code That Fits in Your Head

Engineering heuristics for sustainable software, based on Mark Seemann's 2021 book.

Philosophy (Why This Skill Exists)

Software development is principally a design activity, not construction. Code is written by people, read by people, and endures far longer than any "project". These heuristics are rules of thumb (not scientific laws) that make software sustainable — that is, cheap to change and resilient to the next 10,000 small 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 doesn't grow by itself — someone writes it
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:

Successful software endures. Prefer changes that don't lock the future; avoid "finish-and-forget" thinking.
Heuristics, not laws. Every rule in this skill has context. Understand why before deviating. When the user asks to break a rule, check if their reason addresses the rule's rationale.
Design = typing code. Code review, naming, function size, and API shape are the primary design surfaces.
The future is unevenly distributed. Techniques described here (CI, tests, checklists, STRIDE) exist today — adopt them per-context rather than arguing for greenfield-only use.

See references/foundations/ for more on sustainability, readability, and brain-limited design.

How to Use This Skill

Identify the user's task (writing, reviewing, debugging, security review, setting up, etc.)
Read guidelines.md — it maps tasks and symptoms to specific reference files
Load only the reference files relevant to the current task (progressive disclosure)
Apply the rules; when in doubt, consult references/practices-glossary/ for cross-references

Chapter Index

Topic	Use when...
`references/foundations/`	Understanding why code should fit in head; sustainability, readability, humane code
`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/`	Splitting a function/class; cyclomatic complexity, 80/24 rule, cohesion, feature envy, fractal architecture, composition
`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 PRs; 50/72 rule, small commits, continuous integration, pair/mob, code review
`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 practice by name (28 entries: 50/72, 80/24, AAA, Bisection, CQS, Strangler, etc.)

⚠️ Editorial amendments (NOT from the book)

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/`	The question is specifically about how a code agent should do something differently from Seemann's 2021 guidance — tight verification loops, hallucination debugging, strict types as primary guardrails, reviewable vs readable code

Workflows

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).