okr-coach — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited okr-coach (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
A coaching skill that helps users write, validate, and stress-test OKRs — from scratch or from an existing draft. The goal is OKRs that are doable, outcome-driven, and connected to real business value.
OKRs are not a template to fill out. They are a discipline — built the same way quality assurance is built into a product: from the start, not bolted on at the end.
The most common failure modes:
The golden rule: Less than 3 OKRs per cycle. Sharp focus. Built from evidence, not aspiration.
Identify where the user is and jump in:
Ask the user these questions one at a time. Do not overwhelm them with all questions at once.
"Are we setting OKRs at the company level, team level, or individual level?"
Coaching tip: Start with company or team level. Individual OKRs come later when the team is more practiced. If the goal is alignment, start at the top.
"Are these quarterly OKRs or annual?"
Coaching tip: Quarterly for short-term focus and learning. Annual for long-term direction. Both can coexist — annual sets the north star, quarterly moves toward it.
"What is the biggest problem you are trying to solve this cycle?"
This is the anchor. Everything else flows from a clear problem statement.
Help the user write an Objective that is:
Bad example: "Improve the product" Good example: "Make our onboarding experience so clear that new users succeed on their own"
Help the user write 2 to 3 Key Results per Objective that are:
Bad example: "Launch the new dashboard feature" (output) Good example: "Increase 30-day user retention from 40% to 60%" (outcome)
Run this on any draft OKR set before finalizing.
"If you achieve these OKRs, will the team be proud of the cycle?" If the answer is uncertain, the objective may be too small or too vague.
"Do any Key Results describe something being shipped or delivered rather than something changing?" If yes, rewrite them to reflect the change in user behavior, business metric, or outcome.
"Is there anything in this OKR set that is non-essential?" If something would not meaningfully move the business forward, remove it.
"Do the stakeholders who need to execute these OKRs know about them and agree on them?" OKRs written in a room without the people doing the work rarely survive contact with reality.
"On a scale of 1 to 10, how confident is the team that these are achievable?" Target: 6 to 7. Below 5 means the objective is too ambitious without support. Above 8 means it is not ambitious enough.
This is the most common gap in OKR writing. Use this when a user's Key Results feel flat or activity-based.
| Output | Outcome |
|---|---|
| We launched the feature | Users adopted the feature |
| We ran 10 customer interviews | We identified 3 unmet needs that changed roadmap direction |
| We hired 2 engineers | Engineering velocity increased by 30% |
| We published the report | Leadership used the findings to make a budget decision |
Ask: "What is supposed to change because of this work?" That change is the outcome. Write the Key Result around that.
Ask: "Who benefits, and how will we know they benefited?" That answer gives you the metric.
OKRs without a check-in rhythm are wishes. Help the user set one up.
Recommended structure:
When a user has a strategy but struggles to connect it to OKRs, use this bridge:
"What does success look like at the end of this cycle — not in terms of what you built, but in terms of what is different in the world?"
That answer becomes the Objective.
"How will you know that difference happened? What would you measure?"
Those answers become the Key Results.
If the user cannot answer these questions, the strategy is not clear enough yet. Help them clarify the strategy before writing OKRs.
references/okr-examples.md — Real-world OKR examples by function (Product, Marketing, Engineering, Sales)references/common-mistakes.md — The 10 most common OKR mistakes and how to fix themRead these when the user needs examples or is making a mistake that is covered there.
When presenting OKRs back to the user, use this structure:
OBJECTIVE: [Inspirational, qualitative direction]
KR1: [Measurable outcome with baseline and target]
KR2: [Measurable outcome with baseline and target]
KR3: [Measurable outcome with baseline and target — optional]
Cycle: [Q1 2026 / Annual 2026]
Level: [Company / Team / Individual]
Confidence: [X out of 10]
Next check-in: [Date or cadence]Always ask the user: "If you achieve these, will you be proud of this cycle?" before finalizing.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.