skills/goals/SKILL.md
OKRs and contribution goals — writing, cascading, scoring, and individual goal setting. Use when: setting team OKRs, writing individual contribution goals, cascading company OKRs to team level, coaching someone on goal quality, preparing for OKR reviews, scoring OKRs at end of cycle, or linking contribution goals to team OKRs. Covers both team-level OKRs and individual contribution goal frameworks.
npx skillsauth add michaelsvanbeek/personal-agent-skills goalsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
| System | Scope | Where It Lives | Audience | |--------|-------|----------------|----------| | Team OKRs | Team-level outcomes for the quarter | Planning docs, shared trackers | Team, PM, leadership | | Contribution Goals | Individual's commitments for the cycle | Goal-tracking system (e.g., Workday, Lattice, 15Five) | Employee, manager, HR |
Both follow the same quality bar: specific, measurable, outcome-oriented, and time-bound. Contribution goals should cascade from team OKRs — they are an individual's slice of the team's commitments.
An objective is what the team wants to achieve:
Good: "Establish our platform as the most reliable in the industry" Bad: "Improve uptime SLA metrics by optimizing infrastructure monitoring and alerting"
A key result is how you measure progress:
Good: "Reduce P1 incident count from 8/quarter to 2/quarter" Bad: "Implement better monitoring" (activity, not outcome)
Objective: <What we want to achieve>
KR1: <Metric from X to Y>
KR2: <Metric from X to Y>
KR3: <Binary: Ship X by date>
Aim for 2–4 objectives with 2–5 key results each per team per quarter.
Company OKR
└─ Org OKR (how this org contributes)
└─ Team OKR (how this team contributes)
└─ Contribution Goal (how this person contributes)
Rules:
Contribution goals are entered into your goal-tracking system by the employee. They should read like individual OKRs — specific to that person's involvement in team priorities.
Before submitting a goal, apply this test:
If ten people read your goal and independently assessed whether you achieved it, would they all reach the same conclusion?
If reasonable people could disagree about whether the goal was met, it's too vague. Sharpen it.
If you might have a similar goal last quarter or next quarter, what makes THIS quarter different?
Goals should reflect the specific context, deliverables, and impact of the current cycle. "Improve code quality" is evergreen and therefore useless. "Reduce escaped defects in the payments service from 12/quarter to 3/quarter" is anchored to now.
| Category | % of Goals | Examples | |----------|-----------|---------| | Delivery / Business Impact | 50–60% | Ship feature X, improve metric Y by Z% | | Technical / Craft | 20–30% | Reduce tech debt in service A, establish testing practices | | Growth / Development | 10–20% | Lead a project end-to-end, mentor a junior engineer | | Team / Culture | 0–10% | Improve onboarding docs, drive hiring for a role |
Each goal needs:
## Goal: [Title]
### Description
[What will be done and why it matters — 1-2 sentences]
### Success Criteria
- [ ] [Specific, measurable outcome — passes the unambiguity test]
- [ ] [Specific, measurable outcome]
### Alignment
Supports: [Team OKR or business priority]
### Target
[Quarter or specific date]
Mid-level Engineer:
Senior Engineer:
Staff Engineer:
| Mistake | Problem | Fix | |---------|---------|-----| | "Improve reliability" | Not measurable — improve how much? | "Reduce P1 incidents from 8 to 2 per quarter" | | "Work on the migration" | Activity, not outcome | "Complete phase 1 migration: 3 services on new platform by Q2" | | "Be a better mentor" | Vague, fails unambiguity test | "Mentor [Name] through their first feature lead; they ship independently by end of quarter" | | "Support the team" | Evergreen, no differentiation | "Drive adoption of contract testing; 80% of inter-service calls covered by Q2" | | Same goal every quarter | Fails differentiation test | Anchor to THIS quarter's specific deliverables |
| Check | ✓ | |-------|---| | Objective is qualitative and directional | | | Objective fits in one sentence | | | Each KR has a baseline ("from X") and target ("to Y") | | | KRs measure outcomes, not activities | | | KRs are within the team's control | | | 2–5 KRs per objective | | | 2–4 objectives per team | | | At least one KR is a stretch | |
| Check | ✓ | |-------|---| | Passes the unambiguity test (10 assessors agree) | | | Passes the differentiation test (specific to this quarter) | | | Has quantified success criteria | | | Aligned to a team OKR or stated business priority | | | Has a target date | | | Tracked in goal-tracking system | |
| Score | Meaning | |-------|---------| | 0.0–0.3 | Failed to make meaningful progress | | 0.4–0.6 | Made progress but fell short | | 0.7–0.9 | Hit or came close — the sweet spot | | 1.0 | Fully achieved (if all KRs score 1.0, you aimed too low) |
Assessed during performance review cycles:
| Rating | Criteria | |--------|---------| | Exceeded | Delivered beyond the stated success criteria | | Met | Achieved what was committed | | Partially Met | Made progress but fell short on key criteria | | Not Met | Significant gaps |
| When | Activity | |------|----------| | Quarter start (Week 1–2) | Draft team OKRs; employees write contribution goals | | Monthly | Check-in: update KR progress, flag risks | | Mid-quarter | Formal mid-cycle review — on track? Goal adjustments? | | Quarter end | Score team OKRs, assess contribution goals, feed into next cycle |
| Anti-Pattern | Fix | |-------------|-----| | Task masquerading as KR | Measure the outcome, not the activity | | Sandbagging | At least one KR should be a genuine stretch | | No baseline | Always include current state: "from X to Y" | | Set and forget | Monthly check-ins at minimum | | Contribution goals copied from OKRs | Personalize: what is THIS person's specific slice? | | Goals too vague to measure | Apply the unambiguity and differentiation tests |
development
TypeScript coding standards and type safety conventions. Use when: creating TypeScript files, defining interfaces and types, writing type-safe code, reviewing TypeScript for type correctness, auditing a codebase for type safety gaps, eliminating any or ts-ignore usage, or improving strict-mode compliance. Covers strict typing, avoiding any and ts-ignore, discriminated unions, Zod runtime validation, immutability patterns, and proper type definitions.
testing
Writing clear, actionable tickets in any issue tracker (Jira, Linear, GitHub Issues, ServiceNow, etc.). Use when: creating epics, stories, tasks, bugs, or spikes; writing acceptance criteria; decomposing work for a sprint; linking dependencies between tickets; auditing backlog items for clarity; or coaching a team on ticket quality. Covers title conventions, description templates, acceptance criteria, decomposition rules, dependency linking, and org-specific pluggable configuration.
development
Testing strategy, patterns, and evaluation for software and LLM/AI systems. Use when: writing tests, choosing test boundaries, designing test data, structuring test suites, evaluating LLM outputs, building evaluation pipelines, setting coverage thresholds, auditing test coverage gaps in existing projects, or improving test quality and structure.
development
Writing effective status updates for different audiences and cadences. Use when: writing a weekly status update, preparing a monthly summary, drafting a quarterly review, sending updates to leadership, sharing progress with stakeholders, or improving the clarity and impact of team communications. Covers weekly, monthly, and quarterly formats tailored for upward, lateral, and downward communication.