Resolve frontend type-safety guidance by guarantee, not by a fixed route

.claude-plugin/marketplace.json

@@ -12,7 +12,7 @@
       "name": "dev-workflows",
       "source": "./dev-workflows",
       "strict": true,
-      "version": "0.25.3",
+      "version": "0.25.4",
       "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",
@@ -83,7 +83,7 @@
       "name": "dev-workflows-frontend",
       "source": "./dev-workflows-frontend",
       "strict": true,
-      "version": "0.25.3",
+      "version": "0.25.4",
       "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",
@@ -157,7 +157,7 @@
       "name": "dev-workflows-fullstack",
       "source": "./dev-workflows-fullstack",
       "strict": true,
-      "version": "0.25.3",
+      "version": "0.25.4",
       "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",
@@ -247,7 +247,7 @@
       "name": "dev-skills",
       "source": "./dev-skills",
       "strict": true,
-      "version": "0.25.3",
+      "version": "0.25.4",
       "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",

agents/quality-fixer-frontend.md

@@ -253,15 +253,14 @@ Between tool calls, briefly report: which phase is running, the command executed
   - Split components when independent rendering, state, data, or test responsibilities create material coupling or verification cost; retain a cohesive component when splitting would add avoidable prop/state synchronization
   - Refactor deeply nested conditionals
 - **Type Error Fixes**
-  - Handle external API responses with unknown type and type guards
+  - Resolve external API response types by the typescript-rules boundary validation policy
   - Add necessary Props type definitions
   - Flexibly handle with generics or union types
 
 ## React-Specific Common Fixes
 
 ### TypeScript Errors
 - **Props type definition**: Add explicit type definitions for all component Props
-- **Unknown API responses**: Use `unknown` type with type guards for external data
 - **Event handlers**: Use proper React event types (`React.ChangeEvent`, `React.MouseEvent`)
 - **Refs**: Use `React.RefObject<T>` or `React.MutableRefObject<T>`
 

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.25.3",
+  "version": "0.25.4",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

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

@@ -25,7 +25,7 @@ Pause the affected decision and review the design when detecting the following p
 4. **Making changes without checking dependencies** - Potential for unexpected impacts
 5. **Disabling code with comments** - Should use version control
 6. **Error suppression** - Hiding problems creates technical debt
-7. **Excessive use of type assertions (as)** - Abandoning type safety
+7. **Type assertions standing in for a guarantee** - Declaring a type established by neither a check nor an existing contract
 8. **Pass-through prop chains that obscure state ownership** - Use composition, Context, or the project's state layer when intermediate components only forward values and a broader owner is clearer; retain explicit props when they preserve local ownership and broader state ownership would add coordination while responsibility remains local
 9. **Components mixing independently changing responsibilities** - Split when rendering, state/data ownership, or reusable/testable behavior forms an independent responsibility; retain cohesive components when splitting would add avoidable prop/state synchronization
 
@@ -79,10 +79,10 @@ Keep concrete implementations separate while their similarity is accidental or t
 **Cause**: Surface-level fixes without understanding root cause
 **Avoidance**: Identify root cause with 5 Whys before fixing
 
-### Pattern 2: Abandoning Type Safety
-**Symptom**: Excessive use of any type or as
+### Pattern 2: Circumventing Type Guarantees
+**Symptom**: `any` or `as` declares a type that no check or contract establishes
 **Cause**: Impulse to avoid type errors
-**Avoidance**: Handle safely with unknown type and type guards
+**Avoidance**: Back the declared type with a check or an existing contract that guarantees it, at the boundary where that guarantee holds
 
 ### Pattern 3: Implementation Without Sufficient Testing
 **Symptom**: Many bugs after implementation

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.25.3",
+  "version": "0.25.4",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

dev-workflows-frontend/agents/quality-fixer-frontend.md

@@ -253,15 +253,14 @@ Between tool calls, briefly report: which phase is running, the command executed
   - Split components when independent rendering, state, data, or test responsibilities create material coupling or verification cost; retain a cohesive component when splitting would add avoidable prop/state synchronization
   - Refactor deeply nested conditionals
 - **Type Error Fixes**
-  - Handle external API responses with unknown type and type guards
+  - Resolve external API response types by the typescript-rules boundary validation policy
   - Add necessary Props type definitions
   - Flexibly handle with generics or union types
 
 ## React-Specific Common Fixes
 
 ### TypeScript Errors
 - **Props type definition**: Add explicit type definitions for all component Props
-- **Unknown API responses**: Use `unknown` type with type guards for external data
 - **Event handlers**: Use proper React event types (`React.ChangeEvent`, `React.MouseEvent`)
 - **Refs**: Use `React.RefObject<T>` or `React.MutableRefObject<T>`
 

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

@@ -25,7 +25,7 @@ Pause the affected decision and review the design when detecting the following p
 4. **Making changes without checking dependencies** - Potential for unexpected impacts
 5. **Disabling code with comments** - Should use version control
 6. **Error suppression** - Hiding problems creates technical debt
-7. **Excessive use of type assertions (as)** - Abandoning type safety
+7. **Type assertions standing in for a guarantee** - Declaring a type established by neither a check nor an existing contract
 8. **Pass-through prop chains that obscure state ownership** - Use composition, Context, or the project's state layer when intermediate components only forward values and a broader owner is clearer; retain explicit props when they preserve local ownership and broader state ownership would add coordination while responsibility remains local
 9. **Components mixing independently changing responsibilities** - Split when rendering, state/data ownership, or reusable/testable behavior forms an independent responsibility; retain cohesive components when splitting would add avoidable prop/state synchronization
 
@@ -79,10 +79,10 @@ Keep concrete implementations separate while their similarity is accidental or t
 **Cause**: Surface-level fixes without understanding root cause
 **Avoidance**: Identify root cause with 5 Whys before fixing
 
-### Pattern 2: Abandoning Type Safety
-**Symptom**: Excessive use of any type or as
+### Pattern 2: Circumventing Type Guarantees
+**Symptom**: `any` or `as` declares a type that no check or contract establishes
 **Cause**: Impulse to avoid type errors
-**Avoidance**: Handle safely with unknown type and type guards
+**Avoidance**: Back the declared type with a check or an existing contract that guarantees it, at the boundary where that guarantee holds
 
 ### Pattern 3: Implementation Without Sufficient Testing
 **Symptom**: Many bugs after implementation

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.25.3",
+  "version": "0.25.4",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

dev-workflows-fullstack/agents/quality-fixer-frontend.md

@@ -253,15 +253,14 @@ Between tool calls, briefly report: which phase is running, the command executed
   - Split components when independent rendering, state, data, or test responsibilities create material coupling or verification cost; retain a cohesive component when splitting would add avoidable prop/state synchronization
   - Refactor deeply nested conditionals
 - **Type Error Fixes**
-  - Handle external API responses with unknown type and type guards
+  - Resolve external API response types by the typescript-rules boundary validation policy
   - Add necessary Props type definitions
   - Flexibly handle with generics or union types
 
 ## React-Specific Common Fixes
 
 ### TypeScript Errors
 - **Props type definition**: Add explicit type definitions for all component Props
-- **Unknown API responses**: Use `unknown` type with type guards for external data
 - **Event handlers**: Use proper React event types (`React.ChangeEvent`, `React.MouseEvent`)
 - **Refs**: Use `React.RefObject<T>` or `React.MutableRefObject<T>`
 

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

@@ -25,7 +25,7 @@ Pause the affected decision and review the design when detecting the following p
 4. **Making changes without checking dependencies** - Potential for unexpected impacts
 5. **Disabling code with comments** - Should use version control
 6. **Error suppression** - Hiding problems creates technical debt
-7. **Excessive use of type assertions (as)** - Abandoning type safety
+7. **Type assertions standing in for a guarantee** - Declaring a type established by neither a check nor an existing contract
 8. **Pass-through prop chains that obscure state ownership** - Use composition, Context, or the project's state layer when intermediate components only forward values and a broader owner is clearer; retain explicit props when they preserve local ownership and broader state ownership would add coordination while responsibility remains local
 9. **Components mixing independently changing responsibilities** - Split when rendering, state/data ownership, or reusable/testable behavior forms an independent responsibility; retain cohesive components when splitting would add avoidable prop/state synchronization
 
@@ -79,10 +79,10 @@ Keep concrete implementations separate while their similarity is accidental or t
 **Cause**: Surface-level fixes without understanding root cause
 **Avoidance**: Identify root cause with 5 Whys before fixing
 
-### Pattern 2: Abandoning Type Safety
-**Symptom**: Excessive use of any type or as
+### Pattern 2: Circumventing Type Guarantees
+**Symptom**: `any` or `as` declares a type that no check or contract establishes
 **Cause**: Impulse to avoid type errors
-**Avoidance**: Handle safely with unknown type and type guards
+**Avoidance**: Back the declared type with a check or an existing contract that guarantees it, at the boundary where that guarantee holds
 
 ### Pattern 3: Implementation Without Sufficient Testing
 **Symptom**: Many bugs after implementation

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.25.3",
+  "version": "0.25.4",
   "author": {
     "name": "Shinsuke Kagawa",
     "url": "https://github.com/shinpr"

package.json

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

skills/frontend-ai-guide/SKILL.md

@@ -25,7 +25,7 @@ Pause the affected decision and review the design when detecting the following p
 4. **Making changes without checking dependencies** - Potential for unexpected impacts
 5. **Disabling code with comments** - Should use version control
 6. **Error suppression** - Hiding problems creates technical debt
-7. **Excessive use of type assertions (as)** - Abandoning type safety
+7. **Type assertions standing in for a guarantee** - Declaring a type established by neither a check nor an existing contract
 8. **Pass-through prop chains that obscure state ownership** - Use composition, Context, or the project's state layer when intermediate components only forward values and a broader owner is clearer; retain explicit props when they preserve local ownership and broader state ownership would add coordination while responsibility remains local
 9. **Components mixing independently changing responsibilities** - Split when rendering, state/data ownership, or reusable/testable behavior forms an independent responsibility; retain cohesive components when splitting would add avoidable prop/state synchronization
 
@@ -79,10 +79,10 @@ Keep concrete implementations separate while their similarity is accidental or t
 **Cause**: Surface-level fixes without understanding root cause
 **Avoidance**: Identify root cause with 5 Whys before fixing
 
-### Pattern 2: Abandoning Type Safety
-**Symptom**: Excessive use of any type or as
+### Pattern 2: Circumventing Type Guarantees
+**Symptom**: `any` or `as` declares a type that no check or contract establishes
 **Cause**: Impulse to avoid type errors
-**Avoidance**: Handle safely with unknown type and type guards
+**Avoidance**: Back the declared type with a check or an existing contract that guarantees it, at the boundary where that guarantee holds
 
 ### Pattern 3: Implementation Without Sufficient Testing
 **Symptom**: Many bugs after implementation