| name | suckless |
| description | Apply the suckless philosophy — simplicity, clarity, frugality — when designing, writing, reviewing, or refactoring software in any language. Use when the goal is minimal, bloat-free tools where removed code is progress. |
Suckless
Language-agnostic distillation of the suckless philosophy and the essays it cites.
Inline [tags] reference the sources listed at the end.
Use this skill when the aim is small, sharp, maintainable software for advanced users —
where complexity is the enemy and the best change is often a deletion.
Philosophy
- Simplicity, clarity, frugality. These are the goals, in that order. Elegant simple
design is harder than letting features accumulate ad hoc — do the harder thing.
[philosophy]
- Removed lines are progress. More code is not more skill. "The more code lines you
have removed, the more progress you have made." Measure work by what you took out.
[philosophy]
- Complexity is the root cause. Bloat drives inconsistency, wasted resources, poor
performance, and vulnerabilities. Resist it at the source, not with more patches.
[philosophy]
- Minimalism finishes. Staying minimal and clear keeps goals realistic and lets a
project actually reach completion. [philosophy]
- Build for experienced users. Target advanced users ignored by mainstream software.
Do not add layers to guard against every conceivable misuse. [philosophy]
- Unix philosophy. Do one thing well; compose through ordinary interfaces — files,
stdin/stdout, pipes, flags. [philosophy]
- Minimal viable program. A program should be so minimal that removing any part makes
it useless. Reuse existing infrastructure instead of duplicating it (get timestamps from
version control; don't build a date feature). Aim for behaviour stable enough to work
the same in 100 years. [Armstrong]
- Right-size the tool to the problem. Do not reach for heavy infrastructure when simple
composable tools and streaming already solve it. Know your actual bottleneck and weigh
total cost before adopting a platform. [Drake]
- Explicit over implicit. Keep control flow and error paths visible in the code rather
than hidden behind language machinery. [Sústrik]
- Fail gracefully. Handle errors rather than aborting; stay loosely coupled with few
dependencies; follow established standards; stay portable; don't force heavy dependencies
on users. [sucks]
How To Apply
Before writing, state the one thing the tool does. If it does more than one, split or cut.
Prefer deletion and directness:
- Cut features added "just in case" or for hypothetical users. [philosophy, Armstrong]
- Reject abstractions with no current duplication or complexity to justify them.
[philosophy]
- Reject dependencies that replace only a few clear lines of code, and prefer ones that are
small, portable, and don't force themselves on users. [sucks]
- Prefer config in source (compile-time) over runtime config machinery when it removes more
complexity than it adds. [philosophy]
- Reuse existing infrastructure instead of reimplementing it. [Armstrong]
- Keep the public/exported surface small; make internals private by default.
- Avoid cyclic dependencies between modules.
- Use the smallest, most standard subset of the language; avoid clever features and
extensions. [Sústrik]
- Keep scope tight — short functions, variables declared close to use.
- Comment only the surprising; let straightforward code speak for itself.
- When code has grown tangled, a clean rewrite beats another patch. [philosophy]
When reviewing, count what could be removed before suggesting anything to add. Every added
line must earn its place against the cost of maintaining it. [philosophy]
Test
Before writing or shipping, answer:
- Would removing any part make this useless? If not, cut the removable part. [Armstrong]
- Can I state what this does in one sentence, for one job? [philosophy]
- Did I remove more than I added, or justify every line I added? [philosophy]
- Is the tool sized to the actual problem, not a hypothetical one? [Drake]
- Would an experienced user find this obvious without a manual? [philosophy]
- Any feature, abstraction, or dependency here only added "in case"? [philosophy]
If (1)–(5) are no or (6) is yes, cut before you commit.
Sources
