--- name: project-kickoff description: "Full session startup sequence for beginning a brand new project. Triggers automatically when user says /kickoff, 'start a new project', 'new project', 'let's build', or 'kickoff [project name]'. Orchestrates persistent-memory initialization, superpowers-workflow brainstorm, CEO review, and implementation planning in one structured pipeline so nothing gets built before it is properly scoped, planned, and reviewed." --- # Project Kickoff Trigger keyword: **/kickoff** Also activates on: "start a new project", "new project", "let's build [idea]", "kickoff [project name]", "I want to build [idea]" This skill runs the complete new project startup pipeline. It chains persistent-memory, superpowers-workflow, and gstack-engineering-team together so every project starts with a solid spec, a reviewed plan, and a memory file — before a single line of code is written. **The rule:** No code until the plan is approved. No plan until the spec is approved. No spec until the brainstorm is done. --- ## Step 1: Capture the Idea When the user says `/kickoff` or a variant: If a project name and description are included (e.g., `/kickoff my-saas-app — a tool that does X for Y users`), extract both and proceed. If only a name is given, ask: "What are we building? Give me 2-3 sentences: what it does, who uses it, and what problem it solves." If nothing is given, ask: "What's the project name and what are we building?" Do not ask multiple questions at once. One question, wait for the answer, then proceed. --- ## Step 2: Initialize Project Memory Create the memory file immediately so nothing gets lost. ```bash python3 /home/ubuntu/skills/persistent-memory/scripts/manage_memory.py init [project-name] ``` Then write the initial project overview into the memory file based on what the user described. Confirm: "Memory initialized for '[project-name]'. I will keep this updated throughout our sessions." --- ## Step 3: Brainstorm (Superpowers Stage 1) Enter brainstorm mode. The goal is to fully understand the problem before proposing any solution. Ask the following questions ONE AT A TIME. Wait for each answer before asking the next: 1. "Who is the primary user? Be specific — not 'developers' but 'solo founders who deploy to Vercel and want to avoid manual testing'." 2. "What is the single most important thing this product must do? The one thing that, if it did nothing else, would still make it worth building." 3. "What are you NOT building? What is explicitly out of scope for the first version?" 4. "What does success look like in 30 days? What would have to be true for you to say this was worth building?" 5. "What tech stack do you want to use, or should I recommend one based on the requirements?" After all 5 answers are collected, write a Brainstorm Summary into the memory file under the Architecture Decisions section. --- ## Step 4: Write the Spec Based on the brainstorm answers, write a concise product spec: ``` SPEC: [project-name] ==================== What it is: [one sentence] Primary user: [specific description] Core problem solved: [the job to be done] MVP Features (v1 only): 1. [Feature] — [why it is essential] 2. [Feature] — [why it is essential] 3. [Feature] — [why it is essential] Out of scope for v1: - [thing explicitly excluded] - [thing explicitly excluded] Success criteria (30 days): - [measurable outcome] - [measurable outcome] Tech stack: - Frontend: [choice and reason] - Backend: [choice and reason] - Database: [choice and reason] - Deployment: [choice and reason] ``` Present the spec and ask: "Does this spec look right? Say 'approved' to continue to planning, or tell me what to change." Do NOT proceed until the user approves the spec. Save the approved spec to the memory file. --- ## Step 5: CEO Review on the Spec Before writing the implementation plan, run the CEO persona from gstack-engineering-team on the approved spec. Evaluate: - Is the scope right for a v1? Too small (leaving value on the table) or too large (ocean-boiling)? - Is the user value clear and specific? - Is the success criteria measurable? - Is anything obviously missing that would make v1 useless? Report: ``` CEO REVIEW: [project-name] spec ================================ Verdict: [APPROVED / ADJUST SCOPE / WRONG DIRECTION] Scope assessment: [what the spec covers vs what it should] User value: [how clearly the user benefit is defined] Recommendation: [what to change, if anything] ``` If the CEO verdict is ADJUST SCOPE or WRONG DIRECTION, present the suggested changes and ask the user to approve before continuing. --- ## Step 6: Write the Implementation Plan (Superpowers Stage 2) Write a detailed, phased implementation plan. Every task must have: - Exact file paths (no "create a component", but "create `src/components/LoginForm.tsx`") - Actual code snippets for non-obvious implementations - Exact commands with expected output - A failing test written BEFORE the implementation (TDD) - No TBD, no placeholders, no "figure this out later" Plan format: ``` IMPLEMENTATION PLAN: [project-name] ===================================== Phase 1: [Foundation] — [what this phase achieves] Task 1.1: [exact task with file path] Test first: [the failing test to write] Implementation: [the code to write] Command: [exact command to verify it works] Task 1.2: ... Phase 2: [Core Feature] — [what this phase achieves] ... Phase 3: [Polish + Ship] — [what this phase achieves] ... ``` Present the plan and ask: "Does this plan look right? Say 'approved' to start building, or tell me what to change." Save the approved plan to the memory file. --- ## Step 7: Engineering Review on the Plan Before writing any code, run the Engineering Manager persona from gstack-engineering-team on the approved plan. Check: - Are all tasks concrete with no TBD steps? - Is TDD enforced on every task? - Are there any architectural red flags? - Is the phase order logical (no task depends on something built later)? Report: ``` ENG REVIEW: [project-name] plan ================================= Verdict: [APPROVED / NEEDS WORK] Plan quality: [assessment of concreteness and completeness] TDD coverage: [is every task test-first?] Architecture flags: [any concerns] Approved to build: [YES / NO — fix X first] ``` --- ## Step 8: Kickoff Complete Once both the spec and plan are approved, give the user the session ready confirmation: ``` KICKOFF COMPLETE: [project-name] ================================== Memory: Initialized and populated Spec: Approved Plan: Approved ([N] phases, [N] tasks) TDD: Enforced READY TO BUILD. Starting with Phase 1, Task 1.1. Commands available throughout this project: /resume — reload full context at the start of any future session /review — code review on any file or recent changes /qa — QA test the current feature /cso — security audit /ship — pre-ship checklist before deploying /end — compress and save this session to memory ``` Then immediately begin Phase 1, Task 1.1 — write the failing test first. --- ## Reference Files - See `references/kickoff-patterns.md` for handling common kickoff scenarios (vague ideas, scope creep, tech stack decisions)