self-critique
Skill0 starsChanged 54 days agoMITView on GitHub
Systematically critique and improve any output, document, or skill. Use when: reviewing your own work, improving a draft, stress-testing a framework, or iterating on anything that needs to be better. Triggers: 'critique this', 'what's wrong with this', 'how can I improve this', 'review my work', 'iterate on this'.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- jaskirat1616/grok-skillstheir own version, first seen Nov 1, 2026
- goolars/Claude-Code-Stoptheir own version, first seen Oct 25, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- jaskirat1616/grok-skills★ 22same name
- goolars/Claude-Code-Stop★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- gif-loop-captureSkill
- release-gateSkill
- session-storySkill
- ship-learn-nextSkill
- ui-auditSkill
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 92
If not, break it down further
- Distinctive: line 95
Before: [what it says now]
- Distinctive: line 96
After: [what it should say]
- Distinctive: line 117
Read from the beginning as if first time
- Distinctive: line 124
Decision Rule: Stop when additional iteration yields diminishing returns.
- Distinctive: line 175
No cognitive moves, just labels
- Distinctive: line 180
Add cognitive HOW (highest impact)
- Distinctive: line 182
Add INVERT (easy + valuable)
- Distinctive: line 186
Add attack checklist to CHALLENGE with concrete questions
- Distinctive: line 187
Add INVERT mode with 4 cognitive moves, ~10 lines
≈ “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
Self-Critique
The Loop
IDENTIFY → RANK → SPECIFY → VALIDATE → (repeat if needed)Each phase has specific cognitive moves. Don't skip phases.
Phase 1: IDENTIFY (What's wrong?)
Goal: Surface all issues without filtering.
Cognitive Moves:
- HOW vs WHAT check
- Does this tell someone HOW to do it, or just WHAT to do?
- Can a novice execute this? If not, it's too abstract.
- Weakest-link scan
- Which section is weakest relative to its importance?
- Where does quality drop off?
- Absence check
- What's obviously missing?
- What question would a skeptic ask that isn't answered?
- Friction test
- Where would someone get stuck trying to use this?
- What requires re-reading to understand?
- Bloat check
- What could be cut without losing value?
- What's there to sound smart vs. to be useful?
Output: Raw list of all issues found. No filtering yet.
Phase 2: RANK (Pareto filter)
Goal: Ruthlessly prioritize. Most issues don't matter.
The Pareto Question:
"If I could only fix ONE thing, which creates the most value?"
Cognitive Moves:
- Impact sort
- High impact + easy fix → Do first
- High impact + hard fix → Do second
- Low impact → Probably skip
- Kill the perfectionism
- What's a "nice to have" disguised as important?
- What am I fixing for me vs. for the user?
- Dependency check
- Does fixing X automatically fix Y?
- What's the root issue vs. symptoms?
Decision Rule: Identify the 2-3 changes that create 80% of the improvement. Everything else is polish.
Output: Prioritized short list (max 3-5 items).
Phase 3: SPECIFY (Make it concrete)
Goal: Turn vague critiques into specific fixes.
Cognitive Moves:
- Write the fix, not the problem
- Bad: "This section is unclear"
- Good: "Replace paragraph 2 with: [exact new text]"
- Additive vs. Subtractive
- Am I adding something missing, or removing something harmful?
- Subtractive fixes are often higher leverage
- Time-box test
- Can I implement this fix in <5 minutes?
- If not, break it down further
- Show the delta
- Before: [what it says now]
- After: [what it should say]
Output: Specific, actionable fixes with concrete language.
Phase 4: VALIDATE (Did it work?)
Goal: Confirm improvement, catch regressions.
Cognitive Moves:
- The use test
- Would I actually use this improved version?
- Does it solve the problem better?
- Complexity check
- Did I make it more complex or more useful?
- Complexity without value = regression
- Fresh eyes pass
- Read from the beginning as if first time
- What's still confusing?
- Completion test
- What's still missing after fixes?
- Is another loop needed, or is this good enough?
Decision Rule: Stop when additional iteration yields diminishing returns. "Good enough to ship" beats "perfect but stuck."
Output: Go/no-go decision. Either ship it or run another loop.
Anti-Patterns
Critique theater: Listing issues to look thorough without prioritizing. 20 minor issues ≠ useful critique.
Perfectionism spiral: Running infinite loops. Know when to stop.
Vague complaints: "This could be better" without specifying how. Not actionable = not useful.
Scope creep: Critique becomes redesign. Stay focused on improving THIS thing, not building something new.
Critique without creation: Tearing down without building up. Always pair problems with solutions.
When to Use Each Phase
| Situation | Start At |
| First draft review | Phase 1 (full scan) |
| Quick polish | Phase 3 (already know what's wrong) |
| Major revision | Phase 1 → full loop |
| Final check | Phase 4 only |
Integration
This skill pairs with:
- An expansion pass first (widen the idea), then critique
- A polish pass after (critique catches what polish hides)
- Any output that needs iteration before shipping
Example Application
Input: A skill document that tells WHAT to do but not HOW.
IDENTIFY:
- Modes are descriptive, not procedural
- No cognitive moves, just labels
- CHALLENGE section is weak relative to importance
- Missing INVERT mode
RANK:
- Add cognitive HOW (highest impact)
- Strengthen CHALLENGE (weak + important)
- Add INVERT (easy + valuable)
SPECIFY:
- For each mode, add "Cognitive Moves:" with 3-4 specific mental operations
- Add attack checklist to CHALLENGE with concrete questions
- Add INVERT mode with 4 cognitive moves, ~10 lines
VALIDATE:
- Each mode now executable by novice? ✓
- CHALLENGE has teeth? ✓
- INVERT adds value without bloat? ✓
- Ship it.
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.