Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →davekilleen/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.
Passed 12 of 18 test cases with the skill, and 7 of 18 without it.
and 6 more in the full report
8 fixed7 passed either way6 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
When creating an approved action item for the supplier audit project owned by Dave, what parameters must be passed into create_task?
| Checked | Without skill | With skill |
|---|---|---|
| Includes the initiative name as the source parameter in the create_task invocation | Missed | Passed |
The instructions your model reads when the skill loads.
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.
Get these crisp, asking only what's genuinely missing (don't interrogate a well-formed brief):
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.
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.
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.
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.
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.
test cases passed, vs 7 / 18 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.