Generalize Pattern 4 to unverified premises

.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "dev-workflows",
       "source": "./dev-workflows",
       "strict": true,
-      "version": "0.28.0",
+      "version": "0.28.1",
       "description": "Skills + Subagents for backend development - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
       "author": {
         "name": "Shinsuke Kagawa",
@@ -80,7 +80,7 @@
       "name": "dev-workflows-frontend",
       "source": "./dev-workflows-frontend",
       "strict": true,
-      "version": "0.28.0",
+      "version": "0.28.1",
       "description": "Skills + Subagents for React/TypeScript - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
       "author": {
         "name": "Shinsuke Kagawa",
@@ -151,7 +151,7 @@
       "name": "dev-workflows-fullstack",
       "source": "./dev-workflows-fullstack",
       "strict": true,
-      "version": "0.28.0",
+      "version": "0.28.1",
       "description": "Skills + Subagents for fullstack development (backend + React/TypeScript) - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
       "author": {
         "name": "Shinsuke Kagawa",
@@ -238,7 +238,7 @@
       "name": "dev-skills",
       "source": "./dev-skills",
       "strict": true,
-      "version": "0.28.0",
+      "version": "0.28.1",
       "description": "Lightweight skills for users with existing workflows - coding best practices, testing principles, and design guidelines without recipe workflows or agents",
       "author": {
         "name": "Shinsuke Kagawa",

dev-skills/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "dev-skills",
   "description": "Lightweight skills for users with existing workflows - coding best practices, testing principles, and design guidelines without recipe workflows or agents",
-  "version": "0.28.0",
+  "version": "0.28.1",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

dev-skills/skills/ai-development-guide/SKILL.md

@@ -30,7 +30,6 @@ Pause the affected decision and review the design when detecting the following p
 ### Design Anti-patterns
 - **"Make it work for now" thinking** - Accumulation of technical debt
 - **Patchwork implementation** - Unplanned additions to existing code
-- **Optimistic implementation of uncertain technology** - Designing unknown elements assuming "it'll probably work"
 - **Symptomatic fixes** - Surface-level fixes that don't solve root causes
 - **Unplanned large-scale changes** - Lack of incremental approach
 
@@ -130,17 +129,10 @@ Keep concrete implementations separate while their apparent similarity is accide
 **Cause**: Ignoring Red-Green-Refactor process
 **Avoidance**: Start implementation with a failing test that proves the intended behavior
 
-### Pattern 4: Ignoring Technical Uncertainty
-**Symptom**: Frequent unexpected errors when introducing new technology
-**Cause**: Assuming "it should work according to official documentation" without prior investigation
-**Avoidance**:
-- Record certainty where it controls implementation or verification decisions
-  ```
-  Certainty: low (Reason: no working examples found for this integration)
-  Exploratory implementation: true
-  Fallback: use established alternative approach
-  ```
-- For low certainty cases, create minimal verification code first
+### Pattern 4: Building on Unverified Premises
+**Symptom**: Dependent work fails, or workarounds accumulate, once an assumed premise proves false
+**Cause**: Treating an assumed capability, behavior, or existing implementation as fact
+**Avoidance**: When an unverified premise could invalidate the chosen approach, check it by the cheapest sufficient means before building dependent work on it. When results contradict the premise, reconsider the approach before patching its parts. Keep this reasoning in the active task; it needs no separate artifact.
 
 ### Pattern 5: Insufficient Existing Code Investigation
 **Symptom**: Duplicate implementations, architecture inconsistency, integration failures, adopting outdated patterns

dev-skills/skills/frontend-ai-guide/SKILL.md

@@ -32,7 +32,6 @@ Pause the affected decision and review the design when detecting the following p
 ### Design Anti-patterns
 - **"Make it work for now" thinking** - Accumulation of technical debt
 - **Patchwork implementation** - Unplanned additions to existing components
-- **Optimistic implementation of uncertain technology** - Designing unknown elements assuming "it'll probably work"
 - **Symptomatic fixes** - Surface-level fixes that don't solve root causes
 - **Unplanned large-scale changes** - Lack of incremental approach
 
@@ -89,17 +88,10 @@ Keep concrete implementations separate while their similarity is accidental or t
 **Cause**: Ignoring Red-Green-Refactor process
 **Avoidance**: Start new or changed behavior and reproducible bug fixes with a failing test. For behavior-preserving refactors, confirm existing or characterization tests pass before and after the change
 
-### Pattern 4: Ignoring Technical Uncertainty
-**Symptom**: Frequent unexpected errors when introducing new technology
-**Cause**: Assuming "it should work according to official documentation" without prior investigation
-**Avoidance**:
-- Record certainty where it controls implementation or verification decisions
-  ```
-  Certainty: low (Reason: new experimental feature with limited production examples)
-  Exploratory implementation: true
-  Fallback: use established patterns
-  ```
-- For low certainty cases, create minimal verification code first
+### Pattern 4: Building on Unverified Premises
+**Symptom**: Dependent work fails, or workarounds accumulate, once an assumed premise proves false
+**Cause**: Treating an assumed capability, behavior, or existing implementation as fact
+**Avoidance**: When an unverified premise could invalidate the chosen approach, check it by the cheapest sufficient means before building dependent work on it. When results contradict the premise, reconsider the approach before patching its parts. Keep this reasoning in the active task; it needs no separate artifact.
 
 ### Pattern 5: Insufficient Existing Code Investigation
 **Symptom**: Duplicate implementations, architecture inconsistency, integration failures

dev-workflows-frontend/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "dev-workflows-frontend",
   "description": "Skills + Subagents for React/TypeScript - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
-  "version": "0.28.0",
+  "version": "0.28.1",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

dev-workflows-frontend/skills/ai-development-guide/SKILL.md

@@ -30,7 +30,6 @@ Pause the affected decision and review the design when detecting the following p
 ### Design Anti-patterns
 - **"Make it work for now" thinking** - Accumulation of technical debt
 - **Patchwork implementation** - Unplanned additions to existing code
-- **Optimistic implementation of uncertain technology** - Designing unknown elements assuming "it'll probably work"
 - **Symptomatic fixes** - Surface-level fixes that don't solve root causes
 - **Unplanned large-scale changes** - Lack of incremental approach
 
@@ -130,17 +129,10 @@ Keep concrete implementations separate while their apparent similarity is accide
 **Cause**: Ignoring Red-Green-Refactor process
 **Avoidance**: Start implementation with a failing test that proves the intended behavior
 
-### Pattern 4: Ignoring Technical Uncertainty
-**Symptom**: Frequent unexpected errors when introducing new technology
-**Cause**: Assuming "it should work according to official documentation" without prior investigation
-**Avoidance**:
-- Record certainty where it controls implementation or verification decisions
-  ```
-  Certainty: low (Reason: no working examples found for this integration)
-  Exploratory implementation: true
-  Fallback: use established alternative approach
-  ```
-- For low certainty cases, create minimal verification code first
+### Pattern 4: Building on Unverified Premises
+**Symptom**: Dependent work fails, or workarounds accumulate, once an assumed premise proves false
+**Cause**: Treating an assumed capability, behavior, or existing implementation as fact
+**Avoidance**: When an unverified premise could invalidate the chosen approach, check it by the cheapest sufficient means before building dependent work on it. When results contradict the premise, reconsider the approach before patching its parts. Keep this reasoning in the active task; it needs no separate artifact.
 
 ### Pattern 5: Insufficient Existing Code Investigation
 **Symptom**: Duplicate implementations, architecture inconsistency, integration failures, adopting outdated patterns

dev-workflows-frontend/skills/frontend-ai-guide/SKILL.md

@@ -32,7 +32,6 @@ Pause the affected decision and review the design when detecting the following p
 ### Design Anti-patterns
 - **"Make it work for now" thinking** - Accumulation of technical debt
 - **Patchwork implementation** - Unplanned additions to existing components
-- **Optimistic implementation of uncertain technology** - Designing unknown elements assuming "it'll probably work"
 - **Symptomatic fixes** - Surface-level fixes that don't solve root causes
 - **Unplanned large-scale changes** - Lack of incremental approach
 
@@ -89,17 +88,10 @@ Keep concrete implementations separate while their similarity is accidental or t
 **Cause**: Ignoring Red-Green-Refactor process
 **Avoidance**: Start new or changed behavior and reproducible bug fixes with a failing test. For behavior-preserving refactors, confirm existing or characterization tests pass before and after the change
 
-### Pattern 4: Ignoring Technical Uncertainty
-**Symptom**: Frequent unexpected errors when introducing new technology
-**Cause**: Assuming "it should work according to official documentation" without prior investigation
-**Avoidance**:
-- Record certainty where it controls implementation or verification decisions
-  ```
-  Certainty: low (Reason: new experimental feature with limited production examples)
-  Exploratory implementation: true
-  Fallback: use established patterns
-  ```
-- For low certainty cases, create minimal verification code first
+### Pattern 4: Building on Unverified Premises
+**Symptom**: Dependent work fails, or workarounds accumulate, once an assumed premise proves false
+**Cause**: Treating an assumed capability, behavior, or existing implementation as fact
+**Avoidance**: When an unverified premise could invalidate the chosen approach, check it by the cheapest sufficient means before building dependent work on it. When results contradict the premise, reconsider the approach before patching its parts. Keep this reasoning in the active task; it needs no separate artifact.
 
 ### Pattern 5: Insufficient Existing Code Investigation
 **Symptom**: Duplicate implementations, architecture inconsistency, integration failures

dev-workflows-fullstack/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "dev-workflows-fullstack",
   "description": "Skills + Subagents for fullstack development (backend + React/TypeScript) - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
-  "version": "0.28.0",
+  "version": "0.28.1",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

dev-workflows-fullstack/skills/ai-development-guide/SKILL.md

@@ -30,7 +30,6 @@ Pause the affected decision and review the design when detecting the following p
 ### Design Anti-patterns
 - **"Make it work for now" thinking** - Accumulation of technical debt
 - **Patchwork implementation** - Unplanned additions to existing code
-- **Optimistic implementation of uncertain technology** - Designing unknown elements assuming "it'll probably work"
 - **Symptomatic fixes** - Surface-level fixes that don't solve root causes
 - **Unplanned large-scale changes** - Lack of incremental approach
 
@@ -130,17 +129,10 @@ Keep concrete implementations separate while their apparent similarity is accide
 **Cause**: Ignoring Red-Green-Refactor process
 **Avoidance**: Start implementation with a failing test that proves the intended behavior
 
-### Pattern 4: Ignoring Technical Uncertainty
-**Symptom**: Frequent unexpected errors when introducing new technology
-**Cause**: Assuming "it should work according to official documentation" without prior investigation
-**Avoidance**:
-- Record certainty where it controls implementation or verification decisions
-  ```
-  Certainty: low (Reason: no working examples found for this integration)
-  Exploratory implementation: true
-  Fallback: use established alternative approach
-  ```
-- For low certainty cases, create minimal verification code first
+### Pattern 4: Building on Unverified Premises
+**Symptom**: Dependent work fails, or workarounds accumulate, once an assumed premise proves false
+**Cause**: Treating an assumed capability, behavior, or existing implementation as fact
+**Avoidance**: When an unverified premise could invalidate the chosen approach, check it by the cheapest sufficient means before building dependent work on it. When results contradict the premise, reconsider the approach before patching its parts. Keep this reasoning in the active task; it needs no separate artifact.
 
 ### Pattern 5: Insufficient Existing Code Investigation
 **Symptom**: Duplicate implementations, architecture inconsistency, integration failures, adopting outdated patterns

dev-workflows-fullstack/skills/frontend-ai-guide/SKILL.md

@@ -32,7 +32,6 @@ Pause the affected decision and review the design when detecting the following p
 ### Design Anti-patterns
 - **"Make it work for now" thinking** - Accumulation of technical debt
 - **Patchwork implementation** - Unplanned additions to existing components
-- **Optimistic implementation of uncertain technology** - Designing unknown elements assuming "it'll probably work"
 - **Symptomatic fixes** - Surface-level fixes that don't solve root causes
 - **Unplanned large-scale changes** - Lack of incremental approach
 
@@ -89,17 +88,10 @@ Keep concrete implementations separate while their similarity is accidental or t
 **Cause**: Ignoring Red-Green-Refactor process
 **Avoidance**: Start new or changed behavior and reproducible bug fixes with a failing test. For behavior-preserving refactors, confirm existing or characterization tests pass before and after the change
 
-### Pattern 4: Ignoring Technical Uncertainty
-**Symptom**: Frequent unexpected errors when introducing new technology
-**Cause**: Assuming "it should work according to official documentation" without prior investigation
-**Avoidance**:
-- Record certainty where it controls implementation or verification decisions
-  ```
-  Certainty: low (Reason: new experimental feature with limited production examples)
-  Exploratory implementation: true
-  Fallback: use established patterns
-  ```
-- For low certainty cases, create minimal verification code first
+### Pattern 4: Building on Unverified Premises
+**Symptom**: Dependent work fails, or workarounds accumulate, once an assumed premise proves false
+**Cause**: Treating an assumed capability, behavior, or existing implementation as fact
+**Avoidance**: When an unverified premise could invalidate the chosen approach, check it by the cheapest sufficient means before building dependent work on it. When results contradict the premise, reconsider the approach before patching its parts. Keep this reasoning in the active task; it needs no separate artifact.
 
 ### Pattern 5: Insufficient Existing Code Investigation
 **Symptom**: Duplicate implementations, architecture inconsistency, integration failures

dev-workflows/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "dev-workflows",
   "description": "Skills + Subagents for backend development - Use skills for coding guidance, or run recipe workflows for full orchestrated agentic coding with specialized agents",
-  "version": "0.28.0",
+  "version": "0.28.1",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

dev-workflows/skills/ai-development-guide/SKILL.md

@@ -30,7 +30,6 @@ Pause the affected decision and review the design when detecting the following p
 ### Design Anti-patterns
 - **"Make it work for now" thinking** - Accumulation of technical debt
 - **Patchwork implementation** - Unplanned additions to existing code
-- **Optimistic implementation of uncertain technology** - Designing unknown elements assuming "it'll probably work"
 - **Symptomatic fixes** - Surface-level fixes that don't solve root causes
 - **Unplanned large-scale changes** - Lack of incremental approach
 
@@ -130,17 +129,10 @@ Keep concrete implementations separate while their apparent similarity is accide
 **Cause**: Ignoring Red-Green-Refactor process
 **Avoidance**: Start implementation with a failing test that proves the intended behavior
 
-### Pattern 4: Ignoring Technical Uncertainty
-**Symptom**: Frequent unexpected errors when introducing new technology
-**Cause**: Assuming "it should work according to official documentation" without prior investigation
-**Avoidance**:
-- Record certainty where it controls implementation or verification decisions
-  ```
-  Certainty: low (Reason: no working examples found for this integration)
-  Exploratory implementation: true
-  Fallback: use established alternative approach
-  ```
-- For low certainty cases, create minimal verification code first
+### Pattern 4: Building on Unverified Premises
+**Symptom**: Dependent work fails, or workarounds accumulate, once an assumed premise proves false
+**Cause**: Treating an assumed capability, behavior, or existing implementation as fact
+**Avoidance**: When an unverified premise could invalidate the chosen approach, check it by the cheapest sufficient means before building dependent work on it. When results contradict the premise, reconsider the approach before patching its parts. Keep this reasoning in the active task; it needs no separate artifact.
 
 ### Pattern 5: Insufficient Existing Code Investigation
 **Symptom**: Duplicate implementations, architecture inconsistency, integration failures, adopting outdated patterns

package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-code-workflows",
-  "version": "0.28.0",
+  "version": "0.28.1",
   "private": true,
   "type": "module",
   "engines": {

skills/ai-development-guide/SKILL.md

@@ -30,7 +30,6 @@ Pause the affected decision and review the design when detecting the following p
 ### Design Anti-patterns
 - **"Make it work for now" thinking** - Accumulation of technical debt
 - **Patchwork implementation** - Unplanned additions to existing code
-- **Optimistic implementation of uncertain technology** - Designing unknown elements assuming "it'll probably work"
 - **Symptomatic fixes** - Surface-level fixes that don't solve root causes
 - **Unplanned large-scale changes** - Lack of incremental approach
 
@@ -130,17 +129,10 @@ Keep concrete implementations separate while their apparent similarity is accide
 **Cause**: Ignoring Red-Green-Refactor process
 **Avoidance**: Start implementation with a failing test that proves the intended behavior
 
-### Pattern 4: Ignoring Technical Uncertainty
-**Symptom**: Frequent unexpected errors when introducing new technology
-**Cause**: Assuming "it should work according to official documentation" without prior investigation
-**Avoidance**:
-- Record certainty where it controls implementation or verification decisions
-  ```
-  Certainty: low (Reason: no working examples found for this integration)
-  Exploratory implementation: true
-  Fallback: use established alternative approach
-  ```
-- For low certainty cases, create minimal verification code first
+### Pattern 4: Building on Unverified Premises
+**Symptom**: Dependent work fails, or workarounds accumulate, once an assumed premise proves false
+**Cause**: Treating an assumed capability, behavior, or existing implementation as fact
+**Avoidance**: When an unverified premise could invalidate the chosen approach, check it by the cheapest sufficient means before building dependent work on it. When results contradict the premise, reconsider the approach before patching its parts. Keep this reasoning in the active task; it needs no separate artifact.
 
 ### Pattern 5: Insufficient Existing Code Investigation
 **Symptom**: Duplicate implementations, architecture inconsistency, integration failures, adopting outdated patterns