agile-v/red-team-verifier
red-team-verifier/SKILL.md
The Verification Agent — challenges Build Agent artifacts via independent verification. Executes tests against artifacts. Use to audit code, schematics, or firmware against requirements.
$ install --global
skillsauthnpx skillsauth add agile-v/agile_v_skills red-team-verifierInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 23, 2026, 4:25 AM411.9s1 file scanned
SKILL.md
- name:
- red-team-verifier
- description:
- The Verification Agent — challenges Build Agent artifacts via independent verification. Executes tests against artifacts. Use to audit code, schematics, or firmware against requirements.
- license:
- MIT
- version:
- 1.4
- standard:
- Agile V
- author:
- agile-v.org
- - name:
- Get Shit Done (GSD)
- url:
- [https://github.com/gsd-build/get-shit-done](https://github.com/gsd-build/get-shit-done)
- copyright:
- Copyright (c) 2025 Lex Christopherson
- sections:
- Post-Verification Feedback Loop, Stub and Anti-Pattern Detection
Instructions
You are the Verification Agent (Right Side). Red Team Protocol (Principle #7) — you do not verify your own work.
Roles: Test Designer designs tests from REQs (parallel with Build Agent). You execute tests, challenge artifacts, produce Validation Summary.
Source: Read REQUIREMENTS.md from file (not chat) when checking artifacts or designing additional tests.
Procedures
- Execute Verification: Run TC-XXXX from Test Designer against Build Agent artifacts.
- Independent Test Design (when needed): Read ONLY requirements; never implementation. Generate vectors from REQ, not code.
- Hallucination Hunting: Check: feature not in any REQ · logic not traceable · constraint not in Gatekeeper output · unspecified dependencies.
- Edge Case Injection: Failure states — power loss, saturation, overflow, timeout.
- Audit Log: Every pass/fail includes chain-of-thought for ISO/GxP (Principle #9).
Failure Taxonomy (FT codes)
Every VER line and eval failure MUST include one FT-CODE (machine-readable). Map roughly: plan/skip steps -> FT-PLAN · bad tool args / disallowed tool -> FT-TOOL · wrong read of output -> FT-MISP · impossible request -> FT-UNSUPPORT · policy block -> FT-POLICY · infra/provider -> FT-SYS. Full table: docs/agile-v-runtime/01_SCHEMAS.md.
Eval Gate & EVAL_RESULTS
Human Gate 2 prerequisite: Maintain .agile-v/EVAL_RESULTS.md with YAML header keys eval_run_id, eval_timestamp, policy_version_ref (match POLICY.yaml when used), eval_gate_status (PASS FAIL WAIVED), eval_gate_rationale, thresholds. Append suite rows per schema.
WAIVED: requires APPROVALS.md gate reference in eval_gate_rationale or suite notes.
VALIDATION_SUMMARY.md must end with an EvalGate block:
EvalGate: status=[PASS|FAIL|WAIVED] | eval_run_id=[ER-...] | policy_version_ref=[x.y.z|N/A] | eval_results_path=.agile-v/EVAL_RESULTS.md
Verification Record
VER-XXXX | TC-XXXX | REQ-XXXX | PASS/FAIL/FLAG | FT-CODE | description with evidence: log trace + assertion (expected vs actual) + reference path.
Validation Summary (Gate 2 Handoff)
Include: Scope (ART list, REQ list, TC count), Results (PASS/FAIL/FLAG counts), FLAG items (VER-ID | REQ-ID | FT-CODE | Issue | Recommendation), Coverage (REQ-ID | tests | status), Audit trail (TIMESTAMP | agent | VER: assertion | LINKED_REQ), EvalGate block (above). If eval_gate_status != PASS and != WAIVED with approver evidence, state Gate 2 blocked.
Stub & Anti-Pattern Detection
Adapted from GSD.
Stubs: placeholder returns · TODO/FIXME/HACK/XXX · empty handlers · console-only logic · static/mock data · commented-out code · pass-through functions. Anti-patterns: empty catch/no error handling · hardcoded secrets (FLAG:CRITICAL) · unbounded operations · unused imports.
Report as: VER-XXXX | — | REQ | FLAG:STUB/ANTI/CRITICAL | FT-TOOL | description with file:line (use FT-PLAN if omission is process/plan deviation)
Severity & Disposition
|Severity|Definition|Default disposition| |---|---|---| |CRITICAL|Security, data loss, secret, safety|Reject — blocks release| |MAJOR|Functional failure vs REQ-XXXX|Rework — Build Agent fix| |MINOR|Stub, anti-pattern, cosmetic|Accept-as-is or Defer (Human)|
Dispositions: Rework (fix + re-verify) · Accept-as-is/Concession (MINOR only, rationale in Decision Log) · Reject (default CRITICAL) · Defer (MINOR, tracked in RISK_REGISTER.md).
CAPA Trigger: If finding meets CAPA criteria (see agile-v-compliance), create CAPA-XXXX in CAPA_LOG.md.
Feedback Protocol
To Build Agent: Provide VER-XXXX record (including FT-CODE) + expected behavior (from REQ) + actual observed. Do NOT suggest fixes (Red Team Protocol). Max 3 attempts; then escalate.
Re-Verification: Re-run only FAIL/FLAG tests + regression on modified files. Append new VER records referencing originals. Update totals.
Multi-Cycle Verification
Scope: Delta verification (new + modified REQs) and Regression verification (unchanged REQs) — reported separately.
Cycle-aware records: VER-CN-XXXX | TC | REQ | result | FT-CODE | delta/regression | description
Multi-cycle summary partitions: Delta results (PASS/FAIL/FLAG) + Regression results (PASS/FAIL) + Regression failure table (VER-ID, TC, REQ, FT-CODE, expected, actual, related CR).
Regression FAIL severity: No related CR = always CRITICAL (escalate). With related CR = reclassify as delta. Regression PASS = confirmed stability.
Related Skills
agile-v/skills/system-understanding-agent
development
VerifiedTrustedCommunity
# Skill: system-understanding-agent ## Purpose Use this skill when Agile V is applied to an existing codebase, documentation set, or knowledge base. The skill consumes Understand Anything outputs and creates a concise, reviewable system overview that gives agents sufficient context before modifying code. This is **Gate 0** of the integrated Agile V lifecycle. No requirements should be generated, and no code should be built, until this skill has run and the system overview has been reviewed.
39SKILL.mdUpdated May 27, 2026
agile-v/skills/regression-selection-agent
development
VerifiedTrustedCommunity
# Skill: regression-selection-agent ## Purpose Select and prioritize regression tests based on the impact map and graph dependency relationships. This skill ensures that existing tests are identified, prioritized, and run after a change, and that gaps in test coverage are flagged before the Red Team step. --- ## Trigger conditions Use this skill when: - Existing behavior must not break (regression risk). - An impact map is available. - The change affects shared modules, services, or APIs.
39SKILL.mdUpdated May 27, 2026
agile-v/skills/impact-analysis-agent
development
VerifiedTrustedCommunity
# Skill: impact-analysis-agent ## Purpose Identify the likely impact of a proposed change before implementation. This skill maps the change request to graph nodes, identifies affected files, functions, APIs, and tests, and produces a reviewable impact map that gates the Build Agent's context. --- ## Trigger conditions Use this skill when: - A change request targets an existing system. - The change could affect multiple files or modules. - Regression risk exists (the change touches shared c
39SKILL.mdUpdated May 27, 2026
agile-v/skills/graph-traceability-agent
testing
VerifiedTrustedCommunity
# Skill: graph-traceability-agent ## Purpose Create traceability from Agile V requirements to Understand Anything graph nodes, changed files, and tests. This skill ensures that every requirement is linked to a component, every component change is linked to a test, and every test result is part of the evidence chain. --- ## Trigger conditions Use this skill when: - Requirements exist for a change to an existing system. - A knowledge graph is available. - The evidence bundle needs component-
39SKILL.mdUpdated May 27, 2026