메뉴
Write a clear, structured pull request description from a git diff, branch summary, or commit list. Use when asked to write a PR description, draft a pull request, or document code changes. Produces a description with summary, motivation, changes made, testing steps, and reviewer guidance.
SOC 직업 분류 기준
Apply prioritisation frameworks (RICE, MoSCoW, Kano, ICE, Opportunity Scoring) to rank features and backlog items. Use when asked to prioritise features, rank a backlog, decide what to build next, or evaluate tradeoffs between competing ideas. Produces a scored, ranked feature list with framework-specific tables, recommended build order, deprioritised items, and assumptions made.
Generate structured developer handoff annotations for a Figma screen or component. Use when asked to write Figma annotations, create dev handoff notes, document a Figma design for developers, or write specs for a screen. Produces a complete annotation set covering interactions, states, spacing, accessibility, and edge cases.
Audit a Figma component library for consistency, coverage gaps, and naming issues. Use when asked to audit components, review a design system, check component consistency, identify missing components, or assess Figma library health. Produces a structured audit report with issues prioritised by impact, naming recommendations, and a fix plan.
Write a structured design brief for a Figma design task from a product requirement or feature request. Use when asked to write a design brief, create a design spec for Figma, turn a PRD into design requirements, or brief a designer on what to build in Figma. Produces a brief with goals, scope, user flows, components needed, constraints, and success criteria.
Runs a PM-perspective design critique focused on product outcomes and user goals, not aesthetics. Use when asked for a PM design critique, a product review of a Figma design, or feedback from a product perspective without needing to be a designer. Produces structured outcome-based feedback tied to user goals, business metrics, and requirement coverage.
Runs a pre-handoff QA checklist on a Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, or validate a Figma file is ready to build. Produces a structured QA report covering file hygiene, component usage, accessibility, and handoff readiness with explicit pass/fail status per item. Optimised for Opus 4.7 and newer models.
| name | pr-description-writer |
| description | Write a clear, structured pull request description from a git diff, branch summary, or commit list. Use when asked to write a PR description, draft a pull request, or document code changes. Produces a description with summary, motivation, changes made, testing steps, and reviewer guidance. |
Writes structured, reviewer-friendly pull request descriptions from a diff, commit list, or informal notes. Covers the what, why, and how-to-review so reviewers can start immediately.
Ask for these if not provided:
git log --oneline, or describe the changes in plain English)A clear, imperative-mood title under 72 characters:
[type]: [concise description of what changed]
Examples:
feat: add rate limiting to the public APIfix: resolve race condition in session expiryrefactor: extract payment logic into PaymentService2–3 sentences covering:
Bullet list of specific changes — one bullet per logical change, not per file:
[If UI change: include before/after screenshots or a screen recording] [If API change: include example request/response] [If no visual change and no API contract change: omit this section entirely — do not leave it as a placeholder]
Step-by-step instructions a reviewer can follow:
Include any specific commands, test data, or environment flags needed.
Flag anything that warrants extra attention: