cs-philosophy-review
Skill0 starsChanged 7 months agoMITView on GitHub
Use for a deeper design or implementation critique grounded in enduring programming wisdom: simplicity first, clarity over cleverness, abstraction restraint, deletion when possible, and explicit tradeoffs.
In this repositoryOne other file it gives its agents.
- code-mentorSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 10 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
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
- Distinctive: line 9
Use this skill for a first-principles critique of code or design.
- Distinctive: line 13
Ask these questions explicitly:
- Distinctive: line 16
Should any code be deleted instead of added?
- Distinctive: line 25
Prefer obvious code to surprising code.
- Distinctive: line 26
Prefer local clarity to framework theater.
- Distinctive: line 27
Prefer data shape clarity before abstraction growth.
- Distinctive: line 28
Prefer reversible decisions over ornate structure.
- Distinctive: line 29
Treat “no code” or “less code” as a serious candidate, not a rhetorical flourish.
- Distinctive: line 43
Avoid hero worship and avoid empty aphorisms
- Distinctive: line 44
Use programming wisdom as a decision aid, not as ornament
≈ “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.
Files
CS Philosophy Review
Use this skill for a first-principles critique of code or design. Apply durable engineering judgment rather than style nitpicks.
Core questions
Ask these questions explicitly:
- Is this the simplest solution?
- Should any code be deleted instead of added?
- Is the abstraction earning its cost?
- Did we generalize too early?
- Would a plainer data structure or control flow solve this better?
- Is the code easier to explain than the obvious alternative?
- Does this optimize for clarity over cleverness?
Review lens
- Prefer obvious code to surprising code.
- Prefer local clarity to framework theater.
- Prefer data shape clarity before abstraction growth.
- Prefer reversible decisions over ornate structure.
- Treat “no code” or “less code” as a serious candidate, not a rhetorical flourish.
Output
Give a concise review with:
- What is good — the parts that show good taste or restraint
- What is too complex — unnecessary abstraction, indirection, or ceremony
- What should change — the simplest credible improvement
- What should maybe be deleted — any code that may not need to exist
Tone
- Calm, senior, and unsentimental
- Avoid hero worship and avoid empty aphorisms
- Use programming wisdom as a decision aid, not as ornament
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
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.