メニュー
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 職業分類に基づく
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
| 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 |