/initiative-kickoff

The moment you decide to start something new is when it's cheapest to make it real — an outcome, an owner, success you can check, and a first step — instead of a vague intention that never lands. This turns "we should do X" into a project that can actually begin.

It is for non-product initiatives — a hire, a partnership, a GTM push, an ops or strategy bet. Spec'ing a product feature is product-brief; checking on projects already running is project-health.

Step 1 — Frame the initiative

Get these crisp, asking only what's genuinely missing (don't interrogate a well-formed brief):

• Outcome — what "won / done" actually looks like, in one line.
• Why now — the reason this is worth starting today.
• Scope / not-scope — one line each, so it doesn't sprawl.

Step 2 — Success criteria

Name 2–4 checkable signals that say it worked — concrete and verifiable, not vanity ("signed 3 design-partner LOIs by end of Q3", not "build momentum"). If the user offers only fuzzy aims, sharpen them into something you could actually check later.

Step 3 — Owner and stakeholders

Name the owner (accountable) and the people involved. Link existing person pages via lookup_person; for people without a page, follow the vault's entity_creation setting (auto/suggest/off) rather than hard-creating.

Step 4 — Ladder to pillars and goals

Infer the pillar it serves (from System/pillars.yaml; never assume a fixed set). Then check get_quarterly_goals — if a current goal fits, offer to link it via confirm_goal_link. If nothing fits, say so and record it as a standalone bet — never manufacture a goal link that isn't real.

Step 5 — First concrete steps (confirm-gated)

Draft the 3–5 next actions that get it moving. Offer to turn them into tasks — nothing is created without per-item confirmation. For each approved one, call create_task (carry the owner, the initiative as source; infer the pillar), then read back the created task IDs. A failed create_task is reported as not created, never counted as done.

Step 6 — Create the project page, then confirm

Write the project page to 04-Projects/ with the outcome, why-now, scope, success criteria, owner/stakeholders, pillar/goal link (or "standalone"), and the next steps. Then confirm by reading back the page path, the created task IDs, and the goal link. Never report "kicked off" without those in hand.

Quality bar

A good kickoff leaves a real project page with a crisp outcome, checkable success criteria, a named owner, an honest ladder to a pillar/goal (or "standalone bet"), and the first steps captured as confirmed tasks — enough that the initiative can actually start, not a paragraph of aspiration.

Anti-patterns (do not do these)

• Spec'ing a product (that's product-brief) or reviewing existing projects (that's project-health).
• Manufacturing a goal link when the initiative doesn't ladder to a real one — say "standalone bet."
• Vanity success criteria you couldn't actually check later.
• Auto-creating tasks without per-item confirmation, or person pages against the entity_creation setting.
• Claiming "kicked off" without reading back the project-page path and created task IDs.

Degradation

• No quarterly goals set (or get_quarterly_goals unavailable) → skip the goal ladder, note it, record as standalone; never fabricate a goal.
• System/pillars.yaml absent → ask which area it serves rather than guessing a fixed pillar set.
• entity_creation: off/suggest → track/offer for new people, don't auto-create pages.
• A create_task call fails → report that item as not created; don't count it.

Track Usage (Silent)

Update System/usage_log.md to mark initiative-kickoff as used. Analytics (Silent): call track_event with event_name initiative_kicked_off and properties steps_created and linked_to_goal (count + boolean — no initiative name, no content). Fires only if the user opted into analytics; no action if it returns "analytics_disabled".