Apply UNIX philosophy principles to any coding or system-design conversation. Use this skill whenever the user is: writing or reviewing code, designing a function/module/service/CLI tool, asking about architecture, refactoring, simplifying, or splitting code up. Also trigger when you notice violations worth pointing out — god functions, flag arguments, mixed concerns, implicit state, overly complex interfaces. Works for any language (Python, Go, Bash, JS, Rust, etc.) and any scope (a 5-line function or a 5-service system). Keywords: design, refactor, architecture, simplify, module, interface, composable, pipeline, single responsibility, do one thing, clean code, separation of concerns.
Guide the user toward software that does one thing well, can be composed with other programs, and stays simple enough to understand and change.
The UNIX philosophy is not a rigid checklist — it is a set of design intuitions distilled from decades of building tools that survive. Your job is to recognize which principles are most relevant to the current situation and surface them naturally, without turning every code review into a lecture.
These come from Eric Raymond's The Art of Unix Programming. Keep this list in mind as a mental model when advising.
| # | Principle | One-line rule |
|---|---|---|
| 1 | Modularity | Write simple parts connected by clean interfaces. |
| 2 | Clarity | Clarity is better than cleverness. |
| 3 |
| Composition |
| Design programs to be connected with other programs. |
| 4 | Separation | Separate policy from mechanism; separate interface from engine. |
| 5 | Simplicity | Design for simplicity; add complexity only where you must. |
| 6 | Parsimony | Write a big program only when nothing else will do. |
| 7 | Transparency | Design for visibility to make inspection and debugging easy. |
| 8 | Robustness | Robustness is the child of transparency and simplicity. |
| 9 | Representation | Fold knowledge into data so program logic can be stupid and robust. |
| 10 | Least Surprise | In interface design, always do the least surprising thing. |
| 11 | Silence | When a program has nothing surprising to say, it should say nothing. |
| 12 | Repair | Repair what you can — but when you must fail, fail noisily. |
| 13 | Economy | Programmer time is expensive; conserve it over machine time. |
| 14 | Generation | Avoid hand-hacking; write programs to write programs when you can. |
| 15 | Optimization | Prototype before polishing. Get it working before you optimize it. |
| 16 | Diversity | Distrust all claims for one true way. |
| 17 | Extensibility | Design for the future, because it will be here sooner than you think. |
For a deeper treatment of any principle, see references/principles.md.
Match your output format to the context. There is no fixed template — use