jabrena · jabrena · Apr 9, 2026 · Apr 9, 2026
@@ -26,7 +26,6 @@
   {"id": "131", "xml": true},
   {"id": "132", "xml": true},
   {"id": "133", "xml": true},
-  {"id": "134", "xml": true},
   {"id": "141", "xml": true},
   {"id": "142", "xml": true},
   {"id": "143", "xml": true},
@@ -63,5 +62,6 @@
   {"id": "522", "xml": true},
   {"id": "523", "xml": true},
   {"id": "701", "xml": true},
-  {"id": "702", "xml": true}
+  {"id": "702", "xml": true},
+  {"id": "703", "xml": true}
 ]
@@ -20,17 +20,17 @@ Help teams produce maintainable **OpenAPI 3.x** contracts that stay aligned with
 - Reusable `components` (schemas, parameters, responses, security schemes) and examples
 - Validation and CI: spec linting, breaking-change checks, pre-codegen gates
 - Security modeling in the contract (schemes, scopes, global vs operation security)
-- Clear **delegation** to framework REST skills for runtime and generator-specific work
+- Clear boundaries between contract-first design and runtime implementation concerns
 
-**Scope:** Contract-first quality only. For **Spring Boot**, **Quarkus**, or **Micronaut** REST implementation details, use the matching `302`, `402`, or `502` skill. For **CATS fuzz testing** against a contract, use `134-java-testing-fuzzing-testing`.
+**Scope:** Contract-first quality only. Focus this skill on OpenAPI design, quality, and governance guidance.
 ]]></goal>
 
   <constraints>
     <constraints-description>Keep recommendations at the OpenAPI layer unless the user explicitly asks for Java framework integration. After editing this repository's XML sources, regenerate skills and verify the build.</constraints-description>
     <constraint-list>
       <constraint>**MANDATORY**: Run `./mvnw compile` or `mvn compile` before proposing Java or Maven changes in the same change set</constraint>
-      <constraint>**FRAMEWORK**: Defer OpenAPI Generator goals, controller bindings, and runtime `/openapi` exposure to `@302-frameworks-spring-boot-rest`, `@402-frameworks-quarkus-rest`, or `@502-frameworks-micronaut-rest`</constraint>
-      <constraint>**FUZZING**: Defer CATS execution and CI fuzz pipelines to `@134-java-testing-fuzzing-testing`</constraint>
+      <constraint>**FRAMEWORK**: Keep guidance contract-centric; do not prescribe framework-specific controller wiring or runtime exposure details</constraint>
+      <constraint>**FUZZING**: Keep fuzzing guidance high-level and contract-focused without linking to external skill identifiers</constraint>
       <constraint>**MANDATORY**: Regenerate skills with `./mvnw clean install -pl skills-generator` after editing skill or system-prompt XML in this repo</constraint>
       <constraint>**VERIFY**: Run `./mvnw clean verify` or `mvn clean verify` before promoting changes</constraint>
     </constraint-list>

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <prompt xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:noNamespaceSchemaLocation="https://jabrena.github.io/pml/schemas/0.7.0/pml.xsd"
-      id="134-java-testing-fuzzing-testing">
+      id="703-technologies-fuzzing-testing">
   <metadata>
     <author>Juan Antonio Breña Moral</author>
     <version>0.14.0-SNAPSHOT</version>
@@ -47,7 +47,7 @@ Design and implement contract-driven fuzz testing for Java APIs using CATS to un
 
   <references>
     <reference-list>
-        <reference>references/134-java-testing-fuzzing-testing.md</reference>
+        <reference>references/703-technologies-fuzzing-testing.md</reference>
     </reference-list>
   </references>
 </prompt>
@@ -27,7 +27,6 @@
   {"name": "131-java-testing-unit-testing"},
   {"name": "132-java-testing-integration-testing"},
   {"name": "133-java-testing-acceptance-tests"},
-  {"name": "134-java-testing-fuzzing-testing"},
   {"name": "141-java-refactoring-with-modern-features"},
   {"name": "142-java-functional-programming"},
   {"name": "143-java-functional-exception-handling"},
@@ -65,6 +64,7 @@
   {"name": "523-frameworks-micronaut-testing-acceptance-tests"},
   {"name": "701-technologies-openapi"},
   {"name": "702-technologies-wiremock"},
+  {"name": "703-technologies-fuzzing-testing"},
   {"name": "behaviour-consultative-interaction"},
   {"name": "behaviour-progressive-learning"},
   {"name": "behaviour-article-writer"}

@@ -19,7 +19,6 @@
         3. **Describe HTTP** faithfully: stable paths, correct verbs, explicit status codes and error bodies, `operationId`, parameters (path, query, header, cookie), and request/response `content` types.
         4. **Security**: declare `securitySchemes` and default/global `security` requirements; avoid silent optional auth where the runtime always enforces it.
         5. **Quality gates**: recommend spec linting (e.g. Spectral rulesets), CI validation before codegen, and changelog discipline for breaking vs additive changes.
-        6. **Delegation**: for runtime stack concerns (Spring MVC, Quarkus REST, Micronaut controllers, framework plugins, OpenAPI Generator options), direct users to `@302-frameworks-spring-boot-rest`, `@402-frameworks-quarkus-rest`, or `@502-frameworks-micronaut-rest`. For **CATS fuzz execution**, use `@134-java-testing-fuzzing-testing`.
 
         Do not replace those framework skills; complement them with contract-level guidance only.
     </goal>

@@ -17,17 +17,17 @@ Help teams produce maintainable **OpenAPI 3.x** contracts that stay aligned with
 - Reusable `components` (schemas, parameters, responses, security schemes) and examples
 - Validation and CI: spec linting, breaking-change checks, pre-codegen gates
 - Security modeling in the contract (schemes, scopes, global vs operation security)
-- Clear **delegation** to framework REST skills for runtime and generator-specific work
+- Clear boundaries between contract-first design and runtime implementation concerns
 
-**Scope:** Contract-first quality only. For **Spring Boot**, **Quarkus**, or **Micronaut** REST implementation details, use the matching `302`, `402`, or `502` skill. For **CATS fuzz testing** against a contract, use `134-java-testing-fuzzing-testing`.
+**Scope:** Contract-first quality only. Focus this skill on OpenAPI design, quality, and governance guidance.
 
 ## Constraints
 
 Keep recommendations at the OpenAPI layer unless the user explicitly asks for Java framework integration. After editing this repository's XML sources, regenerate skills and verify the build.
 
 - **MANDATORY**: Run `./mvnw compile` or `mvn compile` before proposing Java or Maven changes in the same change set
-- **FRAMEWORK**: Defer OpenAPI Generator goals, controller bindings, and runtime `/openapi` exposure to `@302-frameworks-spring-boot-rest`, `@402-frameworks-quarkus-rest`, or `@502-frameworks-micronaut-rest`
-- **FUZZING**: Defer CATS execution and CI fuzz pipelines to `@134-java-testing-fuzzing-testing`
+- **FRAMEWORK**: Keep guidance contract-centric; do not prescribe framework-specific controller wiring or runtime exposure details
+- **FUZZING**: Keep fuzzing guidance high-level and contract-focused without linking to external skill identifiers
 - **MANDATORY**: Regenerate skills with `./mvnw clean install -pl skills-generator` after editing skill or system-prompt XML in this repo
 - **VERIFY**: Run `./mvnw clean verify` or `mvn clean verify` before promoting changes
 

@@ -21,7 +21,6 @@ Apply **framework-agnostic** OpenAPI best practices so a published contract is a
 3. **Describe HTTP** faithfully: stable paths, correct verbs, explicit status codes and error bodies, `operationId`, parameters (path, query, header, cookie), and request/response `content` types.
 4. **Security**: declare `securitySchemes` and default/global `security` requirements; avoid silent optional auth where the runtime always enforces it.
 5. **Quality gates**: recommend spec linting (e.g. Spectral rulesets), CI validation before codegen, and changelog discipline for breaking vs additive changes.
-6. **Delegation**: for runtime stack concerns (Spring MVC, Quarkus REST, Micronaut controllers, framework plugins, OpenAPI Generator options), direct users to `@302-frameworks-spring-boot-rest`, `@402-frameworks-quarkus-rest`, or `@502-frameworks-micronaut-rest`. For **CATS fuzz execution**, use `@134-java-testing-fuzzing-testing`.
 
 Do not replace those framework skills; complement them with contract-level guidance only.
 

@@ -1,5 +1,5 @@
 ---
-name: 134-java-testing-fuzzing-testing
+name: 703-technologies-fuzzing-testing
 description: Use when you need to add or review fuzz testing for Java APIs with CATS — including contract-driven negative testing, malformed payload validation, boundary input exploration, CI integration, reproducible failures, and local execution guidance. Part of the skills-for-java project
 license: Apache-2.0
 metadata:
@@ -40,4 +40,4 @@ Before applying any fuzz testing changes, ensure the project compiles. If compil
 
 ## Reference
 
-For detailed guidance, examples, and constraints, see [references/134-java-testing-fuzzing-testing.md](references/134-java-testing-fuzzing-testing.md).
+For detailed guidance, examples, and constraints, see [references/703-technologies-fuzzing-testing.md](references/703-technologies-fuzzing-testing.md).
@@ -1,5 +1,5 @@
 ---
-name: 134-java-testing-fuzzing-testing
+name: 703-technologies-fuzzing-testing
 description: Use when you need to add or review fuzz testing for Java APIs with CATS — including contract-driven negative testing, malformed payload validation, boundary input exploration, CI integration, reproducible failures, and local execution guidance.
 license: Apache-2.0
 metadata: