pixelheros/CCGS Skill Testing Framework/skills/utility/start.md

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.