@tudeorangbiasa/sdd-multiagent-opencode 0.2.2 → 0.2.3

package/.opencode/commands/sdd-construct.md

@@ -0,0 +1,693 @@
+---
+description: Initialize SDD workflow for a new or existing project — explore stack, grill vision, scaffold config, create CONTEXT.md and ADRs
+agent: sdd-planner
+---
+
+Initialize the "spine" of an SDD-driven project. This is a one-time setup command that creates the foundational artifacts every AI-assisted project needs.
+
+## Usage
+
+```text
+/sdd-construct
+/sdd-construct "e-commerce platform for digital goods"
+/sdd-construct --existing
+```
+
+## Philosophy
+
+Inspired by Matt Pocock's `setup-matt-pocock-skills` + `grill-with-docs` workflow. The goal is not to generate boilerplate — it is to **force clarity before code**.
+
+Before any implementation artifact exists, the project must have:
+- A detected and verified stack profile
+- A domain glossary (CONTEXT.md) with agreed terminology
+- Architectural Decision Records for load-bearing choices
+- Model routing and reasoning profiles tuned to project complexity
+- Type-specific guardrails (design system for frontend, API contract for backend, etc.)
+
+## Phase 1: Stack Detection and Classification
+
+### Step 0: Empty Directory Guard
+
+Check if the directory contains ANY files:
+- `ls -la` at repo root
+- Check for hidden files: `.gitignore`, `.env`, `.git/`
+
+**If ZERO files found (truly empty):**
+1. Report: "This directory is empty. I cannot auto-detect a stack."
+2. Ask user to choose project type explicitly:
+   - `frontend` (React, Vue, Svelte, etc.)
+   - `backend` (Express, Fastify, Laravel, Django, etc.)
+   - `library/sdk` (TypeScript package, utility library)
+   - `cli` (command-line tool)
+   - `fullstack` (Next.js, Remix, Nuxt)
+3. Ask user to choose initial stack details:
+   - Framework, language, package manager, styling (if applicable)
+4. Generate minimal starter files based on chosen type (`package.json`, `tsconfig.json`, etc.)
+5. Proceed to Phase 2 with user-provided stack info
+6. DO NOT spawn sdd-explorer (nothing to explore).
+
+### Step 1: Quick Sniff Test (no subagent yet)
+
+Read these files directly to determine if exploration is needed:
+1. `package.json` (first 50 lines) — check for framework dependencies and config fields
+2. `ls -la` at root — check for config files and directory structure
+
+**Decision Matrix: Spawn explorer or skip?**
+
+| Sniff Result | Decision | Reason |
+|-------------|----------|--------|
+| No `package.json` + random files | Spawn explorer | Unclear pattern |
+| `package.json` + `next.config.*` | Skip | Clear: Next.js |
+| `package.json` + `nuxt.config.*` | Skip | Clear: Nuxt |
+| `package.json` + `vite.config.*` + `src/` + no server deps | Skip | Clear: Vite frontend |
+| `package.json` + `laravel/` dir | Skip | Clear: Laravel |
+| `package.json` + `django/` or `manage.py` | Skip | Clear: Django |
+| `package.json` + `express`/`fastify`/`hono` deps | Skip | Clear: backend |
+| `package.json` + `"exports"` field + no server deps | Skip | Clear: library |
+| `package.json` + `"bin"` field + no server | Skip | Clear: CLI |
+| `package.json` + unknown config + 3+ config files | Spawn explorer | Complex or custom |
+| `pnpm-workspace.yaml` or monorepo structure | Spawn explorer | Monorepo needs deep scan |
+| 10+ config files at root | Spawn explorer | Too many signals to classify from sniff |
+
+**If decision is SKIP:**
+- Classify project type directly from sniff results.
+- Proceed to Step 3 (Present findings).
+- Do NOT spawn subagent.
+
+**If decision is SPAWN:**
+- Proceed to Step 2 (Subagent exploration).
+
+### Step 2: Subagent Exploration (only if sniff test is unclear)
+
+Spawn `sdd-explorer` subagent with this task:
+
+```
+Explore this codebase and return a structured stack profile.
+
+Write results to `.sdd/stack-profile.json` with this exact structure:
+
+{
+  "detectedAt": "<ISO timestamp>",
+  "projectType": "<frontend|backend|library|cli|fullstack>",
+  "packageManager": { "name": "<value>", "lockFile": "<filename or null>" },
+  "framework": { "name": "<value>", "version": "<value or null>", "config": "<config filename or null>" },
+  "language": { "name": "<value>", "version": "<value or null>", "config": "<config filename or null>" },
+  "styling": { "name": "<value or null>", "version": "<value or null>", "config": "<config filename or null>" },
+  "testing": { "name": "<value or null>", "config": "<config filename or null>" },
+  "sddArtifacts": { "hasSddDir": false, "hasSpecs": false, "hasContextMd": false, "hasAdr": false },
+  "designSignals": { "hasDesignMd": false, "hasStorybook": false, "componentDirs": [] },
+  "rawFiles": {
+    "package.json": "<truncated to 200 lines>",
+    "tsconfig.json": "<full content if < 200 lines, else truncated>",
+    "<other small config files>": "<full content>"
+  }
+}
+
+Rules for rawFiles:
+- Config files < 200 lines: include FULL content
+- Config files >= 200 lines: truncate to first 200 lines, append "... (truncated)"
+- Source files: do NOT include, only list paths
+- Include at minimum: package.json, tsconfig.json (or equivalent), and up to 3 other config files
+
+After writing the file, summarize findings in a table for the user.
+```
+
+**Timeout and Error Handling (Three-Layer Fallback):**
+
+- **Layer 1**: Spawn `sdd-explorer` with 60-second timeout.
+- **Layer 2**: If Layer 1 times out or errors → `sdd-planner` reads files directly:
+  - Read `package.json`, `tsconfig.json`, and up to 3 config files found in sniff test.
+  - Do manual classification based on what's readable.
+  - Report: "Explorer timed out. I did a quick scan instead. Results may be incomplete."
+  - Write `.sdd/stack-profile.json` with whatever was found (use `null` for unknown fields).
+- **Layer 3**: If Layer 2 also fails (unreadable files, no package.json, etc.):
+  - Report: "I could not read this project automatically."
+  - Ask user to provide: project type, framework, language, package manager.
+  - Write `.sdd/stack-profile.json` with user-provided info.
+  - Proceed to Phase 2 with caveat.
+
+### Step 3: Present Findings
+
+Summarize what is present, what is missing, and the classified type:
+
+```markdown
+## Stack Detection Results
+
+| Signal | Found | Value |
+|--------|-------|-------|
+| Package manager | ✅ | pnpm |
+| Framework | ✅ | Next.js 15 (App Router) |
+| Language | ✅ | TypeScript 5.7 |
+| Styling | ✅ | Tailwind CSS v4 |
+| Testing | ❌ | none detected |
+| Existing SDD | ❌ | no .sdd/ or specs/ |
+| Design docs | ❌ | no DESIGN.md or PRODUCT.md |
+
+**Classified as: fullstack**
+```
+
+If exploration was done via subagent, also note: "Full stack profile saved to `.sdd/stack-profile.json`".
+If fallback was used, note: "Stack profile is incomplete — explorer fell back to direct scan."
+
+## Phase 2: Grilling Session
+
+After presenting findings, walk the user through decisions **one at a time**. Do not dump all questions at once. Wait for each answer before proceeding.
+
+Assume the user does not know SDD terminology. Each section starts with a short explainer.
+
+### Section A — Project Vision (ALL types)
+
+> Explainer: This defines what you're building at a high level. It becomes the north star for all future `/sdd-propose` calls.
+
+Ask:
+1. **What are you building?** (one sentence description)
+2. **Who is the target user?** (developer, consumer, enterprise, etc.)
+3. **What is the single most important feature?** (the thing that must work)
+
+### Section B — Constraints & Preferences (ALL types)
+
+> Explainer: These are the guardrails that prevent AI from making wrong choices. If you don't set them now, the AI will guess — and it will guess wrong.
+
+Ask:
+1. **Any libraries or frameworks you refuse to use?** (e.g., "no Redux", "no jQuery")
+2. **Any libraries you insist on?** (e.g., "must use Zod", "must use TanStack Query")
+3. **Team size:** solo, small team (2-5), or large team (5+)? This affects how strict the workflow should be.
+
+### Section C — Model Budget (ALL types)
+
+> Explainer: SDD routes different agents to different models. Paid models get planning and orchestration roles. Free models get implementation and exploration roles. This section configures that routing.
+
+Present the default model profile (from `.sdd/templates/model-profile-template.json`) and ask:
+1. **Do you have a paid model subscription?** (OpenAI Plus, OpenCode Go, OpenCode Zen, or direct API keys)
+2. **If yes, which provider?** This determines which agents get routed to paid models.
+3. **If no, accept the free-model defaults.** Implementation will still work but planning may be slower.
+
+### Section D — Issue Tracker (ALL types)
+
+> Explainer: SDD can track work through GitHub Issues, GitLab Issues, or local markdown files. This determines where `/sdd-propose` publishes its artifacts.
+
+Options:
+- **GitHub** — uses `gh` CLI (default if `git remote` points to GitHub)
+- **GitLab** — uses `glab` CLI
+- **Local markdown** — files under `.scratch/` (good for solo projects)
+- **Other** — ask user to describe workflow in one paragraph
+
+### Section E — Domain Glossary (CONTEXT.md) (ALL types)
+
+> Explainer: CONTEXT.md is a glossary of domain terms. It contains NO implementation details — only agreed-upon terminology. Skills like `/sdd-propose` and `/sdd-ship` read this to ensure consistent language. If a term isn't in CONTEXT.md, the AI might invent its own variant.
+
+Ask:
+1. **What are the key domain terms in your project?** (e.g., for e-commerce: "Product", "Cart", "Checkout", "Order", "Customer")
+2. **Any terms that are commonly confused?** (e.g., "User vs Customer — User is authenticated, Customer is the buyer")
+
+### Section F — Type-Specific Guardrails (conditional)
+
+**Only for `frontend` and `fullstack` projects:**
+
+#### Section F-UI — Design System Lock
+
+> Explainer: Without a locked design system, every feature will invent its own colors, spacing, and shadows. This causes visual drift. We must lock core tokens NOW before any feature is proposed.
+
+Ask:
+1. **Design system:** Material You 3, shadcn/ui, Tailwind default, Custom, or Existing?
+2. **Primary color:** Hex value (e.g., `#6750A4` for Material You)
+3. **Typography:** Font family + scale (e.g., "Inter, 14/16/20/24/32")
+4. **Spacing base:** Pixel value (e.g., `8px`)
+5. **Dark mode:** Yes or No?
+
+If user says **"Custom"** → MUST define at minimum: primary, secondary, surface, font, spacing. No skip allowed.
+If user says **"Existing"** → read tokens from existing files and copy to DESIGN.md.
+If user says **"Skip for now"** → create DESIGN.md empty but flag: all future `/sdd-propose` UI changes will WARN that tokens are not locked.
+
+**Only for `backend` projects:**
+
+#### Section F-API — API Contract
+
+> Explainer: API contracts define how your backend communicates with clients. Without these, every feature will invent its own response format and error structure.
+
+Ask:
+1. **Auth method:** JWT, Session/Cookie, API Key, OAuth2, None?
+2. **Response format:** `{data, meta}`, `{result}`, plain array, other?
+3. **Pagination style:** cursor-based, offset-based, none?
+4. **Error format:** RFC 7807 (Problem Details), `{error: {code, message}}`, other?
+5. **Rate limiting:** Yes/No? If yes, what limits?
+
+**Only for `library/sdk` projects:**
+
+#### Section F-LIB — Public API
+
+> Explainer: A library's public API is its contract with consumers. Breaking changes cost users real money. We must define the export policy now.
+
+Ask:
+1. **Export style:** ESM only, CJS only, dual (ESM + CJS)?
+2. **Versioning policy:** Semver strict, semver with pre-release, other?
+3. **Breaking change tolerance:** "Never break without major version", "Accept minor breaking for beta", other?
+4. **Type exports:** Always export types, types only in `@types/`, other?
+
+**Only for `cli` projects:**
+
+#### Section F-CLI — Command Structure
+
+> Explainer: CLI tools need consistent flag conventions, output formats, and exit codes. Without these, each command feels like it was written by a different author.
+
+Ask:
+1. **Flag convention:** `--kebab-case`, `-camelCase`, POSIX short flags (`-v`)?
+2. **Output format:** JSON (`--json` flag), human-readable default, both?
+3. **Exit codes:** Standard (0=success, 1=error), custom codes?
+4. **Help format:** `--help`, `man` page, interactive?
+
+## Phase 3: Scaffold Artifacts
+
+After all grilling questions are answered, generate the following files:
+
+### 3.1 `.sdd/project-profile.json`
+
+Populate the template with detected stack info and user answers:
+- `stack.*` — from `.sdd/stack-profile.json` (written by Phase 1 explorer or sniff test)
+- `commands.*` — from package.json scripts or equivalent
+- `design.*` — from styling signals and design doc presence
+- `projectState` — `"new"` or `"existing"` based on whether source code exists
+- `projectType` — classified type from Phase 1
+
+### 3.1b `.sdd/stack-profile.json` (if not already written by explorer)
+
+If Phase 1 used the sniff test (no subagent spawned), write the stack profile now with the same structure the explorer would have written:
+
+```json
+{
+  "detectedAt": "<ISO timestamp>",
+  "projectType": "<value>",
+  "packageManager": { "name": "<value>", "lockFile": "<value or null>" },
+  "framework": { "name": "<value>", "version": "<value or null>", "config": "<value or null>" },
+  "language": { "name": "<value>", "version": "<value or null>", "config": "<value or null>" },
+  "styling": { "name": "<value or null>", "version": "<value or null>", "config": "<value or null>" },
+  "testing": { "name": "<value or null>", "config": "<value or null>" },
+  "sddArtifacts": { "hasSddDir": false, "hasSpecs": false, "hasContextMd": false, "hasAdr": false },
+  "designSignals": { "hasDesignMd": false, "hasStorybook": false, "componentDirs": [] },
+  "rawFiles": {
+    "package.json": "<truncated to 200 lines>",
+    "tsconfig.json": "<full content if < 200 lines>"
+  }
+}
+```
+
+This ensures `.sdd/stack-profile.json` always exists after `/sdd-construct`, regardless of whether a subagent was used.
+
+### 3.2 `.sdd/model-profile.json`
+
+Populate the template with model routing based on Phase 2 Section C:
+- If user has paid subscription → route orchestrator and planner to paid model
+- If user has no paid subscription → use free model defaults
+- Keep explorer, implementer, verifier, reviewer on free models
+
+### 3.3 `.sdd/reasoning-profile.json`
+
+Copy the template. No changes needed — defaults are appropriate for all project sizes.
+
+### 3.4 `CONTEXT.md` (at repo root)
+
+Create the domain glossary. Format:
+
+```markdown
+# Context: <project name>
+
+## Domain Terms
+
+| Term | Definition | Non-Example |
+|------|------------|-------------|
+| Product | A sellable item in the catalog | Not a Service — Services have no inventory |
+| Cart | A temporary collection of Products selected by a Customer | Not an Order — Orders are placed after checkout |
+| Customer | A user who has placed at least one Order | Not a User — Users may browse without buying |
+
+## Out of Scope Terms
+
+Terms that are intentionally NOT part of this project:
+
+| Term | Why Excluded |
+|------|-------------|
+| Warehouse | Handled by external 3PL system |
+| Invoice | Generated by Stripe, not stored locally |
+```
+
+**Rules for CONTEXT.md:**
+- Totally devoid of implementation details
+- No file paths, no code snippets, no framework names
+- Only domain concepts and their relationships
+- If no terms were resolved during grilling, create the file with empty tables and a note: "Terms will be added during /sdd-propose sessions"
+
+### 3.5 `docs/adr/0001-project-initialization.md`
+
+Create the first ADR documenting the initialization decisions:
+
+```markdown
+# ADR-0001: Project Initialization
+
+**Date:** YYYY-MM-DD
+**Status:** Accepted
+
+## Context
+
+Initial SDD construct session for <project name>.
+Project type: <frontend|backend|library|cli|fullstack>
+
+## Decisions
+
+| Decision | Rationale |
+|----------|-----------|
+| Stack: <framework> + <language> | <user's reason or "default choice"> |
+| Styling: <approach> | <user's preference> |
+| Issue tracker: <tracker> | <reason> |
+| Model routing: <paid/free> | <subscription status> |
+| <Type-specific guardrail> | <user's answer> |
+
+## Consequences
+
+- SDD workflow is initialized and ready for /sdd-propose
+- CONTEXT.md contains initial domain glossary
+- Model profile routes agents based on subscription status
+```
+
+### 3.6 Type-Specific Artifacts (conditional)
+
+**For `frontend` projects:**
+
+Create `DESIGN.md` with locked tokens from Section F-UI:
+
+```markdown
+# Design System: <project name>
+
+## 🔒 Locked Tokens (READ-ONLY for /sdd-propose)
+
+Core tokens that CANNOT be changed by feature proposals.
+Only /sdd-construct or explicit design change request can modify these.
+
+| Token | Value | Source |
+|-------|-------|--------|
+| color-primary | <value> | <source> |
+| color-surface-light | <value> | <source> |
+| color-surface-dark | <value> | <source> |
+| font-family | <value> | <source> |
+| font-scale | <value> | <source> |
+| spacing-base | <value> | <source> |
+| border-radius | <value> | <source> |
+| shadow-elevation-1 | <value> | <source> |
+
+## 📦 Component Catalog (APPEND-ONLY for /sdd-propose)
+
+New components can be ADDED. Existing components CANNOT be modified
+without explicit user approval.
+
+| Component | Tokens Used | Added In | Status |
+|-----------|-------------|----------|--------|
+| (none yet) | — | — | — |
+```
+
+Also create or update `AGENTS.md` with design rules:
+
+```markdown
+## Design Rules
+
+- All UI components must follow the design system defined in DESIGN.md
+- No inline styles — use Tailwind utility classes or CSS modules
+- No hardcoded colors — use design tokens from DESIGN.md
+- Responsive breakpoints: mobile-first (sm: 640px, md: 768px, lg: 1024px)
+- Accessibility: all interactive elements must have aria-labels
+```
+
+**For `fullstack` projects:**
+
+Create both `DESIGN.md` (as above) AND `API_CONTRACT.md`:
+
+```markdown
+# API Contract: <project name>
+
+## Authentication
+
+Method: <JWT|Session|API Key|OAuth2>
+Token location: Header (Authorization: Bearer <token>)
+
+## Response Format
+
+```json
+{
+  "data": "<result>",
+  "meta": { "page": 1, "total": 100 }
+}
+```
+
+## Error Format
+
+Format: <RFC 7807|custom>
+```json
+{
+  "error": {
+    "code": "VALIDATION_ERROR",
+    "message": "Email is required",
+    "details": {}
+  }
+}
+```
+
+## Pagination
+
+Style: <cursor|offset|none>
+
+## Rate Limiting
+
+Enabled: <yes|no>
+Limits: <if yes, what limits>
+```
+
+**For `backend` projects:**
+
+Create `API_CONTRACT.md` (as above) AND `SECURITY_RULES.md`:
+
+```markdown
+# Security Rules: <project name>
+
+## Input Validation
+
+- All input must be validated with Zod (or equivalent)
+- No raw user input passed to database queries
+- SQL injection prevention: use parameterized queries
+
+## Authentication
+
+- <method from Section F-API>
+- Token expiration: <value>
+- Refresh token policy: <value>
+
+## Rate Limiting
+
+- <limits from Section F-API>
+- Per-user or per-IP: <value>
+
+## CORS
+
+- Allowed origins: <value>
+- Allowed methods: GET, POST, PUT, DELETE
+- Credentials: <true|false>
+```
+
+**For `library/sdk` projects:**
+
+Create `PUBLIC_API.md` AND `VERSIONING.md`:
+
+```markdown
+# Public API: <project name>
+
+## Exports
+
+Export style: <ESM|CJS|dual>
+
+## Exported Modules
+
+| Module | Purpose | Stability |
+|--------|---------|-----------|
+| (none yet) | — | — |
+
+## Type Exports
+
+Policy: <always export types|separate @types package>
+
+## Deprecation Policy
+
+- Deprecated exports must be marked with `@deprecated` JSDoc
+- Minimum 1 minor version notice before removal
+- Migration guide required for breaking changes
+```
+
+```markdown
+# Versioning: <project name>
+
+## Policy
+
+Versioning: <semver strict|semver with pre-release|other>
+
+## Breaking Change Rules
+
+- MAJOR: Breaking changes to public API
+- MINOR: New features, backward-compatible
+- PATCH: Bug fixes, backward-compatible
+
+## Changelog Format
+
+- Use Keep a Changelog format
+- Categories: Added, Changed, Deprecated, Removed, Fixed, Security
+```
+
+**For `cli` projects:**
+
+Create `COMMAND_STRUCTURE.md`:
+
+```markdown
+# Command Structure: <project name>
+
+## Flag Convention
+
+Style: <kebab-case|camelCase|POSIX>
+
+## Output Format
+
+Default: <human-readable|JSON>
+JSON flag: `--json` → machine-readable output
+
+## Exit Codes
+
+- 0: Success
+- 1: General error
+- 2: Misuse of CLI (invalid flags)
+- Custom codes: <if any>
+
+## Help
+
+Format: `--help` flag
+Additional: <man page|interactive|none>
+```
+
+### 3.7 Agent Skills Block
+
+Add or update the `## Agent skills` block in `AGENTS.md` (or `CLAUDE.md` if it exists):
+
+```markdown
+## Agent skills
+
+### Issue tracker
+
+<one-line summary>. See `docs/agents/issue-tracker.md`.
+
+### Domain docs
+
+Single-context: CONTEXT.md at repo root, ADRs in docs/adr/.
+
+### SDD Commands
+
+| Command | Purpose |
+|---------|---------|
+| `/sdd-explore` | Codebase investigation |
+| `/sdd-propose` | Create spec, design, and tasks for a feature |
+| `/sdd-apply` | Implement tasks from a spec |
+| `/sdd-ship` | Final verification before merge |
+| `/sdd-quick` | Lightweight cosmetic/config change |
+| `/sdd-construct` | Initialize SDD workflow (this command) |
+```
+
+### 3.8 `docs/agents/issue-tracker.md`
+
+Create based on user's choice in Phase 2 Section D:
+
+For GitHub:
+```markdown
+# Issue Tracker: GitHub
+
+Issues are tracked via GitHub Issues using the `gh` CLI.
+
+## Workflow
+- `/sdd-propose` creates specs in `specs/active/<change-id>/`
+- Features can be published as GitHub Issues with `ready-for-agent` label
+- Triage labels: needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix
+```
+
+For local markdown:
+```markdown
+# Issue Tracker: Local Markdown
+
+Issues are stored as files under `.scratch/<feature>/` in this repo.
+
+## Workflow
+- `/sdd-propose` creates specs in `specs/active/<change-id>/`
+- Feature requests can be written as `.scratch/<feature>/request.md`
+- No labels — status is tracked via file presence
+```
+
+## Phase 4: Verification
+
+Before reporting completion, verify:
+
+### Universal checks (ALL project types):
+- [ ] `.sdd/stack-profile.json` exists (written by explorer or by planner after sniff test)
+- [ ] `.sdd/project-profile.json` exists and has non-null values for detected stack
+- [ ] `.sdd/model-profile.json` exists and has agent routing configured
+- [ ] `.sdd/reasoning-profile.json` exists
+- [ ] `CONTEXT.md` exists at repo root (even if empty tables)
+- [ ] `docs/adr/0001-project-initialization.md` exists
+- [ ] `AGENTS.md` or `CLAUDE.md` has `## Agent skills` block
+- [ ] `docs/agents/issue-tracker.md` exists
+
+### Type-specific checks:
+- [ ] If `frontend`: `DESIGN.md` exists with locked tokens from Section F-UI
+- [ ] If `fullstack`: `DESIGN.md` AND `API_CONTRACT.md` exist
+- [ ] If `backend`: `API_CONTRACT.md` AND `SECURITY_RULES.md` exist
+- [ ] If `library`: `PUBLIC_API.md` AND `VERSIONING.md` exist
+- [ ] If `cli`: `COMMAND_STRUCTURE.md` exists
+
+If any item is missing, report it as a warning but do not fail — the user can create it manually later.
+
+## Anti-Generic Gate
+
+Before final output, verify:
+
+- [ ] Stack detection was based on actual file signals, not assumptions
+- [ ] Empty directory was handled explicitly (asked user, did not guess)
+- [ ] Quick sniff test was performed before deciding to spawn subagent
+- [ ] Subagent was spawned ONLY when sniff test was unclear (not for clear patterns like Next.js)
+- [ ] If subagent was spawned, `.sdd/stack-profile.json` contains raw file content (not just summary)
+- [ ] If subagent failed, fallback was used and reported to user (no silent failure)
+- [ ] Project type was classified correctly (not forced into frontend)
+- [ ] Grilling questions were asked one at a time (not dumped all at once)
+- [ ] CONTEXT.md contains domain terms from the grilling session, not generic placeholders
+- [ ] ADR documents actual decisions made during the session
+- [ ] Model routing reflects user's subscription status, not defaults
+- [ ] No file paths or code snippets in CONTEXT.md
+- [ ] Type-specific guardrails match classified project type
+- [ ] No DESIGN.md generated for non-UI projects (backend, library, cli)
+- [ ] No API_CONTRACT.md generated for frontend-only projects
+
+If any item fails, report the failure and explain what is missing.
+
+## Output
+
+End with:
+
+```markdown
+changed: SDD project initialized
+
+Artifacts created:
+- `.sdd/stack-profile.json` — raw stack detection results (from explorer or sniff test)
+- `.sdd/project-profile.json` — stack detection results
+- `.sdd/model-profile.json` — model routing configuration
+- `.sdd/reasoning-profile.json` — reasoning effort per agent
+- `CONTEXT.md` — domain glossary
+- `docs/adr/0001-project-initialization.md` — initialization decisions
+- `docs/agents/issue-tracker.md` — issue tracker configuration
+- `AGENTS.md` — agent skills block (created or updated)
+- <type-specific artifacts>
+
+Project type: <frontend|backend|library|cli|fullstack>
+Stack: <framework> + <language> + <styling or "N/A">
+Issue tracker: <GitHub|GitLab|Local|Other>
+Model routing: <paid model name|free defaults>
+Exploration: <subagent|sniff-test|user-provided>
+
+Next: run `/sdd-propose "<your first feature>"` to start building.
+```