---
description: Initialize a new specification with detailed project description
allowed-tools: Bash, Read, Write, Glob
argument-hint: <project-description>
---

# Spec Initialization

<background_information>
- **Role**: Establish the foundation for a new specification by generating a unique feature identifier and scaffolding the required directory and file structure.
- **Success Criteria**:
  - A meaningful, conflict-free feature name is derived from the project description
  - Specification directory and seed files are created without errors
  - The path forward to requirements generation is clearly communicated
</background_information>

<instructions>
## Core Task
Derive a unique feature name from the project description ($ARGUMENTS) and initialize the full specification scaffold.

## Execution Steps

1. **Absorb Steering Context**: Before touching any files, read the entire `{{SDD_DIR}}/steering/` directory:
   - Core files: `product.md`, `tech.md`, `structure.md`
   - Any additional custom steering files present
   - This step anchors the feature name and initial framing in real project knowledge

2. **Verify Name Uniqueness**: Inspect `{{SDD_DIR}}/specs/` for any existing directories whose names would conflict with the proposed feature name. If a conflict exists, append a numeric suffix (e.g., `-2`, `-3`) and inform the user.

3. **Create Spec Directory**: `{{SDD_DIR}}/specs/[feature-name]/`

4. **Bootstrap Files from Templates**:
   - Read `{{SDD_DIR}}/settings/templates/specs/init.json`
   - Read `{{SDD_DIR}}/settings/templates/specs/requirements-init.md`
   - Substitute placeholders before writing:
     - `{{FEATURE_NAME}}` → chosen feature name
     - `{{TIMESTAMP}}` → current ISO 8601 timestamp
     - `{{PROJECT_DESCRIPTION}}` → the exact text of $ARGUMENTS
   - Write `spec.json` and `requirements.md` into the new spec directory

5. **Post-Init Integrations**: After files are written, check each steering file for any integration directives tied to the `spec-init` lifecycle event and execute them exactly as described.

## Important Constraints
- Initialization only — do not generate requirements, design, or tasks at this step
- Keep phases strictly separated; each phase gate exists to allow human review
- Only initialization and steering-directed post-init actions are performed here
</instructions>

## Tool Guidance
- Use **Glob** to scan existing spec directories before settling on a name
- Use **Read** to load `init.json` and `requirements-init.md` templates
- Use **Write** to persist `spec.json` and `requirements.md` after placeholder substitution
- Validate all substitutions before any write

## Output Description
Report in the language specified by `spec.json` using the following structure:

1. **Feature Name**: `kebab-case-name` with 1–2 sentences explaining the derivation logic
2. **Project Summary**: One sentence capturing the core intent
3. **Created Files**: Bulleted list showing full paths of each written file
4. **Next Step**: Code block containing `/sdd:spec-requirements <feature-name>`
5. **Phase Note**: 2–3 sentences reinforcing why only initialization was performed at this stage

**Formatting Rules**:
- Markdown headings (##, ###) for structure
- Commands wrapped in fenced code blocks
- Total output under 250 words
- Professional, declarative tone matching `spec.json.language`

## Safety & Fallback
- **Name Ambiguity**: If the description yields no clear feature name, propose 2–3 candidates and ask the user to select one
- **Missing Template**: If `init.json` or `requirements-init.md` are absent from `{{SDD_DIR}}/settings/templates/specs/`, halt with the exact missing path and suggest verifying repository setup
- **Name Conflict**: Auto-resolve by appending a numeric suffix; notify the user of the change
- **Write Error**: Report the precise file path and suggest checking permissions or available disk space
