performance-review

$npx mdskill add mohitagw15856/pm-claude-skills/performance-review

This skill turns rough notes, bullet points, or bullet-point memories into a complete, professionally written performance review. Output is ready to submit or use as a strong first draft.

SKILL.md

.github/skills/performance-reviewView on GitHub ↗
---
name: performance-review
description: "Write structured, balanced performance reviews from bullet-point inputs. Use when asked to write a performance review, self-assessment, peer review, 360 feedback, or manager evaluation. Produces a complete, fair, professionally written review covering achievements, areas for growth, and development goals."
---

# Performance Review Skill

This skill turns rough notes, bullet points, or bullet-point memories into a complete, professionally written performance review. Output is ready to submit or use as a strong first draft.

## Required Inputs

Ask the user for these if not provided:
- **Review type** (Self-assessment / Manager review / Peer/360 / Upward feedback)
- **Review period** (e.g. H1 2025, Q2 2025, Annual)
- **Name of person being reviewed** (or "myself" for self-assessment)
- **Role / level**
- **Key achievements or notable work** (rough notes are fine)
- **Areas where they struggled or could improve** (be honest — reviews without growth areas aren't credible)
- **Key projects or deliverables from the period**
- **Company values or competencies to assess against** (optional — if provided, structure the review around them)
- **Overall rating/recommendation** (if the form requires one)

## Output Structure

---

# Performance Review: [Name]
**Role:** [Title / Level]
**Review period:** [Period]
**Review type:** [Manager / Self / Peer / Upward]
**Reviewed by:** [If known]

---

## Overall Summary

[3–5 sentences. High-level characterisation of the period. Acknowledge standout contributions. Be specific — use project names and outcomes, not vague praise. For self-assessments, this should reflect honestly on the period without underselling or overselling.]

---

## Achievements & Impact

[3–5 achievements, each structured as:]

**[Achievement title — specific and concrete]**
[2–4 sentences. What was the context? What did [name] do specifically? What was the measurable or observable outcome? Avoid generic praise — every sentence should be something only this person could have done.]

---

## Strengths Demonstrated

[3–4 bullet points. Each bullet = one strength, with one concrete example from the review period. No abstract traits without evidence.]

- **[Strength]:** [Example — specific project or behaviour that demonstrated this]

---

## Areas for Growth

[2–3 areas. Be direct and constructive — not vague. Frame as "opportunity to develop" not "failure." Each should include:]

**[Area name]**
- **Observed pattern:** [What was noticed — be specific, not personal]
- **Why it matters:** [Impact on team, output, or career progression]
- **Suggested development:** [One concrete action — e.g. "Take on [X] responsibility next half" or "Shadow [role] on [process]"]

---

## Development Goals for Next Period

[2–3 goals. Format each as:]

**Goal [N]:** [Clear, outcome-oriented goal]
- **Why:** [Connection to growth areas or career aspirations]
- **How to measure:** [What "done" looks like]
- **Support needed:** [Resources, training, or manager input required]

---

## Competency Ratings (if framework provided)

| Competency | Rating | Evidence |
|---|---|---|
| [Competency from company framework] | [Exceeds / Meets / Developing / Below] | [One-sentence example] |

---

## Closing Recommendation

[2–3 sentences. For manager reviews: overall assessment and any promotion/compensation recommendation. For self-assessments: what you're asking for or committing to. For peer reviews: one sentence on what it's like to work with this person.]

---

## Writing Rules

- Never use vague phrases: "strong communicator," "team player," "hardworking" — always back with evidence
- Growth areas must be honest — reviewers who only write positives lose credibility and help no one
- Use third person for manager/peer reviews, first person for self-assessments
- Avoid jargon — "drove alignment" and "leveraged synergies" are meaningless. Use plain language.
- If the user gives sparse notes, ask for one concrete example per achievement before writing

## Quality Checks

- [ ] Every achievement includes a specific outcome (not just activity)
- [ ] Strengths have concrete examples from the review period
- [ ] Growth areas are honest and constructive (not softened to meaninglessness)
- [ ] Development goals are measurable
- [ ] No vague phrases without evidence
- [ ] Tone is professional and fair throughout

## Example Trigger Phrases

- "Write a performance review for [name] based on these notes: [paste notes]"
- "Help me write my self-assessment for [period]"
- "Draft a peer review for my colleague who did [description]"
- "Turn these bullet points into a full performance review: [paste bullets]"

More from mohitagw15856/pm-claude-skills

SkillDescription
360-feedback-templateDesign a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
ab-test-plannerDesign statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
accessibility-auditGenerate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
account-planBuild a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.
aeo-optimizerOptimize an article for Answer Engine Optimization (AEO) — restructuring content so AI engines like ChatGPT, Perplexity, and Claude can extract, quote, and cite it. Rewrites headings as questions, drops 50-80 word answer capsules, audits paragraph length, and flags trust signals. Use when asked to AEO-optimize, make content AI-readable, improve AI citation chances, or adapt an article for answer engines.
ai-ethics-reviewConduct an ethical review of an AI or ML feature, model, or product. Use when asked to run an AI ethics review, assess AI risks, audit a model for bias, or produce an AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with prioritised mitigations.
ai-product-canvasStructure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
ambiguity-resolverStructure vague opportunities and unclear briefs into actionable one-page problem statements. Use when asked to clarify a vague brief, frame an undefined problem, make sense of an unclear opportunity, or when the user says 'we need to figure out what to do about X' or 'I've been asked to look into Y'. Produces a structured problem brief with reframed questions, scoped boundaries, and a minimum viable research plan.
api-docs-writerWrite clear, developer-facing API documentation. Use when asked to document an API endpoint, write API reference docs, create a developer guide, or turn a raw spec/Postman collection into documentation. Produces endpoint documentation with descriptions, parameters, request/response examples, and error codes.
api-versioning-strategyWrite an API versioning strategy document for a service or API platform. Use when asked to define versioning policy, plan API deprecation, classify breaking changes, or document version lifecycle. Produces a complete versioning strategy with breaking-change classification table, deprecation timeline, migration guide template, and client communication template.