# Skill Test Spec: /start ## Skill Summary `/start` is the first-time onboarding skill for new projects. It guides the user through naming the project, choosing a game engine, and setting up the initial directory structure. It creates stub configuration files (CLAUDE.md, technical-preferences.md) and then routes to `/setup-engine` with the chosen engine as an argument. Each file or directory created is gated behind a "May I write" ask, following the collaborative protocol. The skill detects whether a project is already configured and whether a partial setup exists, offering to resume or restart as appropriate. It has no director gates — it is a utility setup skill that runs before any agent hierarchy exists. --- ## Static Assertions (Structural) Verified automatically by `/skill-test static` — no fixture needed. - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools` - [ ] Has ≥2 phase headings - [ ] Contains verdict keywords: COMPLETE, BLOCKED - [ ] Contains "May I write" collaborative protocol language for each config file - [ ] Has a next-step handoff at the end (routes to `/setup-engine`) --- ## Director Gate Checks None. `/start` is a utility setup skill. No director agents exist yet at the point this skill runs. --- ## Test Cases ### Case 1: Happy Path — Fresh repo, no engine, full onboarding flow **Fixture:** - Empty repository: no CLAUDE.md overrides, no `production/stage.txt`, no `technical-preferences.md` content beyond placeholders - No existing design docs or source code **Input:** `/start` **Expected behavior:** 1. Skill detects no existing configuration and begins fresh onboarding 2. Skill asks for project name 3. Skill presents 3 engine options: Godot 4, Unity, Unreal Engine 5 4. User selects an engine 5. Skill asks "May I write the initial directory structure?" 6. Skill creates all directories defined in `directory-structure.md` 7. Skill asks "May I write CLAUDE.md stub?" and writes it on approval 8. Skill routes to `/setup-engine [chosen-engine]` to complete technical config **Assertions:** - [ ] Project name is captured before any file is written - [ ] Exactly 3 engine options are presented - [ ] "May I write" is asked for each config file individually - [ ] No file is written without explicit user approval - [ ] Handoff to `/setup-engine` occurs at the end with the chosen engine argument - [ ] Verdict is COMPLETE after all files are written and handoff is issued --- ### Case 2: Already Configured — Detects existing config, offers to skip or reconfigure **Fixture:** - `technical-preferences.md` has engine already set (not placeholder) - `production/stage.txt` exists with `Concept` **Input:** `/start` **Expected behavior:** 1. Skill reads `technical-preferences.md` and detects configured engine 2. Skill reports: "This project is already configured with [engine]" 3. Skill presents options: skip (exit), reconfigure engine, or reconfigure specific sections 4. If user selects skip: skill exits cleanly with a summary of current config 5. If user selects reconfigure: skill proceeds to the engine-selection step **Assertions:** - [ ] Skill does NOT overwrite existing config without user choosing reconfigure - [ ] Detected engine name is shown to the user in the status message - [ ] User is offered at least 2 options (skip or reconfigure) - [ ] Verdict is COMPLETE whether user skips or reconfigures --- ### Case 3: Engine Choice — User picks Godot 4, routes to /setup-engine godot **Fixture:** - Fresh repo — no existing configuration **Input:** `/start` **Expected behavior:** 1. Skill presents engine options and user selects Godot 4 2. Skill writes initial stubs (directory structure, CLAUDE.md) after approval 3. Skill explicitly routes to `/setup-engine godot` as the next step 4. Handoff message clearly names the engine and the next skill invocation **Assertions:** - [ ] Handoff command is `/setup-engine godot` (not generic `/setup-engine`) - [ ] Handoff is issued after all initial stubs are written, not before - [ ] Engine choice is echoed back to user before writing begins --- ### Case 4: Interrupted Setup — Partial config detected, offers resume or restart **Fixture:** - Directory structure exists (was created) but `technical-preferences.md` is still all placeholders (engine was never chosen — setup was interrupted) - No `production/stage.txt` **Input:** `/start` **Expected behavior:** 1. Skill detects partial state: directories exist but engine is unconfigured 2. Skill reports: "A partial setup was detected — directories exist but engine is not configured" 3. Skill offers: resume from engine selection, or restart from scratch 4. If resume: skill skips directory creation, proceeds to engine choice 5. If restart: skill asks "May I overwrite existing structure?" before proceeding **Assertions:** - [ ] Partial state is correctly identified (directories present, engine absent) - [ ] User is offered resume vs. restart choice — not forced into one path - [ ] Resume path skips re-creating directories (no redundant "May I write" for structure) - [ ] Restart path asks for permission to overwrite before touching any files --- ### Case 5: Director Gate Check — No gate; start is a utility setup skill **Fixture:** - Any fixture **Input:** `/start` **Expected behavior:** 1. Skill completes full onboarding flow 2. No director agents are spawned at any point 3. No gate IDs (CD-*, TD-*, AD-*, PR-*) appear in the output **Assertions:** - [ ] No director gate is invoked during the skill execution - [ ] No gate skip messages appear (gates are absent, not suppressed) - [ ] Skill reaches COMPLETE without any gate verdict --- ## Protocol Compliance - [ ] Asks for project name before any file is written - [ ] Presents engine options as a structured choice (not free text) - [ ] Asks "May I write" separately for directory structure and for CLAUDE.md stub - [ ] Ends with a handoff to `/setup-engine` with the engine name as argument - [ ] Verdict is clearly stated (COMPLETE or BLOCKED) at end of output --- ## Coverage Notes - The case where the user rejects all engine options and provides a custom engine name is not tested — the skill is designed for the three supported engines only. - Git initialization (if any) is not tested here; that is an infrastructure concern outside the skill boundary. - Solo vs. lean mode behavior is not applicable — this skill has no gates and mode selection is irrelevant.