self-eval

---
name: self-eval
description: Use when a task, code review, or work session just finished and needs an honest, calibrated evaluation that resists score inflation and forces devil-advocate reasoning.
category: Engineering
version: 1.0.0
tools: []
---

# Self-Eval: Honest Work Evaluation

Produce honest, calibrated evaluations of completed work, replacing the default tendency to rate everything 4/5 with a two-axis scoring system, mandatory devil's-advocate reasoning, and anti-inflation awareness.

The core insight: self-assessment converges to "everything is a 4" because a single-axis score conflates task difficulty with execution quality. Separate the two axes, then combine them through a fixed matrix that cannot be overridden by picking a number first and rationalizing it.

## When Invoked

Review the conversation to identify what was accomplished, or use the specific piece of work named by the requester. Summarize the work in one sentence before scoring anything.

## Two-Axis Scoring

Rate each axis independently, then read the matrix — never pick a composite number first and justify it backward.

**Axis 1 — Task Ambition** (what was attempted, not how well): Low (1) — safe, familiar, routine, no real risk of failure (minor config changes, simple refactors, copy-paste with small modifications, anything you were confident you'd complete before starting). Medium (2) — meaningful work with novelty or challenge, partial failure was possible (new feature implementation, integrating an unfamiliar API, architectural changes, debugging a tricky issue). High (3) — ambitious, unfamiliar, or high-stakes, real risk of complete failure (building something from scratch in an unfamiliar domain, complex system redesign, performance-critical optimization, shipping to production under pressure). Self-check: if you were confident of success before starting, ambition is Low or Medium, not High.

**Axis 2 — Execution Quality** (how well it was done, independent of ambition): Poor (1) — major failures, incomplete, wrong output, or abandoned mid-task; the deliverable doesn't meet its own stated criteria. Adequate (2) — completed but with gaps, shortcuts, or missing rigor; did the thing but left obvious improvements on the table. Strong (3) — well-executed, thorough, quality output; no obvious improvements left undone given the scope.

**Composite score matrix** (read it, don't override it):

|                        | Poor Exec (1) | Adequate Exec (2) | Strong Exec (3) |
|------------------------|:---:|:---:|:---:|
| Low Ambition (1)       |  1  |  2  |  2  |
| Medium Ambition (2)    |  2  |  3  |  4  |
| High Ambition (3)      |  2  |  4  |  5  |

Key properties: low ambition caps at 2 — safe work done perfectly is still safe work. A 5 requires both high ambition and strong execution, and should be rare. High ambition plus poor execution scores 2 — bold failure hurts. The most common honest score for solid work is 3 (medium ambition, adequate execution). The devil's-advocate step below can cause a re-rated axis, but never a direct override of the matrix result.

## Devil's Advocate (mandatory, ≥3 sentences)

Before writing the final score, argue all three of these explicitly:

1. **Case for LOWER** — why might this deserve a lower score? What was easy, what was avoided, what was less ambitious than it appears? Would a skeptical reviewer agree with the axis ratings?
2. **Case for HIGHER** — why might this deserve a higher score? What was genuinely challenging, surprising, or exceeded the original plan?
3. **Resolution** — if either case reveals a mis-rated axis, re-rate it and recompute the matrix result; then state the final score with a justification addressing at least one point from each case.

A devil's-advocate section under 3 sentences total means it isn't engaging with the exercise — go deeper.

## Anti-Inflation Check

Amara has no persistent file storage across sessions, so score history lives in the conversation: if earlier scores from this same conversation or session are visible, check whether 4+ of the last 5 are identical, and flag it explicitly — "Warning: score clustering detected. Consider whether you're anchoring to a default." If no prior scores are visible in context, ask instead: "Would an outside observer rate this the same way?" If the user maintains their own score log elsewhere, invite them to paste recent scores so the check can run properly next time.

## Output Format

```
## Self-Evaluation

**Task:** [1-sentence summary of what was attempted]
**Ambition:** [Low/Medium/High] — [1-sentence justification]
**Execution:** [Poor/Adequate/Strong] — [1-sentence justification]

**Devil's Advocate:**
- Lower: [why it might deserve less]
- Higher: [why it might deserve more]
- Resolution: [final reasoning]

**Score: [1-5]** — [1-sentence final justification]
```

## Examples

**Feature work** — "Added cursor-based pagination to the user list API": Ambition Medium (established pattern, but real backwards-compatibility constraint supporting both offset and cursor modes); Execution Strong (all tests pass, edge cases handled, existing clients unaffected). Devil's advocate: lower case notes the pattern was copied with minor changes (arguably Low); higher case notes the backwards-compat requirement added real complexity beyond copy-paste; resolution keeps Medium ambition. **Score: 4** — solid execution on meaningful work with real constraints.

**Bug fix** — "Fixed a race condition in checkout causing duplicate orders": Ambition Medium (required debugging across 3 services to find root cause); Execution Adequate (fix works, but the test only covers the exact reported scenario, not the general class of race conditions). Devil's advocate: lower case notes the eventual fix was a single-line mutex, trivial once found; higher case notes the cross-service investigation was real work; resolution keeps Medium ambition but drops execution to Adequate since a more thorough fix would address the pattern, not just the instance. **Score: 3** — good debugging work but the fix is narrow.