# Work Evaluator

> Числовая оценка качества работы, кода, решения или продукта по шкале 1-10 с обоснованием по конкретным критериям. Использовать когда нужно объективно оценить текущее состояние, сравнить "до/после", или принять решение "достаточно ли хорошо чтобы двигаться дальше".

- Skill: `alubiama/work-evaluator` (Agent Skill)
- Install (CLI): `npx skillmds@latest add alubiama/work-evaluator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alubiama/work-evaluator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Alubiama (https://skillmd.com/u/alubiama)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/alubiama/work-evaluator

---


# Work Evaluator

## Goal

Give an honest, calibrated numeric score (1-10) for any work product — code, architecture, UX, plan, skill, document. The score must be actionable: the user should understand exactly WHY it's a 6 and not an 8, and WHAT would make it an 8.

## When To Use

- User asks "оцени", "какую оценку дашь", "насколько это хорошо"
- After a major milestone to calibrate progress
- Before deciding "ship or iterate"
- Comparing current state to ideal state

## Scoring Rubric

| Score | Meaning | Ship? |
|---|---|---|
| 1-2 | Broken, doesn't work at basic level | No |
| 3-4 | Works but fundamentally flawed | No |
| 5 | Minimum viable, significant gaps | Maybe for internal |
| 6 | Functional with known limitations | Yes with caveats |
| 7 | Solid, production-worthy for current scope | Yes |
| 8 | Good, covers edge cases, well-structured | Yes, confidently |
| 9 | Excellent, few improvements possible | Yes |
| 10 | Best-in-class, would recommend as reference | Yes |

## Calibration Rules

- **Anchor to the user's context**, not to ideal software. A solo dev's side project at 7/10 is different from a FAANG service at 7/10.
- **Never give 10.** If you think it's a 10, you missed something. Give 9 and explain what would need to be true for 10.
- **Never give round numbers without justification.** "7/10" alone is lazy. Why 7 and not 6 or 8?
- **Distinguish dimensions.** A project can be 8/10 on code quality but 4/10 on UX. Give the overall AND the breakdown.

## Process

1. **Identify dimensions** relevant to this work (functionality, reliability, UX, code quality, security, performance, maintainability — pick 3-5 most relevant).
2. **Score each dimension** 1-10 with one-line justification.
3. **Calculate overall** — weighted by importance to the user's goal, not equal average.
4. **Name the ceiling** — what's the maximum score this work CAN reach without a redesign? If ceiling is 7, no amount of polishing makes it 9.
5. **Name the next point** — the single highest-leverage action to gain +1 on overall score.

## Output Contract

Return:
1. `dimensions` — 3-5 scored dimensions with justification
2. `overall_score` — weighted overall 1-10
3. `ceiling` — max reachable score without redesign
4. `next_point` — single action for +1
5. `context` — what "good" means for this user/project

## Anti-Patterns

- Giving 7-8 to everything — this means your scale is broken
- Scoring high on potential instead of current state
- Ignoring dimensions the user didn't ask about but that matter (security, reliability)
- Changing score to match user expectations after pushback — defend your assessment
- Averaging dimensions equally when one is clearly dominant