# Initiative Kickoff > Turn a decision to start something new — a hire, a partnership, a go-to-market push, an internal bet — into a real initiative: the outcome and why now, what success looks like, who's involved, the first concrete steps, and a project page that ladders to your pillars and goals. Use when the user says 'let's kick off X', 'I'm starting a new initiative', 'set up a project for this', or 'we've decided to do Y'. Also use proactively when the user commits to a new effort mid-conversation. Not for spec'ing a product feature or writing a PRD; use `product-brief`. Not for checking the status of projects already underway; use `project-health`. - Skill: `davekilleen/initiative-kickoff-2` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add davekilleen/initiative-kickoff-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/davekilleen/initiative-kickoff-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: davekilleen (https://skillmd.com/u/davekilleen) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/davekilleen/initiative-kickoff-2 --- # /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".