ring/dev-team/skills/dev-fuzz-testing/SKILL.md

name	description	trigger	skip_when	NOT_skip_when	sequence	related	input_schema	output_schema	verification
ring:dev-fuzz-testing	Gate 4 of development cycle - ensures fuzz tests exist with proper seed corpus to discover edge cases, crashes, and unexpected input handling.	- After unit testing complete (Gate 3) - MANDATORY for all development tasks - Discovers crashes and edge cases via random input generation	- Not inside a development cycle (ring:dev-cycle) - Task is documentation-only, configuration-only, or non-code - No functions accept external or user-controlled input - Frontend-only project (fuzz testing applies to backend code)	- "Unit tests cover edge cases" - Fuzz tests find cases you didn't think of. - "No time for fuzz testing" - Fuzz tests catch crashes before production. - "Code is simple" - Simple code can still crash on unexpected input.	after before ring:dev-unit-testing ring:dev-property-testing	complementary ring:dev-cycle ring:dev-unit-testing ring:qa-analyst	required optional name type description unit_id string Task or subtask identifier name type items description implementation_files array string Files from Gate 0 implementation name type enum description language string go Programming language (Go only for native fuzz) name type description gate3_handoff object Full handoff from Gate 3 (unit testing)	format required_sections metrics markdown name pattern required Fuzz Testing Summary ^## Fuzz Testing Summary true name pattern required Corpus Report ^## Corpus Report true name pattern required Handoff to Next Gate ^## Handoff to Next Gate true name type values result enum PASS FAIL name type fuzz_functions integer name type corpus_entries integer name type crashes_found integer name type iterations integer	automated manual command description success_pattern grep -rn 'func Fuzz' --include='*_test.go' . Fuzz functions exist func Fuzz command description success_pattern grep -rn 'f.Add' --include='*_test.go' . Seed corpus entries exist f.Add Fuzz functions follow FuzzXxx naming convention Seed corpus has at least 5 entries per function No crashes found during 30s fuzz run

Dev Fuzz Testing (Gate 4)

Overview

Ensure critical parsing and input handling code has fuzz tests to discover crashes and edge cases through random input generation.

Core principle: Fuzz tests find bugs you didn't think to test for. They're mandatory for all code that handles external input.

<block_condition>

• No fuzz functions = FAIL
• Seed corpus < 5 entries = FAIL
• Any crash found = FAIL (fix and re-run) </block_condition>

CRITICAL: Role Clarification

This skill ORCHESTRATES. QA Analyst Agent (fuzz mode) EXECUTES.

Who	Responsibility
This Skill	Gather requirements, dispatch agent, track iterations
QA Analyst Agent	Write fuzz tests, generate corpus, run fuzz

---

Standards Reference

MANDATORY: Load testing-fuzz.md standards via WebFetch.

<fetch_required> https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/golang/testing-fuzz.md </fetch_required>

---

Step 1: Validate Input

REQUIRED INPUT:
- unit_id: [task/subtask being tested]
- implementation_files: [files from Gate 0]
- language: [go only for native fuzz]

OPTIONAL INPUT:
- gate3_handoff: [full Gate 3 output]

if any REQUIRED input is missing:
  → STOP and report: "Missing required input: [field]"

if language != "go":
  → STOP and report: "Native fuzz testing only supported for Go (Go 1.18+)"

Step 2: Dispatch QA Analyst Agent (Fuzz Mode)

Task tool:
  subagent_type: "ring:qa-analyst"
  prompt: |
    **MODE:** FUZZ TESTING (Gate 4)

    **Standards:** Load testing-fuzz.md

    **Input:**
    - Unit ID: {unit_id}
    - Implementation Files: {implementation_files}
    - Language: {language}

    **Requirements:**
    1. Create fuzz functions (FuzzXxx naming)
    2. Add seed corpus (minimum 5 entries per function)
    3. Run fuzz tests for 30 seconds
    4. Report any crashes found

    **Output Sections Required:**
    - ## Fuzz Testing Summary
    - ## Corpus Report
    - ## Handoff to Next Gate

Step 3: Evaluate Results

Parse agent output:

if "Status: PASS" in output:
  → Gate 4 PASSED
  → Return success with metrics

if "Status: FAIL" in output:
  → Dispatch fix to implementation agent
  → Re-run fuzz tests (max 3 iterations)
  → If still failing: ESCALATE to user

Step 4: Generate Output

## Fuzz Testing Summary
**Status:** {PASS|FAIL}
**Fuzz Functions:** {count}
**Corpus Entries:** {count}
**Crashes Found:** {count}

## Corpus Report
| Function | Entries | Crashes |
|----------|---------|---------|
| {function_name} | {count} | {count} |

## Handoff to Next Gate
- Ready for Gate 5 (Property Testing): {YES|NO}
- Iterations: {count}

---

Severity Calibration

Severity	Criteria	Examples
CRITICAL	Crash found, security vulnerability discovered	Panic on input, buffer overflow, memory corruption
HIGH	No fuzz functions, missing corpus	Zero FuzzXxx functions, empty seed corpus
MEDIUM	Insufficient corpus, naming issues	Less than 5 corpus entries, non-standard function names
LOW	Coverage gaps, optimization	Missing edge case seeds, fuzz duration improvements

Report all severities. CRITICAL = immediate fix and re-fuzz. HIGH = fix before gate pass. MEDIUM = fix in iteration. LOW = document.

---

Anti-Rationalization Table

Rationalization	Why It's WRONG	Required Action
"Unit tests cover edge cases"	You can't test what you don't think of. Fuzz finds unknowns.	Write fuzz tests
"Code is too simple for fuzz"	Simple code can still crash on malformed input.	Write fuzz tests
"Fuzz testing is slow"	30 seconds per function. Crashes in production are slower.	Write fuzz tests
"We validate input anyway"	Validation can have bugs too. Fuzz tests the validators.	Write fuzz tests

---