create-sdd-project 0.11.1 → 0.12.1

package/README.md

@@ -307,23 +307,25 @@ SDD DevFlow combines three proven practices:
 
 | Command | What it does |
 |---------|-------------|
-| `/review-spec` | Reviews feature specs using external AI models before planning — catches requirement gaps, ambiguity, and architectural inconsistencies |
-| `/review-plan` | Sends Implementation Plan to external AI models (Codex CLI, Gemini CLI) for independent critique |
+| `/review-spec` | Cross-model spec review — runs automatically after self-review when external CLIs are available; catches requirement gaps, ambiguity, and architectural inconsistencies |
+| `/review-plan` | Cross-model plan review — runs automatically after plan self-review when external CLIs are available; catches implementation blind spots |
 | `/context-prompt` | Generates a context recovery prompt after `/compact` with Workflow Recovery to prevent checkpoint skipping |
 | `/review-project` | Comprehensive project-level review using up to 3 AI models in parallel — 6 domains, audit context, consolidated report with action plan |
 
 ### Spec & Plan Quality
 
-Every Standard/Complex feature spec goes through a **built-in self-review** (Step 0.4) where the agent critically re-reads its own spec checking for completeness, edge cases, API contract clarity, and architectural consistency. For additional confidence, the optional `/review-spec` command sends the spec plus project context (`key_facts.md`, `decisions.md`) to external AI models for independent critique — catching requirement-level blind spots before any planning begins.
+Every Standard/Complex feature spec goes through a **built-in self-review** (Step 0.4) where the agent critically re-reads its own spec checking for completeness, edge cases, API contract clarity, and architectural consistency. Then `/review-spec` **automatically** sends the spec plus project context (`key_facts.md`, `decisions.md`) to external AI models for independent critique — catching requirement-level blind spots before any planning begins.
 
-Every plan then goes through its own **built-in self-review** (Step 2.4) followed by the optional `/review-plan` command for external critique — catching implementation-level blind spots that same-model review misses.
+Every plan then goes through its own **built-in self-review** (Step 2.4) followed by **automatic** `/review-plan` for external critique — catching implementation-level blind spots that same-model review misses.
+
+Cross-model reviews only trigger when at least one external CLI is available (Gemini CLI, Codex CLI). If no CLIs are detected, the step is skipped — the self-review is sufficient.
 
 ### Workflow (Steps 0–6)
 
 ```
-0. SPEC      → spec-creator drafts + self-review → Spec Approval
-1. SETUP     → Branch, ticket, product tracker    → Ticket Approval
-2. PLAN      → Planner creates plan + self-review → Plan Approval
+0. SPEC      → spec-creator drafts + self-review + cross-model review → Spec Approval
+1. SETUP     → Branch, ticket, product tracker                       → Ticket Approval
+2. PLAN      → Planner creates plan + self-review + cross-model review → Plan Approval
 3. IMPLEMENT → Developer agent, TDD
 4. FINALIZE  → Tests/lint/build, validator       → Commit Approval
 5. REVIEW    → PR, code review, QA              → Merge Approval

package/lib/adapt-agents.js

@@ -17,11 +17,12 @@ function adaptAgentContentForProjectType(dest, config, replaceInFileFn) {
 
   if (config.projectType === 'backend') {
     for (const dir of toolDirs) {
-      // spec-creator: remove Frontend Specifications section and UI output format
+      // spec-creator: remove Frontend Specifications section, UI output format, ui-components refs
       replaceInFileFn(path.join(dest, dir, 'agents', 'spec-creator.md'), [
         [/### Frontend Specifications\n(?:- [^\n]*\n)+\n/, ''],
         [/### For UI Changes\n```markdown\n(?:[^\n]*\n)*?```\n\n/, ''],
         ['Data Model Changes, UI Changes, Edge Cases', 'Data Model Changes, Edge Cases'],
+        ['(`api-spec.yaml`, `ui-components.md`)', '(`api-spec.yaml`)'],
       ]);
       // production-code-validator: remove ui-components line from Spec Drift
       replaceInFileFn(path.join(dest, dir, 'agents', 'production-code-validator.md'), [
@@ -44,10 +45,11 @@ function adaptAgentContentForProjectType(dest, config, replaceInFileFn) {
     }
   } else if (config.projectType === 'frontend') {
     for (const dir of toolDirs) {
-      // spec-creator: remove Backend Specifications section
+      // spec-creator: remove Backend Specifications section, api-spec refs
       replaceInFileFn(path.join(dest, dir, 'agents', 'spec-creator.md'), [
         [/### Backend Specifications\n(?:- [^\n]*\n)+\n/, ''],
         [/### For API Changes\n```yaml\n(?:[^\n]*\n)*?```\n\n/, ''],
+        ['(`api-spec.yaml`, `ui-components.md`)', '(`ui-components.md`)'],
       ]);
       // code-review-specialist: frontend-only standards ref
       replaceInFileFn(path.join(dest, dir, 'agents', 'code-review-specialist.md'), [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-sdd-project",
-  "version": "0.11.1",
+  "version": "0.12.1",
   "description": "Create a new SDD DevFlow project with AI-assisted development workflow",
   "bin": {
     "create-sdd-project": "bin/cli.js"

package/template/.claude/agents/spec-creator.md

@@ -10,9 +10,10 @@ You are an expert Systems Analyst and API Designer. Your goal is to translate va
 
 ## Goal
 
-Draft or update the specification files in `docs/specs/` AND the ticket's `## Spec` section based on a Ticket or User Request. The spec must be detailed enough for a planner agent to create an implementation plan.
+Update the global specification files in `docs/specs/` AND the ticket's `## Spec` section based on a Ticket or User Request. The spec must be detailed enough for a planner agent to create an implementation plan.
 
 **NEVER write implementation code. Only produce specifications.**
+**NEVER create per-feature spec files** (e.g., `docs/specs/F038-feature-spec.md`). Feature specs belong in the ticket's `## Spec` section. Only update the existing global files (`api-spec.yaml`, `ui-components.md`).
 
 ## Responsibilities
 
@@ -68,5 +69,6 @@ Draft or update the specification files in `docs/specs/` AND the ticket's `## Sp
 - **ALWAYS** follow existing patterns in the spec files
 - **ALWAYS** ensure the specs are feasible (don't over-engineer)
 - **ALWAYS** consider edge cases and error scenarios
-- **ALWAYS** update BOTH the global spec files AND the ticket's `## Spec` section
+- **ALWAYS** update the existing global spec files (`api-spec.yaml`, `ui-components.md`) AND the ticket's `## Spec` section
+- **NEVER** create new per-feature spec files in `docs/specs/` — the ticket IS the feature spec
 - **ALWAYS** ask for user approval: "Does this spec look correct?"

package/template/.claude/skills/development-workflow/SKILL.md

@@ -71,7 +71,7 @@ Ask user to classify complexity before starting. See `references/complexity-guid
 2. Agent updates global spec files (`api-spec.yaml`, `ui-components.md`) and Zod schemas in `shared/src/schemas/` if applicable
 3. Agent writes spec summary into the ticket's `## Spec` section
 4. **Spec Self-Review:** Re-read the spec critically. Are requirements complete? Edge cases covered? API contract well-defined? Acceptance criteria testable? Does the spec conflict with existing architecture (`key_facts.md`, `decisions.md`)? Update the spec with any fixes found before proceeding.
-5. **Optional:** Run `/review-spec` for external model review (recommended for Standard/Complex)
+5. **Cross-Model Spec Review:** Run `/review-spec`. If at least one external CLI is available (`gemini`, `codex`), this provides independent validation from other models. If no external CLIs are detected, skip this step (the self-review above is sufficient).
 
 **→ CHECKPOINT: Spec Approval** — Update tracker (Active Session + Features table): step `0/6 (Spec)`
 
@@ -108,7 +108,8 @@ See `references/branching-strategy.md` for details.
    - Dependencies between steps that force a different order?
    - Over-engineering or unnecessary abstractions?
    Update the plan with any fixes found before proceeding.
-5. Update tracker: step `2/6 (Plan)` (Active Session + Features table)
+5. **Cross-Model Plan Review:** Run `/review-plan`. If at least one external CLI is available (`gemini`, `codex`), this provides independent validation from other models. If no external CLIs are detected, skip this step (the self-review above is sufficient).
+6. Update tracker: step `2/6 (Plan)` (Active Session + Features table)
 
 **→ CHECKPOINT: Plan Approval**
 

package/template/.gemini/agents/spec-creator.md

@@ -5,7 +5,7 @@
 
 ## Instructions
 
-Translate requirements into precise, standard-compliant specifications. Update global spec files AND the ticket's `## Spec` section.
+Translate requirements into precise, standard-compliant specifications. Update existing global spec files (`api-spec.yaml`, `ui-components.md`) AND the ticket's `## Spec` section. NEVER create per-feature spec files — the ticket IS the feature spec.
 
 ## Workflow
 
@@ -20,5 +20,6 @@ Translate requirements into precise, standard-compliant specifications. Update g
 
 - NEVER write implementation code — only specifications
 - ALWAYS follow existing patterns in spec files
-- ALWAYS update BOTH global spec files AND ticket's `## Spec` section
+- ALWAYS update existing global spec files (`api-spec.yaml`, `ui-components.md`) AND ticket's `## Spec` section
+- NEVER create per-feature spec files in `docs/specs/` — the ticket IS the feature spec
 - ALWAYS ask: "Does this spec look correct?"

package/template/.gemini/skills/development-workflow/SKILL.md

@@ -71,7 +71,7 @@ Ask user to classify complexity before starting. See `references/complexity-guid
 2. Update global spec files (`api-spec.yaml`, `ui-components.md`) and Zod schemas in `shared/src/schemas/` if applicable
 3. Write spec summary into the ticket's `## Spec` section
 4. **Spec Self-Review:** Re-read the spec critically. Are requirements complete? Edge cases covered? API contract well-defined? Acceptance criteria testable? Does the spec conflict with existing architecture (`key_facts.md`, `decisions.md`)? Update the spec with any fixes found before proceeding.
-5. **Optional:** Run `/review-spec` for external model review (recommended for Standard/Complex)
+5. **Cross-Model Spec Review:** Run `/review-spec`. If at least one external CLI is available (`claude`, `codex`), this provides independent validation from other models. If no external CLIs are detected, skip this step (the self-review above is sufficient).
 
 **→ CHECKPOINT: Spec Approval** — Update tracker (Active Session + Features table): step `0/6 (Spec)`
 
@@ -108,7 +108,8 @@ See `references/branching-strategy.md` for details.
    - Dependencies between steps that force a different order?
    - Over-engineering or unnecessary abstractions?
    Update the plan with any fixes found before proceeding.
-5. Update tracker: step `2/6 (Plan)` (Active Session + Features table)
+5. **Cross-Model Plan Review:** Run `/review-plan`. If at least one external CLI is available (`claude`, `codex`), this provides independent validation from other models. If no external CLIs are detected, skip this step (the self-review above is sufficient).
+6. Update tracker: step `2/6 (Plan)` (Active Session + Features table)
 
 **→ CHECKPOINT: Plan Approval**