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
- Identify dimensions relevant to this work (functionality, reliability, UX, code quality, security, performance, maintainability — pick 3-5 most relevant).
- Score each dimension 1-10 with one-line justification.
- Calculate overall — weighted by importance to the user's goal, not equal average.
- 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.
- Name the next point — the single highest-leverage action to gain +1 on overall score.
Output Contract
Return:
dimensions — 3-5 scored dimensions with justificationoverall_score — weighted overall 1-10ceiling — max reachable score without redesignnext_point — single action for +1context — 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
1---2name: work-evaluator3description: Числовая оценка качества работы, кода, решения или продукта по шкале 1-10 с обоснованием по конкретным критериям. Использовать когда нужно объективно оценить текущее состояние, сравнить "до/после", или принять решение "достаточно ли хорошо чтобы двигаться дальше".4---56# Work Evaluator78## Goal910Give 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.1112## When To Use1314- User asks "оцени", "какую оценку дашь", "насколько это хорошо"15- After a major milestone to calibrate progress16- Before deciding "ship or iterate"17- Comparing current state to ideal state1819## Scoring Rubric2021| Score | Meaning | Ship? |22|---|---|---|23| 1-2 | Broken, doesn't work at basic level | No |24| 3-4 | Works but fundamentally flawed | No |25| 5 | Minimum viable, significant gaps | Maybe for internal |26| 6 | Functional with known limitations | Yes with caveats |27| 7 | Solid, production-worthy for current scope | Yes |28| 8 | Good, covers edge cases, well-structured | Yes, confidently |29| 9 | Excellent, few improvements possible | Yes |30| 10 | Best-in-class, would recommend as reference | Yes |3132## Calibration Rules3334- **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.35- **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.36- **Never give round numbers without justification.** "7/10" alone is lazy. Why 7 and not 6 or 8?37- **Distinguish dimensions.** A project can be 8/10 on code quality but 4/10 on UX. Give the overall AND the breakdown.3839## Process40411. **Identify dimensions** relevant to this work (functionality, reliability, UX, code quality, security, performance, maintainability — pick 3-5 most relevant).422. **Score each dimension** 1-10 with one-line justification.433. **Calculate overall** — weighted by importance to the user's goal, not equal average.444. **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.455. **Name the next point** — the single highest-leverage action to gain +1 on overall score.4647## Output Contract4849Return:501. `dimensions` — 3-5 scored dimensions with justification512. `overall_score` — weighted overall 1-10523. `ceiling` — max reachable score without redesign534. `next_point` — single action for +1545. `context` — what "good" means for this user/project5556## Anti-Patterns5758- Giving 7-8 to everything — this means your scale is broken59- Scoring high on potential instead of current state60- Ignoring dimensions the user didn't ask about but that matter (security, reliability)61- Changing score to match user expectations after pushback — defend your assessment62- Averaging dimensions equally when one is clearly dominant
Alubiama