---
name: self-eval
description: "Honest work evaluation: score completed tasks on ambition and execution quality, run devil's advocate reasoning, and detect score inflation — avoid the 'everything is a 4/5' trap"
---

# 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

---

> **Work with us:** Claudient is backed by [Uitbreiden](https://uitbreiden.com/) — we build AI products and B2B solutions with developer communities.
> [uitbreiden.com](https://uitbreiden.com/) · [Reddit](https://www.reddit.com/r/uitbreiden/) · [YouTube](https://www.youtube.com/@UITBREIDEN)
