@abdullah-alnahas/claude-sdd 0.3.0 → 0.4.0

package/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "claude-sdd",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Spec-Driven Development discipline system — behavioral guardrails, spec-first development, architecture awareness, TDD enforcement, iterative execution loops"
 }

package/agents/critic.md

@@ -32,7 +32,7 @@ allowed-tools:
 
 # Critic Agent
 
-You are an adversarial reviewer. Your job is to find what's wrong, not confirm what's right.
+You are an adversarial reviewer. Your job is to find what's wrong, not confirm what's right. Report findings only — do not modify code directly.
 
 ## Review Process
 

package/agents/security-reviewer.md

@@ -41,7 +41,7 @@ You review code through a security lens. Focus on high-impact issues, not theore
 3. **Check auth/authz**: Are protected resources properly gated?
 4. **Check injection surfaces**: SQL, command, XSS, path traversal, template injection
 5. **Check secrets**: Hardcoded credentials, API keys, tokens in code or config
-6. **Check dependencies**: Known vulnerable versions (if dependency info available)
+6. **Check dependencies**: Known vulnerable versions — run available audit tools (`npm audit`, `pip-audit`, `cargo audit`) when dependency files are present
 
 ## Priority Order
 

package/agents/simplifier.md

@@ -32,7 +32,7 @@ allowed-tools:
 
 # Simplifier Agent
 
-You ask one question: "Could this be done with less?" Your job is to reduce complexity while preserving correctness and test coverage.
+You ask one question: "Could this be done with less?" Your job is to identify complexity and propose simpler alternatives. Report findings only — do not modify code directly.
 
 ## Review Process
 

package/commands/sdd-guardrails.md

@@ -26,12 +26,28 @@ Show the current state of all SDD guardrails and optionally toggle them.
 | `scope-guard` | PostToolUse (Write/Edit) | Detect unrelated file modifications |
 | `completion-review` | Stop | Spec adherence, test coverage, complexity audit, dead code check |
 
+## Persistence
+
+Guardrail state is stored in `.sdd.yaml` under the `guardrails` key. Each guardrail has an `enabled` boolean:
+
+```yaml
+guardrails:
+  pre-implementation:
+    enabled: true
+  scope-guard:
+    enabled: true
+  completion-review:
+    enabled: true
+```
+
+When toggling a guardrail, read `.sdd.yaml`, update the relevant `enabled` value, and write it back. If `.sdd.yaml` does not exist, create it with defaults (all enabled).
+
 ## Behavior
 
 1. Check if `.sdd.yaml` exists in project root — if so, read guardrail config from it
 2. Check if `GUARDRAILS_DISABLED=true` (set by `/sdd-yolo`) — if so, report all disabled
 3. Display each guardrail with its enabled/disabled status
-4. If an argument is provided, toggle the specified guardrail
+4. If an argument is provided, toggle the specified guardrail in `.sdd.yaml`
 
 ## Output Format
 

package/commands/sdd-phase.md

@@ -27,10 +27,18 @@ Display or change the current SDD development phase. Phases provide context that
 | **verify** | Verification | Running full verification suite, spec-compliance checks, security review |
 | **review** | Review | Critic + simplifier agents, retrospective |
 
+## Persistence
+
+Phase state is stored in `.sdd-phase` in the project root. This file contains a single word (the phase name). If the file does not exist, phase is "none".
+
+- **Set phase**: Write the phase name to `.sdd-phase`
+- **Show phase**: Read `.sdd-phase` (or report "none" if missing)
+- **Clear phase**: Delete `.sdd-phase`
+
 ## Behavior
 
-1. Display the current phase (or "none" if not set)
-2. If a phase name is provided, set it
+1. Read `.sdd-phase` to display the current phase (or "none" if not found)
+2. If a phase name is provided, validate it against the known phases and write to `.sdd-phase`
 3. Phase context is available to subsequent prompts and skills
 4. Phase affects which skills are most relevant:
    - `specify` → spec-first skill

package/hooks/hooks.json

@@ -18,7 +18,7 @@
         "hooks": [
           {
             "type": "prompt",
-            "prompt": "If this message is a trivial acknowledgment (e.g. 'yes', 'no', 'thanks', 'ok', 'continue'), skip the checkpoint and respond normally.\n\nOtherwise, BEFORE responding to this request, apply the SDD pre-implementation checkpoint:\n\n1. **Enumerate Assumptions**: List every assumption you're making about the user's intent, the codebase, and the approach. Flag any that are uncertain.\n\n2. **Flag Ambiguity**: If the request is unclear, underspecified, or could be interpreted multiple ways, ASK for clarification before proceeding. Do not guess.\n\n3. **Surface Alternatives**: Identify at least 2 alternative approaches. Briefly note trade-offs. If the user's suggested approach has significant downsides, say so.\n\n4. **Push Back on Bad Ideas**: If the request involves overengineering, premature abstraction, unnecessary complexity, or architectural anti-patterns, respectfully push back with a simpler alternative.\n\n5. **Define Scope**: State explicitly what you WILL and WILL NOT change. Any file not directly related to the request is out of scope.\n\n6. **Check for Spec**: If this is a non-trivial feature and no spec exists, suggest creating one first (spec-first principle).\n\n7. **Plan TDD Approach**: Identify what tests should be written first. Implementation follows tests, not the reverse.\n\nOnly after completing this checkpoint should you proceed with implementation. If GUARDRAILS_DISABLED=true is set, skip this checkpoint."
+            "prompt": "If this message is a trivial acknowledgment (e.g. 'yes', 'no', 'thanks', 'ok', 'continue'), skip and respond normally. Otherwise, apply the SDD pre-implementation checkpoint from the guardrails skill (enumerate assumptions, flag ambiguity, surface alternatives, push back on bad ideas, define scope, check for spec, plan TDD approach) before proceeding. If GUARDRAILS_DISABLED=true, skip."
           }
         ]
       }
@@ -41,7 +41,7 @@
         "hooks": [
           {
             "type": "prompt",
-            "prompt": "Before finalizing, perform the SDD completion review:\n\n1. **Spec Adherence**: If a spec exists, verify every acceptance criterion is met. List any gaps.\n\n2. **Test Coverage**: Were tests written before implementation (TDD)? Do they trace back to spec criteria? Any untested acceptance criteria?\n\n3. **Complexity Audit**: Check for unnecessary abstractions, overengineered patterns, or premature generalization. Every function should be under 50 lines. Every file should be under 500 lines.\n\n4. **Dead Code Check**: Ensure no unused imports, variables, functions, or files were introduced.\n\n5. **Scope Creep Check**: Verify only files directly related to the task were modified. Flag any unrelated changes.\n\n6. **Conceptual Error Scan**: Re-read the core logic. Does it actually solve the problem correctly? Are there off-by-one errors, race conditions, or logical gaps?\n\nReport findings concisely. If GUARDRAILS_DISABLED=true is set, skip this review."
+            "prompt": "Before finalizing, perform the SDD completion review from the guardrails skill (spec adherence, test coverage, complexity audit, dead code check, scope creep check, conceptual error scan). Report findings concisely. If GUARDRAILS_DISABLED=true, skip."
           }
         ]
       }

package/hooks/scripts/post-edit-review.sh

@@ -30,7 +30,7 @@ fi
 
 # Check if inside project directory
 case "$FILE_PATH" in
-  "$PROJECT_DIR"*) ;; # Inside project, OK
+  "$PROJECT_DIR/"*|"$PROJECT_DIR") ;; # Inside project, OK
   /*)
     echo "SDD SCOPE WARNING: Edit to file outside project directory: $FILE_PATH" >&2
     exit 2

package/hooks/scripts/session-init.sh

@@ -11,7 +11,7 @@ YOLO_FLAG="$PROJECT_DIR/.sdd-yolo"
 
 # Check for yolo mode
 if [ -f "$YOLO_FLAG" ]; then
-  echo "SDD: YOLO mode active — all guardrails disabled" >&2
+  echo "SDD: Previous YOLO mode detected — clearing flag, guardrails disabled for this session" >&2
   # Remove yolo flag (auto-clears on session start)
   rm -f "$YOLO_FLAG"
   if [ -n "$ENV_FILE" ]; then
@@ -29,7 +29,7 @@ fi
 
 # Check for config file
 if [ -f "$CONFIG_FILE" ]; then
-  echo "SDD: Config loaded from $CONFIG_FILE" >&2
+  echo "SDD: Config file found at $CONFIG_FILE" >&2
   if [ -n "$ENV_FILE" ]; then
     echo "SDD_CONFIG_FOUND=true" >> "$ENV_FILE"
   fi

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abdullah-alnahas/claude-sdd",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Spec-Driven Development discipline system for Claude Code — behavioral guardrails, spec-first development, architecture awareness, TDD enforcement, iterative execution loops",
   "keywords": [
     "claude-code-plugin",

package/skills/guardrails/SKILL.md

@@ -41,8 +41,8 @@ Before writing ANY implementation code, you MUST:
 
 ## During Implementation
 
-- Follow TDD: write a failing test first, then the minimum code to pass it, then refactor
-- Use iterative execution: implement → verify against spec → fix gaps → repeat
+- Follow TDD: write a failing test first, then the minimum code to pass it, then refactor (see the tdd-discipline skill for detailed workflow)
+- Use iterative execution: implement → verify against spec → fix gaps → repeat (see the iterative-execution skill for the full cycle)
 - Do not refactor surrounding code unless asked
 - Do not add error handling for impossible scenarios
 - Do not add comments explaining obvious code

package/skills/iterative-execution/SKILL.md

@@ -47,11 +47,10 @@ Good completion criteria are:
 
 Use whatever is available, in order of preference:
 1. **Automated tests** (test runners, linters, type checkers)
-2. **Plugin agents** (critic, spec-compliance, security-reviewer)
-3. **Plugin skills** (guardrails, architecture-aware)
-4. **External MCP servers** (if user has configured any)
-5. **External plugin agents/skills** (if other plugins are installed)
-6. **Manual inspection** (read the code, trace the logic)
+2. **Available review agents** (e.g., critic, spec-compliance, security-reviewer)
+3. **Available analysis skills** (e.g., guardrails, architecture-aware)
+4. **External tools** (MCP servers, other plugins the user has configured)
+5. **Manual inspection** (read the code, trace the logic)
 
 ## Honesty Rules
 

package/skills/tdd-discipline/SKILL.md

@@ -47,7 +47,7 @@ Test: test_submit_form_saves_data()
 Code: FormHandler.submit()
 ```
 
-This chain ensures nothing is built without a reason and nothing specified goes untested.
+This chain ensures nothing is built without a reason and nothing specified goes untested. If a test has no spec criterion, either add the criterion to the spec or question whether the test is needed. If a spec criterion has no test, that is a finding — even if the code works.
 
 ## References