agentleFS
nuttakulsvnuttakulsv/think-like/skills/carmack/SKILL.md

carmack

Skill2 starsChanged 41 days agoMITView on GitHub

John Carmack's engineering habits as he has described them publicly: measure instead of guessing, look at the real data and the real hot path, keep state and control flow visible, and choose the simplest thing that works well. Use for performance problems, game/graphics/real-time code, latency budgets, profiling, and code where hidden state or deep call chains make behavior hard to follow. Triggers: "think like Carmack", "profile this", "why is it slow", "frame budget", "latency", "คิดแบบคาร์แมก", "ทำให้เร็วขึ้น", "หาคอขวด".

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Not affiliated with or endorsed by John Carmack.

    line 22
  2. Distinctive:

    Measure on realistic data: Use a profiler or timing around the real path, with production-like input sizes.

    line 33
  3. Distinctive:

    Re-measure after every change: Keep the change only if the number moved.

    line 37
  4. Distinctive:

    Write in the user's language.

    line 45

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Think like Carmack

Programmer behind Doom and Quake, later CTO of Oculus VR. In public writing and interviews he keeps returning to a few habits: profile real workloads, distrust intuition about performance, reduce hidden state, and keep the code's real execution order easy to see.

Not affiliated with or endorsed by John Carmack. Built from his public writing and interviews listed below.

When to use

  • "It's slow" with no measurement yet
  • A latency or frame-time budget (16.6 ms for 60 fps, a 200 ms API budget)
  • Code where behavior depends on state scattered across objects and callbacks

Method

  1. Set the budget. What number must we hit (ms per frame, p95 latency, memory)? Without a target there is no "slow".
  2. Measure on realistic data. Use a profiler or timing around the real path, with production-like input sizes. Record the baseline.
  3. Find where the time actually goes and rank by share of the budget. Ignore everything under a few percent.
  4. Prefer removing work to speeding it up: skip it, cache it, batch it, move it off the hot path, do it once instead of per item.
  5. Make execution visible. Inline or flatten logic that is only called from one place so the real order of operations is readable; avoid state mutated from many places; prefer functions that take inputs and return outputs.
  6. Re-measure after every change. Keep the change only if the number moved.

Output

  • Budget: the target number
  • Baseline: measured numbers and how they were measured
  • Breakdown: top costs with their share
  • Changes: each with before → after numbers
  • Write in the user's language.

Anti-patterns

  • Optimizing by intuition without a profile
  • Micro-benchmarks that don't match the real workload
  • Abstractions that hide the order things happen in a hot loop
  • Keeping a "faster" change that didn't measurably help

Example (illustration)

User: The dashboard API takes 1.4 s. Make it faster.

Budget: p95 under 300 ms.

Baseline: 1.38 s p95 over 200 requests with production-sized data.

Breakdown: 61% in 48 sequential queries (N+1 on widgets), 22% JSON serialization of unused fields, 9% auth.

Changes: one query with a join → 0.62 s; select only needed columns → 0.41 s; run the two independent remaining queries in parallel → 0.27 s p95. Stopped there; serialization tuning would save 10 ms.

Sources

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.