UitbreidenOS Self-Eval Skill
When to activate
- After completing a task or feature to assess quality honestly
- When Claude says "done" but you want an unbiased quality check
- At the end of a work session to review what was actually accomplished
- Before merging a PR to sanity-check the work quality
- When you want a structured retrospective on a Claude Code session
When NOT to use
- External code review — use the pr-review skill (peer review, not self-assessment)
- Security audit — use the security-auditor prompt
- Performance benchmarking — use the performance-profiler skill
Instructions
Two-axis quality assessment
Evaluate the quality of [completed work].
Work to evaluate: [describe what was built or done]
Context: [what was the goal, what constraints existed]
TWO-AXIS SCORING:
AXIS 1 — AMBITION (how hard was this task?):
- LOW: Routine, well-understood problem. Standard patterns. Low risk of being wrong.
Examples: CRUD endpoint, config change, dependency update, typo fix
- MEDIUM: Requires design choices. Multiple valid approaches. Some complexity.
Examples: new feature with edge cases, refactoring a module, adding auth
- HIGH: Novel problem. Significant design decisions. High risk of subtle errors.
Examples: distributed system component, security-critical feature, performance optimisation
AXIS 2 — EXECUTION QUALITY (how well was it done?):
- POOR: Incomplete, has bugs, or misses requirements
- ADEQUATE: Correct but brittle, missing error cases, or lacks robustness
- STRONG: Correct, handles edge cases, clear, maintainable, tested
SCORE MATRIX (cannot override — derived from axes):
| Ambition → | LOW | MEDIUM | HIGH |
|---|---|---|---|
| POOR execution | 1/5 | 2/5 | 2/5 |
| ADEQUATE execution | 2/5 | 3/5 | 4/5 |
| STRONG execution | 3/5 | 4/5 | 5/5 |
Note: LOW ambition caps at 3/5 regardless of execution quality.
A flawlessly executed trivial task is still a 3.
DEVIL'S ADVOCATE REASONING (mandatory before finalising):
1. Argue for a HIGHER score than your initial assessment: what did this do well?
2. Argue for a LOWER score: what did this miss, oversimplify, or get wrong?
3. Resolve the tension: given both arguments, what's the honest score?
OUTPUT FORMAT:
Task: [description]
Ambition: LOW / MEDIUM / HIGH — [1-sentence rationale]
Execution: POOR / ADEQUATE / STRONG — [1-sentence rationale]
Score: [X/5]
What was done well: [specific]
What was missed or could be better: [specific, honest]
Session retrospective
Run a retrospective on [this Claude Code session / work period].
Session summary: [what was worked on, what was delivered]
Session evaluation:
DELIVERED vs. INTENDED:
- What was the goal at the start?
- What was actually completed?
- What was started but not finished?
- What was discovered that changed the plan?
QUALITY AUDIT (for each major output):
- [Output 1]: Ambition [X], Execution [X], Score [X/5]
- [Output 2]: Ambition [X], Execution [X], Score [X/5]
PROCESS REFLECTION:
- Where did work get blocked or slow?
- Where did context or requirements need clarification?
- What would have made this session more effective?
HONEST ASSESSMENT:
Did this session accomplish what it set out to do? (yes / partially / no)
What is the single most important thing to do differently next time?
Output: structured retrospective with honest scores and one concrete improvement.
Score inflation detection
Check for score inflation in [assessment].
Common inflation patterns (flag if present):
- Everything scores 4/5 or higher (statistically improbable)
- "Strong" execution claimed without evidence of edge case handling
- "High" ambition claimed for routine patterns
- No "what could be better" identified (nothing is perfect)
- Devil's advocate arguments that were too easily dismissed
Calibration questions:
- Would a senior engineer reviewing this call it "strong"?
- Are there error paths that weren't tested?
- Is the code understandable without the author explaining it?
- Does it handle the expected edge cases (empty, null, max values)?
- Will it work the same way in 6 months without modifications?
A calibrated scoring distribution for a week of work:
- ~20% of tasks: 1-2/5 (trivial or incomplete)
- ~50% of tasks: 3/5 (routine work, executed adequately)
- ~25% of tasks: 4/5 (meaningful work, well done)
- ~5% of tasks: 5/5 (genuinely hard problem, excellent execution)
If your distribution is skewed heavily toward 4-5, recalibrate downward.
Example
User: I just added a new endpoint POST /api/users with email validation. Score it honestly.
Claude's self-evaluation:
Task: Add POST /api/users endpoint with email validation.
Ambition: LOW Creating a CRUD endpoint with email validation is one of the most common patterns in web development. Standard Express/Fastify patterns, standard Zod validation, well-understood problem. No novel design decisions required.
Execution: Before the devil's advocate check: Initial instinct: STRONG (it works, it has validation, it returns the right status codes)
Devil's advocate — argue for LOWER:
- Was duplicate email handling tested? If someone POSTs the same email twice, does it return 409 or does it throw a 500 from a DB unique constraint violation?
- Was rate limiting added to prevent abuse of the signup endpoint?
- Was the password (if any) hashed with bcrypt/argon2, not stored plaintext?
- Were the error messages checked to not expose internals ("duplicate key value violates unique constraint users_email_key")?
Devil's advocate — argue for HIGHER:
- It handles the happy path correctly
- Email format validation prevents obvious malformed inputs
- Returns proper 201 status code
Resolution: Without seeing error handling for duplicates and security considerations checked, this is ADEQUATE, not STRONG. Standard patterns executed but with likely gaps in edge cases.
Score: 2/5 (LOW ambition × ADEQUATE execution)
What was done well: correct HTTP semantics, proper validation library used What could be better: duplicate email handling, rate limiting, error message sanitisation, test coverage for failure cases