Performance Review Skill

Write structured, balanced performance reviews from bullet-point inputs.

Performance Review Skill — The Skill Playground: pick the Executive Update skill, fill in a few notes, hit run, and watch a structured executive… (from the mohitagw15856/pm-claude-skills README)

From the mohitagw15856/pm-claude-skills README — shows the whole collection, not only this skill. · view on GitHub

How to use it

Claude Code
  1. Run the line below. It pulls the whole folder into ~/.claude/skills/performance-review.
  2. Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit mohitagw15856/pm-claude-skills/skills/performance-review#main ~/.claude/skills/performance-review

For one project only, change the path to .claude/skills/performance-review.

Claude (web or desktop app)
  1. On this page open ⋯ → Download .md.
  2. Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
  3. Pick the file and Save. Claude shows the name and description and runs a security scan.
  4. Check the skill is switched on.
  5. Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
  1. ChatGPT: make a Project and paste it into Instructions.
  2. Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
  • Check which app you pasted it into — the steps above name the right one.
  • Some skills need the paid tier of Claude or ChatGPT.
Step-by-step guide with screenshots · Ask in the forum

Paste into Claude, ChatGPT or Cursor.

Source of Performance Review Skill

Show the full text129 lines
namedescription
performance-reviewWrite 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

Deeper Materials

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

Anti-Patterns

  • Do not inflate positive language to avoid difficult feedback — growth areas must be clearly stated, not buried
  • Do not include feedback that isn't supported by specific examples — every development point needs evidence
  • Do not write a review that only covers what happened in the last month — the full review period must be considered
  • Do not omit development goals — a review without forward-looking guidance is incomplete
  • Do not use language that could be read as discriminatory — avoid references to personality traits unrelated to work performance

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]"
1---
2name: performance-review
3description: "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."
4---
5 
6# Performance Review Skill
7 
8This 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.
9 
10## Required Inputs
11 
12Ask the user for these if not provided:
13- **Review type** (Self-assessment / Manager review / Peer/360 / Upward feedback)
14- **Review period** (e.g. H1 2025, Q2 2025, Annual)
15- **Name of person being reviewed** (or "myself" for self-assessment)
16- **Role / level**
17- **Key achievements or notable work** (rough notes are fine)
18- **Areas where they struggled or could improve** (be honest — reviews without growth areas aren't credible)
19- **Key projects or deliverables from the period**
20- **Company values or competencies to assess against** (optional — if provided, structure the review around them)
21- **Overall rating/recommendation** (if the form requires one)
22 
23## Output Structure
24 
25---
26 
27# Performance Review: [Name]
28**Role:** [Title / Level]
29**Review period:** [Period]
30**Review type:** [Manager / Self / Peer / Upward]
31**Reviewed by:** [If known]
32 
33---
34 
35## Overall Summary
36 
37[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.]
38 
39---
40 
41## Achievements & Impact
42 
43[3–5 achievements, each structured as:]
44 
45**[Achievement title — specific and concrete]**
46[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.]
47 
48---
49 
50## Strengths Demonstrated
51 
52[3–4 bullet points. Each bullet = one strength, with one concrete example from the review period. No abstract traits without evidence.]
53 
54- **[Strength]:** [Example — specific project or behaviour that demonstrated this]
55 
56---
57 
58## Areas for Growth
59 
60[2–3 areas. Be direct and constructive — not vague. Frame as "opportunity to develop" not "failure." Each should include:]
61 
62**[Area name]**
63- **Observed pattern:** [What was noticed — be specific, not personal]
64- **Why it matters:** [Impact on team, output, or career progression]
65- **Suggested development:** [One concrete action — e.g. "Take on [X] responsibility next half" or "Shadow [role] on [process]"]
66 
67---
68 
69## Development Goals for Next Period
70 
71[2–3 goals. Format each as:]
72 
73**Goal [N]:** [Clear, outcome-oriented goal]
74- **Why:** [Connection to growth areas or career aspirations]
75- **How to measure:** [What "done" looks like]
76- **Support needed:** [Resources, training, or manager input required]
77 
78---
79 
80## Competency Ratings (if framework provided)
81 
82| Competency | Rating | Evidence |
83|---|---|---|
84| [Competency from company framework] | [Exceeds / Meets / Developing / Below] | [One-sentence example] |
85 
86---
87 
88## Closing Recommendation
89 
90[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.]
91 
92---
93 
94## Writing Rules
95 
96- Never use vague phrases: "strong communicator," "team player," "hardworking" — always back with evidence
97- Growth areas must be honest — reviewers who only write positives lose credibility and help no one
98- Use third person for manager/peer reviews, first person for self-assessments
99- Avoid jargon — "drove alignment" and "leveraged synergies" are meaningless. Use plain language.
100- If the user gives sparse notes, ask for one concrete example per achievement before writing
101 
102## Deeper Materials
103 
104- [`references/evidence-not-adjectives.md`](references/evidence-not-adjectives.md) — the adjective→evidence substitution table and the calibration rules that keep files honest
105 
106## Quality Checks
107 
108- [ ] Every achievement includes a specific outcome (not just activity)
109- [ ] Strengths have concrete examples from the review period
110- [ ] Growth areas are honest and constructive (not softened to meaninglessness)
111- [ ] Development goals are measurable
112- [ ] No vague phrases without evidence
113- [ ] Tone is professional and fair throughout
114 
115## Anti-Patterns
116 
117- [ ] Do not inflate positive language to avoid difficult feedback — growth areas must be clearly stated, not buried
118- [ ] Do not include feedback that isn't supported by specific examples — every development point needs evidence
119- [ ] Do not write a review that only covers what happened in the last month — the full review period must be considered
120- [ ] Do not omit development goals — a review without forward-looking guidance is incomplete
121- [ ] Do not use language that could be read as discriminatory — avoid references to personality traits unrelated to work performance
122 
123## Example Trigger Phrases
124 
125- "Write a performance review for [name] based on these notes: [paste notes]"
126- "Help me write my self-assessment for [period]"
127- "Draft a peer review for my colleague who did [description]"
128- "Turn these bullet points into a full performance review: [paste bullets]"
129 

Discussion

Alternatives

Also in MonitoringSee all 533 in Development →
Professional Full-Stack Developer for Network Mapping & Monitoring ApplicationAct as a professional full-stack developer tasked with building a web application for mapping and monitoring networks using Mikrotik Netwatch API. Implement multi-user role-based management to handle devices, monitor their status, and manage user subscriptions.Coding · CC0-1.0Prompt refinerHigh-end Prompt Engineering & Prompt Refiner skill. Transforms raw or messy user requests into concise, token-efficient, high-performance master prompts for systems like GPT, Claude, and Gemini. Use when you want to optimize or redesign a prompt so it solves the problem reliably while minimizing tokens.Data & AI · CC0-1.0Constraint driven developmentEstablishes a project's quality bar as a written contract and stops agents quietly lowering it. Interviews the user on which dimensions matter, supplies sane default thresholds when they have no number in mind, records everything in CONSTRAINTS.md, and watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down. Use when no quality bar is written down, when the user says "set up constraints" or "define our standards", when the user wants dimensions they care about — accessibility, web performance, coverage — set up as enforced constraints, when an agent keeps silencing checks or skipping tests to get to green, when you need a coverage or performance threshold and don't know what number to pick, or when an agent writes more code than anyone will read.Coding · MITObservability and instrumentationInstruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.Coding · MIT