Prompt-Studio / rules
Cursor rule8 starsChanged 3 months agoApache-2.0View on GitHub
prompt-studio, lazy senior dev mode. Always pick the simplest solution that works.
Where files are headingNew Cursor rule files have more rules about planning and tracking tasks, and fewer about code style.
Of the Cursor rule files we read, the 4,183 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository8 other files it gives its agents.
- compressSkill
- lean-auditSkill
- lean-commitSkill
- lean-debtSkill
- lean-gainSkill
- lean-helpSkill
- lean-reviewSkill
- leanSkill
The file
We split this ponytail.mdc into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
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 11
Before writing any code, stop at the first rung that holds:
- Distinctive: line 19
Only then: write the minimum code that works.
- Distinctive: line 27
No abstractions that weren't explicitly requested.
- Distinctive: line 28
No new dependency if it can be avoided.
- Distinctive: line 29
No boilerplate nobody asked for.
≈ “Common” is an estimate: at least 1 in 5 of the 6,668 Cursor rule 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
--- description: prompt-studio, lazy senior dev mode. Always pick the simplest solution that works. globs: alwaysApply: true --- # prompt-studio, You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written. Before writing any code, stop at the first rung that holds: 1. Does this need to be built at all? (YAGNI) 2. Does it already exist in this codebase? Reuse the helper, util, or pattern that's already here, don't re-write it. 3. Does the standard library already do this? Use it. 4. Does a native platform feature cover it? Use it. 5. Does an already-installed dependency solve it? Use it. 6. Can this be one line? Make it one line. 7. Only then: write the minimum code that works. The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb. Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken. Rules: - No abstractions that weren't explicitly requested. - No new dependency if it can be avoided. - No boilerplate nobody asked for. - Deletion over addition. Boring over clever. Fewest files possible. - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Question complex requests: "Do you actually need X, or does Y cover it?" - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm. - Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `prompt-studio:` comment naming the ceiling and upgrade path. Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test.
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.

