create-sdd-project 0.16.3 → 0.16.5

package/package.json

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

package/template/.claude/skills/pm-orchestrator/SKILL.md

@@ -24,6 +24,11 @@ Before starting:
 2. **Product tracker must have pending features.** Read `docs/project_notes/product-tracker.md` → Features table. If no features have step < 6/6, there is nothing to do.
 3. **Working tree must be clean.** Run `git status`. If dirty, ask user to commit or stash.
 4. **No active PM session.** Check if `docs/project_notes/pm-session.lock` exists. If it does, another PM session may be running — ask user before proceeding.
+5. **Target branch quality gates baseline.** Run `npm test`, `npm run lint`, and `npm run build` on the target branch (main or develop) to verify it is clean BEFORE starting any feature. If any gate fails:
+   - Document the failures in `docs/project_notes/bugs.md` as a tech debt entry (e.g., `BUG-DEV-LINT-XXX`).
+   - Create a follow-up task in `product-tracker.md` to fix the baseline.
+   - STOP and inform the user. Do NOT start features on a broken baseline — features will fail Step 4 quality gates and the agent will be unable to distinguish pre-existing failures from regressions.
+   - Exception: if the lint command itself does not exist for some packages, note it but do not block.
 
 ---
 
@@ -59,6 +64,10 @@ Classify complexity for each (Simple / Standard / Complex):
 ```
 
 5. Wait for user to classify all features in the batch.
+6. **Intra-batch dependency check.** Before proceeding, verify that no feature in the batch depends on another feature in the same batch. If F-Y depends on F-X and both are in the batch:
+   - Warn the user explicitly: "F-Y depends on F-X which is also in this batch. F-X's results will be auto-merged at L5 without your validation before F-Y starts. If F-Y's spec/implementation depends on decisions made in F-X, those decisions won't have been validated by you."
+   - Ask the user: "Do you want to (a) remove F-Y from this batch and run it in a future session after validating F-X, or (b) proceed knowing the risk?"
+   - Default to (a) — only proceed with (b) if the user explicitly confirms.
 
 ### Phase 2: Session Initialization
 
@@ -77,6 +86,7 @@ For each feature in the batch:
 - **Kill switch**: If `docs/project_notes/pm-stop.md` exists → stop gracefully (go to Shutdown).
 - **Lock**: If `docs/project_notes/pm-session.lock` is missing → stop (session was terminated externally).
 - **Circuit breaker**: If 3 consecutive features are `blocked` → stop and report to user.
+- **Context check**: If **2+ features have been completed** in this session, STOP and tell the user to run `/compact` followed by `continue pm`. Do NOT continue to the next feature — context degradation causes skipped steps, lost constraints, and poor quality. This is mandatory, not a suggestion.
 - **Clean workspace**: Run `git status`. If dirty, commit or stash before proceeding.
 
 #### b. Start Feature
@@ -130,7 +140,7 @@ After each completed or blocked feature:
 2. If the current batch is exhausted and more eligible features remain:
    - Present the next 1-3 features to the user for complexity classification.
    - Add them to the batch in `pm-session.md`.
-3. If **3+ features completed** in this session → suggest the user run `/compact` before continuing (context may be getting heavy).
+3. If **2+ features completed** in this session → STOP and tell the user to run `/compact` followed by `continue pm`. This is mandatory — do not ask, do not continue.
 4. If max session limit reached (**5 features**) → stop and report.
 
 ### Phase 4: Shutdown
@@ -190,6 +200,9 @@ Completed: 2/3 | Blocked: 1/3 | Remaining: 0
 | Guardrail | Value | Rationale |
 |-----------|-------|-----------|
 | Max features per session | 5 | Model attention degrades after many iterations |
+| Mandatory compact after 2 features | STOP + `/compact` + `continue pm` | Context degradation causes skipped steps and lost constraints |
+| Target branch baseline check | tests/lint/build before first feature | Pre-existing failures would block Step 4 quality gates and contaminate audit trails |
+| Intra-batch dependency check | Warn + default to remove dependent feature | Auto-merge at L5 means dependent feature won't see user-validated parent results |
 | Consecutive failure circuit breaker | 3 | Prevent wasting resources on a systemic issue |
 | Kill switch | `pm-stop.md` or `stop pm` | User can always halt the loop |
 | Session lock | `pm-session.lock` | Prevents concurrent PM sessions |

package/template/.gemini/skills/pm-orchestrator/SKILL.md

@@ -24,6 +24,11 @@ Before starting:
 2. **Product tracker must have pending features.** Read `docs/project_notes/product-tracker.md` → Features table. If no features have step < 6/6, there is nothing to do.
 3. **Working tree must be clean.** Run `git status`. If dirty, ask user to commit or stash.
 4. **No active PM session.** Check if `docs/project_notes/pm-session.lock` exists. If it does, another PM session may be running — ask user before proceeding.
+5. **Target branch quality gates baseline.** Run `npm test`, `npm run lint`, and `npm run build` on the target branch (main or develop) to verify it is clean BEFORE starting any feature. If any gate fails:
+   - Document the failures in `docs/project_notes/bugs.md` as a tech debt entry (e.g., `BUG-DEV-LINT-XXX`).
+   - Create a follow-up task in `product-tracker.md` to fix the baseline.
+   - STOP and inform the user. Do NOT start features on a broken baseline — features will fail Step 4 quality gates and the agent will be unable to distinguish pre-existing failures from regressions.
+   - Exception: if the lint command itself does not exist for some packages, note it but do not block.
 
 ---
 
@@ -59,6 +64,10 @@ Classify complexity for each (Simple / Standard / Complex):
 ```
 
 5. Wait for user to classify all features in the batch.
+6. **Intra-batch dependency check.** Before proceeding, verify that no feature in the batch depends on another feature in the same batch. If F-Y depends on F-X and both are in the batch:
+   - Warn the user explicitly: "F-Y depends on F-X which is also in this batch. F-X's results will be auto-merged at L5 without your validation before F-Y starts. If F-Y's spec/implementation depends on decisions made in F-X, those decisions won't have been validated by you."
+   - Ask the user: "Do you want to (a) remove F-Y from this batch and run it in a future session after validating F-X, or (b) proceed knowing the risk?"
+   - Default to (a) — only proceed with (b) if the user explicitly confirms.
 
 ### Phase 2: Session Initialization
 
@@ -77,6 +86,7 @@ For each feature in the batch:
 - **Kill switch**: If `docs/project_notes/pm-stop.md` exists → stop gracefully (go to Shutdown).
 - **Lock**: If `docs/project_notes/pm-session.lock` is missing → stop (session was terminated externally).
 - **Circuit breaker**: If 3 consecutive features are `blocked` → stop and report to user.
+- **Context check**: If **2+ features have been completed** in this session, STOP and tell the user to run `/compact` followed by `continue pm`. Do NOT continue to the next feature — context degradation causes skipped steps, lost constraints, and poor quality. This is mandatory, not a suggestion.
 - **Clean workspace**: Run `git status`. If dirty, commit or stash before proceeding.
 
 #### b. Start Feature
@@ -130,7 +140,7 @@ After each completed or blocked feature:
 2. If the current batch is exhausted and more eligible features remain:
    - Present the next 1-3 features to the user for complexity classification.
    - Add them to the batch in `pm-session.md`.
-3. If **3+ features completed** in this session → suggest the user run `/compact` before continuing (context may be getting heavy).
+3. If **2+ features completed** in this session → STOP and tell the user to run `/compact` followed by `continue pm`. This is mandatory — do not ask, do not continue.
 4. If max session limit reached (**5 features**) → stop and report.
 
 ### Phase 4: Shutdown
@@ -190,6 +200,9 @@ Completed: 2/3 | Blocked: 1/3 | Remaining: 0
 | Guardrail | Value | Rationale |
 |-----------|-------|-----------|
 | Max features per session | 5 | Model attention degrades after many iterations |
+| Mandatory compact after 2 features | STOP + `/compact` + `continue pm` | Context degradation causes skipped steps and lost constraints |
+| Target branch baseline check | tests/lint/build before first feature | Pre-existing failures would block Step 4 quality gates and contaminate audit trails |
+| Intra-batch dependency check | Warn + default to remove dependent feature | Auto-merge at L5 means dependent feature won't see user-validated parent results |
 | Consecutive failure circuit breaker | 3 | Prevent wasting resources on a systemic issue |
 | Kill switch | `pm-stop.md` or `stop pm` | User can always halt the loop |
 | Session lock | `pm-session.lock` | Prevents concurrent PM sessions |