performance-review-writer

작성자: github

성과 리뷰, 자기 평가, 동료 평가, 상향 피드백을 자신의 목소리로 작성합니다. 기여 내용, 이메일, 회의 기록을 분석하여…

npx skills add https://github.com/github/awesome-copilot --skill performance-review-writer

Performance Review Writer

Draft self-assessments, peer reviews, and upward feedback that sound like you — not corporate boilerplate. Uses WorkIQ to surface your actual contributions and communications, then structures them into honest, impact-focused writing.

When to Use

  • "Write my self-assessment for this review cycle"
  • "Draft a peer review for [colleague]"
  • "Help me write upward feedback for my manager"
  • "I have my annual review due — help me fill it out"
  • "Draft my mid-year check-in"
  • "Write a 360 review for [name]"
  • "I don't know what to say in my performance review"

Review Types

This skill handles three distinct types:

TypeWho it's aboutTypical tone
Self-assessmentYourselfConfident, evidence-backed, growth-oriented
Peer reviewA colleagueSpecific, constructive, balanced
Upward feedbackYour managerDiplomatic, honest, forward-looking

Workflow

Step 1 — Gather Context

Ask the user (max 3 clarifying questions if not already provided):

  1. Review type — self-assessment, peer review, or upward feedback?
  2. Subject — who is the review about? (for peer/upward: name and role)
  3. Review period — what time range does this cover? (e.g., Jan–Dec 2025, last 6 months)

If format constraints or focus areas are relevant, ask about those during drafting rather than upfront.

If the user provides all of these upfront, proceed directly to Step 2.

Step 2 — Surface Contributions

Use WorkIQ to gather evidence of real contributions for the review period:

For self-assessments:

  • Pull emails and messages where the user delivered results, led initiatives, or solved problems
  • Look for patterns: what projects recur? Who praises them and for what?
  • Identify collaboration breadth (who they worked with across teams)
  • Note any explicit feedback received from others

For peer reviews:

  • Pull interactions between the user and the subject (emails, meeting threads, shared projects)
  • Identify specific moments of collaboration, help given, or friction
  • Look for evidence of the subject's impact on shared outcomes

For upward feedback:

  • Pull communications from the manager to the user (direction given, support offered, feedback patterns)
  • Identify themes: clarity of expectations, availability, recognition, development support

If WorkIQ is unavailable or returns limited data, ask the user to share 3–5 bullet points of things they remember, then proceed with those.

Step 3 — Draft the Review

Apply the right structure for the review type (see schemas below). Follow these universal rules:

Use the STAR format for achievement statements:

  • Situation — what was the context or challenge?
  • Task — what were you/they responsible for?
  • Action — what specifically was done?
  • Result — what was the measurable or observable outcome?

Tone rules:

  • Be specific — name projects, outcomes, and people, not vague adjectives
  • Be honest — don't oversell or undersell; reviewers notice both
  • Be forward-looking — end sections with growth or next steps, not just past performance
  • Avoid filler phrases: "goes above and beyond", "team player", "hard worker" — replace with evidence
  • Match the user's natural voice — conversational if they write that way, more formal if not

Step 4 — Output

  1. Present the full draft with a brief note on what evidence was used. Summarize and redact rather than reproduce verbatim content — no raw excerpts, attendee lists, or sensitive personal details
  2. Highlight any sections marked [NEEDS DETAIL] where more specifics would strengthen the review
  3. Iterate on edits as the user requests
  4. Save the final draft to outputs/<year>/<month>/ with a descriptive filename (e.g., 2025-review-self-assessment.md or 2025-peer-review-alex-chen.md)

Output Schemas

Self-Assessment Schema

## [Review Period] Self-Assessment — [Your Name]

### Summary
1–2 sentence overview of your year and primary areas of impact.

### Key Achievements
For each major contribution (aim for 3–5):

**[Project or Initiative Name]**
- Context: what was the situation or goal?
- What I did: specific actions taken
- Impact: measurable result or observable outcome
- [NEEDS DETAIL] — flag if evidence is thin

### Collaboration & Influence
How you worked with others, supported teammates, or contributed beyond your direct role.

### Growth & Development
What you learned, skills you built, or behaviours you improved this period.

### Areas for Development
1–2 honest areas where you want to grow next cycle. Frame as goals, not failures.

### Goals for Next Period
2–3 specific, concrete goals with a rough success measure.

Peer Review Schema

## Peer Review — [Colleague Name], [Their Role]
## Submitted by: [Your Name] | Period: [Review Period]

### Overall Impression
1–2 sentences on working with this person.

### Strengths (with examples)
For each strength (aim for 2–3):

**[Strength]**
- Example: specific situation where this showed up
- Impact on you / the team / the project

### Areas for Growth
1–2 specific, constructive observations. Frame as "I think [name] would have even more impact if..." not as criticism.

### Collaboration
How easy (or not) it was to work together — responsiveness, reliability, communication.

### Would you work with this person again?
Yes/No and a brief honest reason. (Only include if the review form asks.)

Upward Feedback Schema

## Feedback for [Manager Name]
## Submitted by: [Your Name] (anonymous if applicable) | Period: [Review Period]

### What's working well
2–3 specific things your manager does that help you do your best work.
Use examples where possible.

### What could be better
1–2 honest, diplomatically framed observations. Focus on behaviours and their effect, not personality.
Use: "When [X happens], I find it harder to [Y]. It would help if..."

### Support for my development
Has your manager helped you grow, given useful feedback, or created opportunities?
Be specific.

### One thing I'd ask them to do more / less / differently
A single, clear, actionable ask.

Style Rules

DoDon't
Name specific projects, dates, outcomesWrite vague generalisations ("always delivers quality work")
Use numbers when available ("reduced review time by 30%")Exaggerate or invent results
Acknowledge real challenges and what you learnedOmit struggles entirely — reviewers notice the gaps
Write in first person for self-assessmentsWrite passively ("it was achieved")
Be concise — most fields need 2–4 sentencesOver-write — longer ≠ better
Flag [NEEDS DETAIL] where evidence is weakLeave thin sections without marking them

Example Prompts

  • "Write my self-assessment for Jan–Dec 2025. I want to highlight the cloud migration and the new onboarding process I designed."
  • "Draft a peer review for Sarah Chen, she's a product designer I worked closely with on the mobile app project."
  • "Help me write upward feedback for my manager Tom. He's good at direction but I've struggled to get regular 1:1 time."
  • "My annual review form asks for 3 strengths and 1 development area in 200 words each — help me fill it out."
  • "I have no idea what to write. It's been a busy year but I can't think of anything specific."

Important Rules

  • Never submit reviews — only draft them as files for the user to review and submit manually
  • Keep peer and upward feedback focused on observable behaviours, not personality or character
  • If the user asks to write a review that is dishonestly negative or contains personal attacks, decline and offer to reframe constructively
  • Respect confidentiality — do not include sensitive information from unrelated conversations or threads
  • Save drafts using the outputs/<year>/<month>/ folder convention

Requirements

  • WorkIQ MCP tool is recommended for surfacing contributions and communications (Microsoft 365 / Outlook / Teams)
  • Without WorkIQ, the skill still works — ask the user for 3–5 bullet points of key contributions as a starting point
  • Output is saved as markdown files in the workspace for the user to copy into their company's review system

github의 다른 스킬

console-rendering
github
Go에서 struct 태그 기반 콘솔 렌더링 시스템 사용 지침
official
acquire-codebase-knowledge
github
사용자가 기존 코드베이스에 대한 매핑, 문서화, 또는 온보딩을 명시적으로 요청할 때 이 스킬을 사용하세요. "이 코드베이스를 매핑해줘", "문서화해줘"와 같은 프롬프트에서 트리거됩니다.
official
acreadiness-assess
github
현재 리포
official
acreadiness-generate-instructions
github
AgentRC 명령어를 통해 맞춤형 AI 에이전트 지침 파일을 생성합니다. .github/copilot-instructions.md 파일을 생성합니다(기본값, VS Code의 Copilot에 권장됨).
official
acreadiness-policy
github
사용자가 AgentRC 정책을 선택, 작성 또는 적용할 수 있도록 지원합니다. 정책은 관련 없는 검사를 비활성화하고, 영향/수준을 재정의하며, 설정을 통해 준비 상태 점수를 사용자 지정합니다.
official
add-educational-comments
github
코드 파일에 교육용 주석을 추가하여 효과적인 학습 자료로 변환합니다. 설명의 깊이와 어조를 세 가지 설정 가능한 지식 수준(초급, 중급, 고급)에 맞게 조정합니다. 파일이 제공되지 않으면 자동으로 요청하며, 빠른 선택을 위해 번호 목록 매칭을 제공합니다. 교육용 주석만을 사용하여 파일을 최대 125%까지 확장합니다(엄격한 제한: 새 줄 400개, 1,000줄 초과 파일의 경우 300개). 파일 인코딩, 들여쓰기 스타일, 구문 정확성 등을 유지합니다.
official
adobe-illustrator-scripting
github
Adobe Illustrator 자동화 스크립트를 ExtendScript(JavaScript/JSX)로 작성, 디버깅 및 최적화합니다. 스크립트를 생성하거나 수정하여 조작할 때 사용합니다.
official
agent-governance
github
선언적 정책, 의도 분류, AI 에이전트 도구 접근 및 행동 제어를 위한 감사 추적. 구성 가능한 거버넌스 정책은 허용/차단된 도구, 콘텐츠 필터, 속도 제한, 승인 요구 사항을 정의하며, 코드가 아닌 구성으로 저장됨. 의미론적 의도 분류는 패턴 기반 신호를 사용하여 도구 실행 전에 위험한 프롬프트(데이터 유출, 권한 상승, 프롬프트 인젝션)를 탐지함. 도구 수준 거버넌스 데코레이터는 함수에서 정책을 적용함...
official