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 s...
Scanned 9/2/2026
Install to Claude Code
npx -y skills add davekilleen/Dex --skill initiative-kickoff --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Initiative Kickoff?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/davekilleen-initiative-kickoff)More formats (shields.io, HTML) on the badges page.
---
name: initiative-kickoff
description: "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`."
---
<!-- Generated from `.claude/skills/initiative-kickoff/SKILL.md` by `scripts/generate-agents-skills.py`. Do not edit. -->
# /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".
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!