How to Concept a Cheatsheet

The test for a good cheatsheet

A cheatsheet passes if someone can open it mid-task, find what they need in under 10 seconds, and close it. If it requires reading, it’s a tutorial. If it requires knowing the domain first, it’s a reference doc. A cheatsheet is neither — it’s a lookup tool.

Scope: one job, not one topic

Bad scope: “Git” (too broad — 200 commands) Good scope: “Git daily workflow” (10–15 commands someone uses every day)

Bad scope: “Claude” (a product, not a task) Good scope: “Claude CLI commands” (specific, scannable, bounded)

The right scope is the smallest set of information that covers 90% of the real use cases.

Structure: groups before alphabetical

Group commands by task, not alphabetically. A developer reaching for a cheatsheet mid-task is thinking “I want to do X” — they’re not thinking “I want a command that starts with R.”

## Daily Workflow      ← task group
## Branches            ← task group
## Undo                ← task group

Within each group: most common commands first, edge cases last.

Density: one line per item

Every entry should fit on one line. If a command needs more than a short inline comment to be useful, it belongs in a guide, not a cheatsheet.

git stash        # save uncommitted changes temporarily  ✅
git stash        # saves all uncommitted changes so you can switch branches
                 # without losing work, useful when you're in the middle of
                 # something and need to pull or check another branch       ❌

What to cut

• Commands you’d only use once a year
• Flags that are always inferred from context
• Warnings and gotchas (put those in a guide)
• Anything that requires reading a paragraph to understand