conventional-impact

Convert completed engineering work into evidence-backed impact summaries and manager updates.

Updated May 27, 2026
One-click install
npx skills add https://github.com/ybaspinar/agent-work-skills --skill conventional-impact-ybaspinar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: conventional-impact
Source: https://github.com/ybaspinar/agent-work-skills/tree/main/skills/conventional-impact
Command: npx skills add https://github.com/ybaspinar/agent-work-skills --skill conventional-impact-ybaspinar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineers often finish tickets but struggle to communicate the value of their work in MR descriptions, sprint reviews, manager updates, release notes, and performance reviews, leading to vague claims or invented metrics. ## Core Features & Use Cases - Annotation Grammar: Provides grep-friendly @impact, @metric, @evidence, @risk, @decision, and @followup tags to capture impact while work is fresh. - Structured Impact Summary: Produces a complete Ticket Impact Summary with problem, changes, quantification table, validation evidence, demo script, release note, and performance-review bullet. - Anti-Fabrication Guardrails: Enforces rules against inventing metrics, requiring explicit before/after notation and "Not measured" labels when data is missing. - Use Case: After finishing a poster export feature, aggregate your @impact annotations and test evidence into a manager-ready summary with a quantification table showing presets went from 1 -> 4. ## Quick Start Ask the assistant to summarize your completed ticket using the conventional-impact skill, providing your diff, commit notes, and any @impact annotations.

Frequently Asked Questions about conventional-impact

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write an impact summary for a completed engineering ticket?

Collect the ticket title, diff summary, commits, review comments, tests, and any @impact annotations, then separate facts into impact, metrics, evidence, decisions, and risks. Translate implementation details into user, product, or operational value, and quantify only what the source data supports.

How do I write performance review bullets from my engineering work?

Capture impact while the work is fresh using annotations like @impact, @metric, and @evidence in code comments or ticket notes. At review time, aggregate these into one durable accomplishment bullet per project, grounded in measurable before/after changes and reproducible evidence.

What should I write when no performance metrics were measured?

State "Not measured" or "No performance measurement was taken" explicitly instead of implying improvement. Never convert missing data into claims like faster or reduced latency; place unverified ideas under "Possible metric to verify" instead.

What are @impact annotations and how do I use them?

They are grep-friendly tags like @impact(scope), @metric(scope), and @evidence(scope) placed in code comments, commit bodies, or MR drafts to record value as you work. Common scopes include user, product, perf, api, frontend, backend, ops, and security.

When should I not use impact annotations in manager-facing output?

Raw @impact or @evidence tags should not leak into manager-facing summaries unless explicitly requested. Translate them into plain English first, and always list incomplete work as follow-ups rather than hiding it.