# Kickoff > Kickoff - Skill: `mirandaplayer1/kickoff` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add mirandaplayer1/kickoff` - Raw SKILL.md: https://api.skillmd.com/api/skills/mirandaplayer1/kickoff/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: mirandaplayer1 (https://skillmd.com/u/mirandaplayer1) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/mirandaplayer1/kickoff --- # Kickoff Purpose: A spec draft should not come from the user staring at a blank template and filling it in from thin air — it should be distilled from a brainstorming conversation. The user only needs to bring a rough idea; when the workflow skeleton (file templates) is missing, this skill sets it up along the way. **Gate: No implementation begins before the user approves the SPEC.md draft. Every project goes through this flow, no matter how simple — a simple project's spec can be a few sentences short, but it cannot be skipped. Projects "too simple to need a spec" are exactly where unexamined assumptions cause the most rework.** ## Steps 0. **Skeleton check and setup**: List the project folder contents and confirm the skeleton (`WORKFLOW.md`, `SPEC.md`, `DECISIONS.md`, `notes/`) is in place. If complete, go straight to step 1; if anything is missing, copy everything under this skill's `assets/` into the project root (preserving relative paths), with these rules — - **Never overwrite existing files**: ask about each name collision one by one, defaulting to skip; the user's work matters more than the template. - Existing `CLAUDE.md` → do not overwrite it or merge content; only append a single line `@WORKFLOW.md` at the end of the file (leave it untouched if the line is already there), and tell the user before appending. - **Copy faithfully**: do not "improve" the templates in assets along the way; templates evolve through each project's `/reflect` feedback, which the user then applies to this skill's assets by hand. - After setup, list the file tree to verify (`CLAUDE.md` contains `@WORKFLOW.md`), then continue straight into step 1 — the skills all live at the user level; no copies go into the project. - If the user only wants the skeleton and isn't ready to talk content yet, stop here, and note that they can say "I want to build X" later to continue. 1. **Hear the starting point**: Ask the user to say in a few sentences what they want to build, why now, and whether they have a vague picture or reference in mind. Don't press for details — get the raw material first. 2. **Explore**: Read existing material in the project folder (past work, data, notes); search the web when needed to learn domain conventions and comparable work. 3. **Scope assessment**: Before asking any questions, judge — is this idea one project, or several independent sub-projects (e.g. "course material + marketing site + signup system")? If the latter, help decompose first: what the independent parts are, how they relate, a suggested order — then proceed with only the first sub-project. Don't waste questions on the details of a project that should have been split in the first place. 4. **Brainstorm directions**: Propose three to five approaches, ordered from minimum-viable to most ambitious, each with one line on "under what conditions you'd pick this". **Put the recommended option first and explain why**, so the user can simply agree or push back. This step prevents scoping too narrow (missing a high-value approach) or too wide (never finishing). Label each direction with **the belief it bets on** (e.g. "this version assumes full coverage beats fast onboarding") — only when the belief is written down can the user argue with the belief instead of picking at the surface. When the user vetoes a direction, distill the veto into one line — "you rejected X, which means the real need is Y" — and, once confirmed, write it into the spec: reactions to options are themselves spec material. When the differences between approaches hinge on "how the industry solves this" and nobody knows yet, run `/scout` first to produce a comparison report, then come back to choose. When there are more than three directions, or the differences suit visual presentation, build a **single HTML comparison page** (saved to `notes/`): a side-by-side grid, each direction annotated with its trade-offs and when it applies, simple diagrams welcome, with a "copy my choice" button at the bottom that outputs the choice plus reasoning for the user to paste back into the conversation. 5. **Draft SPEC.md section by section**: Fill in each section following the chosen direction, **presenting each completed section and asking "does this look right so far?"** before writing the next (pace by complexity — simple sections can be batched) — - One-line goal, audience and context, in scope / out of scope: distilled from the conversation, in the user's own words. - Skeleton: propose proactively (directory structure, narrative arc, page flow), marked "first draft, pending confirmation". - Acceptance criteria: propose a verifiable definition of done. - Unknowns list: record every question that came up in conversation without a conclusion, in its corresponding quadrant. - Reference examples: any references mentioned in the conversation. 6. **Spec self-review**: After writing, scan the whole thing with fresh eyes and fix in place — - Placeholder scan: any "TBD", "to be filled in", or vague sentences left? - Consistency: do the sections contradict each other? Does the skeleton match the goal? - Scope check: is this spec still so big it should go back for decomposition? - Ambiguity check: can any sentence be read two ways? If so, pick one reading and pin it down. 7. **Approval and hand-off**: Ask the user to read the spec and approve it. Once approved, suggest running `/interview` next (to settle what's undecided) and then `/blindspot` (to scan for what hasn't been thought of); if the user requests changes, make them and rerun step 6. ## Principles - The first draft optimizes for speed, not completeness: loosely right beats precisely wrong; details are for the next two skills to converge. - Distill, don't invent: spec content must come from the conversation and the materials; anything the agent assumed on its own is labeled "assumption" and added to the unknowns list. - Scope proposals must include one "embarrassingly small" option — the minimum-viable version is often the right starting point; ruthlessly cut non-essential features from every direction (YAGNI). - All HTML output follows WORKFLOW.md "HTML output and interactive interfaces": embedded comment layer + "copy results" exit (ready-made snippet: `notes/html-comment-layer.html`).