메뉴
Use when reviewing, critiquing, or improving OKRs for a product or delivery team. Triggers on requests to review OKRs, check if key results are measurable, improve KR quality, or validate an OKR set before a planning cycle.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | review-okrs |
| description | Use when reviewing, critiquing, or improving OKRs for a product or delivery team. Triggers on requests to review OKRs, check if key results are measurable, improve KR quality, or validate an OKR set before a planning cycle. |
The user is part of the ACIL team at carsales. Objectives are fixed — do not create, rename, or reword them. The user will provide KRs (sometimes delivery-focused). Your job is to:
Never invent objectives. Never hallucinate KR context. If a KR cannot be confidently mapped, say so and ask.
| # | Objective |
|---|---|
| O1 | To increase participation and engagement across AG Tools and ecosystems to support JTBD |
| O2 | To improve dealer productivity and platform efficiency |
| O3 | To expand revenue and platform growth |
| O4 | To expand carsales ecosystem through new partnerships |
Mapping logic:
If a KR contains any of these words, it is an output disguised as a result:
launch · ship · deliver · deploy · implement · build · complete · release · migrate (as the end goal) · ensure · improve (without a number)
Exception: "migrate" is acceptable as a KR when paired with a quality metric (e.g. "Migrate 100% of records with < 1% error rate").
A strong objective is:
Group KRs under their mapped ACIL objective. For each:
### O[1–4]: [ACIL Objective text]
**KR: [original KR text]**
Mapped to: O[N] — [one-line reason]
Quality: PASS / FAIL
Issue: [specific problem, or "none"]
Rewrite: [concrete replacement with baseline → target, or "no change needed"]
After all KRs, add:
## Summary
- [N] KRs pass · [N] fail
- Mapping: O1 [n] · O2 [n] · O3 [n] · O4 [n]
- Patterns: [e.g. "All KRs are outputs — no outcomes measured"]
- Top fix: [the single most important change]
- Unmapped: [any KRs you couldn't confidently assign — flag for user to confirm]
When rewriting a failed KR:
[TBC] if unknown), and a target[Metric] from [baseline] to [target] by end of quarterExamples:
| Original (Fail) | Rewrite (Pass) |
|---|---|
| Ship call transcript feature | % of completed calls with enrichment summary saved to profile: [TBC] → 60% |
| Launch after-hours auto-response | Median response time to after-hours enquiries: [TBC] → reduce by 70% |
| Ensure data quality is good | Post-migration mandatory field completion rate: [TBC] → ≥ 95% |
| Increase dealer satisfaction | Dealer CSAT score: [TBC] → [target] (define measurement method first) |
| Check | Pass criteria |
|---|---|
| Number of objectives | 2–3 per team per quarter |
| KRs per objective | 2–4 (max 5) |
| Initiatives listed as KRs | Flag and move to initiatives list |
| All KRs traceable to objective | Each KR should visibly move the objective needle |
| Baselines confirmed | Flag [TBC] items as blockers before quarter starts |
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when executing implementation plans with independent tasks in the current session