| name | goal-setting |
| description | PM-GATED ceremony that converts raw vision (UI sketches, feature wishlists, enthusiasm) into ratified OKRs plus scaffolded spinoff stubs. Dispatches the VP-Product Reviewer as full OKR critic before any artifact lands on disk. Exit: goal artifact(s) + spinoff-roadmap-creator stubs pre-tagged to the goal. Triggers — 'set goals for this quarter', 'I have a vision for X', 'let's OKR this'. |
| description-budget | 300 |
| version | 1.0.0 |
| user-invocable | true |
Goal-Setting — Vision to OKRs to Spinoff Stubs
Posture (load-bearing): vision-in, OKR-out. Neither obsequious rubber-stamp nor idea-crushing gate — the job is "put enough definition on this that we can win together." Each KR must be weekly-perceptible (can an agent or PM observe it move this week?). KRs that fail this test are later-impact aspirations, not measurement handles; surface them as shaping questions, not rejection verdicts.
Two entry points:
- Direct invocation — the PM arrives with raw vision: UI sketches, a feature wishlist, enthusiasm, a rough "I want us to do X this quarter." There is no formed OKR yet.
- Pickup-from-spinoff-goal — a
kind: spinoff-goal stub was deferred earlier (a vision-slice captured but not yet fleshed); the EM picks it up and runs this skill on the captured vision.
What this skill produces:
- A ratified OKR (one Objective + ≤5 Key Results, weekly-perceptible) in a
coordinator-doc-new --type goal artifact
kind: spinoff-roadmap-creator stubs pre-tagged to the goal, one per roadmap-worth-of-work — the building blocks the PM will later chain through /roadmap-planning- Optionally:
kind: spinoff-goal stubs for vision-slices identified but not yet fleshed (deferred vision capture, not deferred goal-setting)
- An OFFER to chain into
/roadmap-planning (PM-gated — offer, never auto-run)
This skill DOES NOT auto-author roadmap plans. It does not invoke `/roadmap-planning` without PM acknowledgment. It does not bypass the roadmap-planning PM gate. It scaffolds stubs and offers the chain. The PM decides whether and when to fire each stub.
When NOT to invoke
- Problem not yet converged (PM is still deciding what to build, not what to achieve) →
coordinator:shape or coordinator:brainstorming first.
- Single-feature scope (one plan, no broader OKR arc) → straight to
coordinator:plan.
- Roadmap already has goals (picking up an existing spinoff-roadmap-creator stub against an already-ratified goal) →
/roadmap-planning directly.
Ceremony
Step 1 — PM states Objective and candidate Key Results
The PM names:
- The Objective (qualitative, inspiring, direction-setting — what "winning" looks like)
- One or more candidate KRs (what movement means — ideally measurable; raw is fine at this stage)
Do NOT prompt for a specific format. Accept rough inputs. The ceremony imposes structure through critique, not intake.
Step 2 — Dispatch the VP-Product Reviewer as full OKR critic
Dispatch via Agent(subagent_type: "coordinator:vp-product", model: "opus").
The VP-Product Reviewer's OKR critique mandate — inline in the dispatch prompt verbatim:
You are the VP-Product Reviewer (VP of Product, they/them). You are reviewing a draft OKR set for strategic rigor. Your job is to act as a full OKR critic, not a rubber-stamp.
Assess:
- Is the Objective a real Objective? Qualitative, inspiring, direction-setting — not a metric disguised as a direction, not a tactic.
- Are the KRs real Key Results? Measurable outcomes that signal the Objective is being achieved — not activity metrics ("we shipped X"), not output proxies that can hit green while the Objective misses.
- Is the SET reasonable? ≤5 KRs per Objective. More than 5 means the Objective is unfocused or the team is spread too thin.
- Weekly-perceptibility test per KR: Can an agent or PM observe this KR move in a given week? If not, it is a "later-impact" aspiration — a shaping question, not a rejection. Flag it as such with a proposed rewrite that IS weekly-perceptible, or a note that the PM should decide whether to defer it to a future goal cycle.
Return: a structured critique with (a) verdict per element (PASS / FLAG / REJECT), (b) specific rewrite suggestions for flagged/rejected elements, (c) a SET-level verdict (GO / REVISE / REFRAME). Do not rewrite the entire OKR for the EM — give the EM and PM the material to revise it themselves.
Step 3 — EM+PM integrate the VP-Product Reviewer's critique in-dialogue
The VP-Product Reviewer's critique is a co-shaping input. The artifact does NOT exist on disk yet. The EM and PM work through:
- REJECT items: must either be rewritten to pass or dropped
- FLAG items: rewrite or consciously accept with a rationale (acceptable to carry a flagged KR if the PM understands the tradeoff)
- Weekly-perceptibility notes: either rewrite to weekly-perceptible or explicitly defer to a
kind: spinoff-goal stub for a future goal cycle
This step is a dialogue, not a unilateral EM rewrite. The EM presents the VP-Product Reviewer's critique, proposes a revised OKR shape, and asks the PM to confirm before moving to Step 4.
Do NOT proceed to Step 4 without explicit PM confirmation on the revised OKR.
Step 4 — Scaffold the goal artifact
Once the PM confirms the revised OKR:
coordinator-doc-new --type goal --title "<objective-slug>"
Fill the scaffold with:
objective: — the ratified Objective textkey_results: — the ratified KR list (≤5, weekly-perceptible)period: — the goal period (e.g., Q3-2026, week, sprint-name)status: active
Step 5 — Spawn spinoff stubs
5a. Spinoff-roadmap-creator stubs (one per roadmap-worth-of-work)
For each distinct roadmap the goal implies, scaffold one stub:
coordinator-doc-new --type spinoff \
--kind spinoff-roadmap-creator \
--goals "<goal-id>" \
--title "<roadmap-topic>"
What makes a roadmap-worth-of-work boundary? Roughly: one /roadmap-planning invocation, one coherent domain or capability arc, one squad's sprint sequence. When in doubt, err toward fewer, larger stubs — the PM can split at pickup; merged stubs are better than over-fragmented ones.
Each stub must carry:
kind: spinoff-roadmap-creatorgoals: FK pointing to the goal artifact created in Step 4deployment_state: awaiting_gate (awaiting PM fire)- A one-line
title that names the capability arc
5b. Spinoff-goal stubs for deferred vision-slices (optional)
When the ceremony surfaces vision-slices that are real aspirations but out-of-scope for this goal period — or KRs that failed the weekly-perceptibility test and the PM chose to defer rather than rewrite — capture each as a kind: spinoff-goal stub:
coordinator-doc-new --type spinoff \
--kind spinoff-goal \
--title "<deferred-vision-slice>"
Each stub carries:
kind: spinoff-goaldeployment_state: awaiting_gate- A brief body capturing the vision-slice verbatim (raw is fine — fidelity matters more than polish)
These stubs are the pickup-from-spinoff-goal entry point for a future goal-setting invocation. They are NOT roadmap stubs; they are vision preservation.
Step 6 — Offer the PM-gated chain
Surface:
"Goal artifact and {N} spinoff-roadmap-creator stub(s) scaffolded. Want me to chain into /roadmap-planning now to begin shaping the first roadmap, or do you want to review the stubs first?"
Wait for PM response. Do NOT invoke /roadmap-planning without explicit PM direction. The chain is an offer, not a pipeline step.
Step 7 — Commit goal + stubs
Once the PM confirms (chain or defer):
git add -- <goal-artifact-path> <stub-path-1> [<stub-path-N>]
git commit -m "goal-setting: ratify <objective-slug> + scaffold {N} spinoff stubs"
Scoped staging only — no blanket add.
Out of scope (architectural reasons)
- Roadmap authoring —
/roadmap-planning owns that; goal-setting produces the stubs that feed it, not the plans themselves. Auto-chaining bypasses the PM's sequencing authority over a multi-wave plan, which is a PM-altitude call.
- KR tracking infrastructure — cockpit-contract
goal.schema.json owns event emission; goal-setting scaffolds the artifact, not the tracking pipeline.
- Deferred-goal fleshing without PM pickup — a
kind: spinoff-goal stub is dormant until the PM picks it up via this skill's second entry point. Auto-fleshing deferred stubs without PM context re-entry violates the vision-in, OKR-out posture.
Skill-scaffold checklist (self-verify before reporting DONE)
