create-sdd-project 0.11.1 → 0.12.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md
CHANGED
|
@@ -307,23 +307,25 @@ SDD DevFlow combines three proven practices:
|
|
|
307
307
|
|
|
308
308
|
| Command | What it does |
|
|
309
309
|
|---------|-------------|
|
|
310
|
-
| `/review-spec` |
|
|
311
|
-
| `/review-plan` |
|
|
310
|
+
| `/review-spec` | Cross-model spec review — runs automatically after self-review when external CLIs are available; catches requirement gaps, ambiguity, and architectural inconsistencies |
|
|
311
|
+
| `/review-plan` | Cross-model plan review — runs automatically after plan self-review when external CLIs are available; catches implementation blind spots |
|
|
312
312
|
| `/context-prompt` | Generates a context recovery prompt after `/compact` with Workflow Recovery to prevent checkpoint skipping |
|
|
313
313
|
| `/review-project` | Comprehensive project-level review using up to 3 AI models in parallel — 6 domains, audit context, consolidated report with action plan |
|
|
314
314
|
|
|
315
315
|
### Spec & Plan Quality
|
|
316
316
|
|
|
317
|
-
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.
|
|
317
|
+
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.
|
|
318
318
|
|
|
319
|
-
Every plan then goes through its own **built-in self-review** (Step 2.4) followed by
|
|
319
|
+
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.
|
|
320
|
+
|
|
321
|
+
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.
|
|
320
322
|
|
|
321
323
|
### Workflow (Steps 0–6)
|
|
322
324
|
|
|
323
325
|
```
|
|
324
|
-
0. SPEC → spec-creator drafts + self-review → Spec Approval
|
|
325
|
-
1. SETUP → Branch, ticket, product tracker
|
|
326
|
-
2. PLAN → Planner creates plan + self-review → Plan Approval
|
|
326
|
+
0. SPEC → spec-creator drafts + self-review + cross-model review → Spec Approval
|
|
327
|
+
1. SETUP → Branch, ticket, product tracker → Ticket Approval
|
|
328
|
+
2. PLAN → Planner creates plan + self-review + cross-model review → Plan Approval
|
|
327
329
|
3. IMPLEMENT → Developer agent, TDD
|
|
328
330
|
4. FINALIZE → Tests/lint/build, validator → Commit Approval
|
|
329
331
|
5. REVIEW → PR, code review, QA → Merge Approval
|
package/package.json
CHANGED
|
@@ -71,7 +71,7 @@ Ask user to classify complexity before starting. See `references/complexity-guid
|
|
|
71
71
|
2. Agent updates global spec files (`api-spec.yaml`, `ui-components.md`) and Zod schemas in `shared/src/schemas/` if applicable
|
|
72
72
|
3. Agent writes spec summary into the ticket's `## Spec` section
|
|
73
73
|
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.
|
|
74
|
-
5. **
|
|
74
|
+
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).
|
|
75
75
|
|
|
76
76
|
**→ CHECKPOINT: Spec Approval** — Update tracker (Active Session + Features table): step `0/6 (Spec)`
|
|
77
77
|
|
|
@@ -108,7 +108,8 @@ See `references/branching-strategy.md` for details.
|
|
|
108
108
|
- Dependencies between steps that force a different order?
|
|
109
109
|
- Over-engineering or unnecessary abstractions?
|
|
110
110
|
Update the plan with any fixes found before proceeding.
|
|
111
|
-
5.
|
|
111
|
+
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).
|
|
112
|
+
6. Update tracker: step `2/6 (Plan)` (Active Session + Features table)
|
|
112
113
|
|
|
113
114
|
**→ CHECKPOINT: Plan Approval**
|
|
114
115
|
|
|
@@ -71,7 +71,7 @@ Ask user to classify complexity before starting. See `references/complexity-guid
|
|
|
71
71
|
2. Update global spec files (`api-spec.yaml`, `ui-components.md`) and Zod schemas in `shared/src/schemas/` if applicable
|
|
72
72
|
3. Write spec summary into the ticket's `## Spec` section
|
|
73
73
|
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.
|
|
74
|
-
5. **
|
|
74
|
+
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).
|
|
75
75
|
|
|
76
76
|
**→ CHECKPOINT: Spec Approval** — Update tracker (Active Session + Features table): step `0/6 (Spec)`
|
|
77
77
|
|
|
@@ -108,7 +108,8 @@ See `references/branching-strategy.md` for details.
|
|
|
108
108
|
- Dependencies between steps that force a different order?
|
|
109
109
|
- Over-engineering or unnecessary abstractions?
|
|
110
110
|
Update the plan with any fixes found before proceeding.
|
|
111
|
-
5.
|
|
111
|
+
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).
|
|
112
|
+
6. Update tracker: step `2/6 (Plan)` (Active Session + Features table)
|
|
112
113
|
|
|
113
114
|
**→ CHECKPOINT: Plan Approval**
|
|
114
115
|
|