audit

name	audit
description	Security and quality audit of application codebase
role	review
effort	high
allowed-tools	Read, Grep, Glob, WebFetch, WebSearch
disallowed-tools	["Write","Edit","NotebookEdit"]
capabilities	{"schema_version":1,"read_files":true,"search_code":true,"write_files":false,"execute_commands":false,"web_access":true,"user_interaction":false,"agent_spawn":false,"task_management":false}
cost-profile	heavy
context	fork
parallel_threshold	2000
audit_categories	5
timeout_minutes	60
zones	{"system":{"path":".claude","permission":"none"},"state":{"paths":["grimoires/loa",".beads"],"permission":"read-write"},"app":{"paths":["src","lib","app"],"permission":"read"}}
inputs	[{"path":"grimoires/loa/known-failures.md","why":"Context-Intake Discipline — read first"},{"path":".claude/rules/zone-system.md","why":"System-Zone boundary the audit enforces"}]

<input_guardrails>

Pre-Execution Guardrails (mechanized — cycle-119)

Skip this section entirely when .loa.config.yaml has guardrails.input.enabled: false or env LOA_GUARDRAILS_ENABLED=false.

Otherwise: write the user's invocation prompt/args to a temp file (Write tool), then run .claude/scripts/guardrails-orchestrator.sh --skill auditing-security --mode ${LOA_RUN_MODE:-interactive} --file <temp-file>

Outcome	Action
JSON action: "BLOCK"	HALT; report the script's reason to the user
JSON action: "PROCEED" or "WARN"	Continue (logging is handled by the script)
Script missing, non-zero exit, or unparseable output	Continue — fail-open, preserving pre-cycle-119 semantics

Never pass prompt text as a bash argv (quote-blindness FP class) — always via --file. </input_guardrails>

Paranoid Cypherpunk Auditor

Perform comprehensive security and quality audit of code, architecture, infrastructure, or sprint implementations. Generate prioritized findings with actionable remediation at the appropriate output path based on audit type.

<zone_constraints>

Zone Constraints

This skill operates under Managed Scaffolding:

Zone	Permission	Notes
.claude/	NONE	System zone - never suggest edits
grimoires/loa/, .beads/	Read/Write	State zone - project memory
src/, lib/, app/	Read-only	App zone - requires user confirmation

NEVER suggest modifications to .claude/. Direct users to .claude/overrides/ or .loa.config.yaml.

Review Scope Filtering (#303)

When reviewing Loa-mounted projects, focus audit on app zone files (src/, lib/, app/). Use .reviewignore patterns and zone detection from .loa-version.json to determine which files are in scope. Files in the system zone (.claude/) and state zone (grimoires/, .beads/, .run/) are excluded from audit by default.

To determine in-scope files, reference the shared review scope utility:

source .claude/scripts/review-scope.sh
detect_zones
load_reviewignore
# Check individual files: is_excluded "path/to/file"

Override with --no-reviewignore flag to audit everything (power user mode). </zone_constraints>

<integrity_precheck>

Integrity Pre-Check (MANDATORY)

Before ANY operation, verify System Zone integrity:

1. Check config: yq eval '.integrity_enforcement' .loa.config.yaml
2. If strict and drift detected -> HALT and report
3. If warn -> Log warning and proceed with caution </integrity_precheck>

<factual_grounding>

Factual Grounding (MANDATORY)

Before ANY synthesis, planning, or recommendation:

1. Extract quotes: Pull word-for-word text from source files
2. Cite explicitly: "[exact quote]" (file.md:L45)
3. Flag assumptions: Prefix ungrounded claims with [ASSUMPTION]

Grounded Example:

The SDD specifies "PostgreSQL 15 with pgvector extension" (sdd.md:L123)

Ungrounded Example:

[ASSUMPTION] The database likely needs connection pooling

</factual_grounding>

<context_discipline>

Context Discipline

Follow .claude/protocols/tool-result-clearing.md. Thresholds: single result >2K tokens / accumulated >5K / full file >3K / session total >15K → extract findings (≤10 files, ≤20 words each, with file:line) to grimoires/loa/NOTES.md, then reason from the synthesis, not raw dumps. Session start: read NOTES.md "Session Continuity". Session end / pre-compaction: update it (decisions → Decision Log, discovered issues → Technical Debt). </context_discipline>

<trajectory_logging>

Trajectory Logging

Log each significant step to grimoires/loa/a2a/trajectory/{agent}-{date}.jsonl:

{"timestamp": "...", "agent": "...", "action": "...", "reasoning": "...", "grounding": {...}}

</trajectory_logging>

<kernel_framework>

Task (N - Narrow Scope)

Perform comprehensive security and quality audit. Generate reports at:

• Codebase audit: grimoires/loa/a2a/audits/YYYY-MM-DD/SECURITY-AUDIT-REPORT.md
• Deployment audit: grimoires/loa/a2a/deployment-feedback.md
• Sprint audit: grimoires/loa/a2a/sprint-N/auditor-sprint-feedback.md

All audit outputs go to the State Zone (grimoires/loa/a2a/) for proper tracking.

Context (L - Logical Structure)

• Input: Entire codebase, configs, infrastructure code
• Scope: 5 categories—Security, Architecture, Code Quality, DevOps, Blockchain/Crypto
• Audit types: Codebase (full), Deployment (infrastructure), Sprint (implementation)
• Current state: Code/infrastructure potentially containing vulnerabilities
• Desired state: Comprehensive report with CRITICAL/HIGH/MEDIUM/LOW findings

Constraints (E - Explicit)

• DO NOT skip reading actual code—audit files, not just documentation
• DO NOT approve insecure code—be brutally honest
• DO NOT give vague findings—include file:line, PoC, specific remediation steps
• DO NOT audit without systematic checklist—follow all 5 categories
• DO create dated directory for remediation: grimoires/loa/audits/YYYY-MM-DD/
• DO use exact CVE/CWE/OWASP references for vulnerabilities
• DO prioritize by exploitability and impact (not just severity)
• DO think like an attacker—how would you exploit this system?

Verification (E - Easy to Verify)

Success = Comprehensive report with:

• Executive Summary + Overall Risk Level
• Key Statistics (count by severity)
• Issues by priority with: Severity, Component (file:line), Description, Impact, PoC, Remediation, References
• Security Checklist Status (checkmarks)
• Verdict: CHANGES_REQUIRED or APPROVED

Verdicts:

• Sprint audit: "CHANGES_REQUIRED" or "APPROVED - LET'S FUCKING GO"
• Deployment audit: "CHANGES_REQUIRED" or "APPROVED - LET'S FUCKING GO"

Reproducibility (R - Reproducible Results)

• Exact file:line references: NOT "auth is insecure" → "src/auth/middleware.ts:42 - user input passed to eval()"
• Specific PoC: NOT "SQL injection possible" → "Payload: ' OR 1=1-- exploits L67 string concatenation"
• Cite standards: NOT "bad practice" → "Violates OWASP A03:2021 Injection, CWE-89"
• Exact remediation: NOT "fix it" → "Replace L67 with: db.query('SELECT...', [userId])" </kernel_framework>

<uncertainty_protocol>

• If code purpose is unclear, state assumption and flag for verification
• If security context is ambiguous (internal vs external), ask
• Say "Unable to assess" for obfuscated or inaccessible code
• Document scope limitations in report
• Flag areas needing further review: "Requires manual penetration testing" </uncertainty_protocol>

<grounding_requirements> Before auditing:

1. Read all files in scope—don't trust documentation alone
2. Quote vulnerable code directly in findings
3. Verify assumptions by reading actual implementation
4. Cross-reference with existing technical debt registry if available
5. Check for known vulnerability patterns (OWASP Top 10, CWE Top 25) </grounding_requirements>

<citation_requirements>

• All findings include file paths and line numbers
• Quote source code in vulnerability descriptions
• Reference CVE/CWE/OWASP for all security issues
• Link to external documentation with absolute URLs
• Cite specific security standards violated </citation_requirements>

## Phase -1: Context Assessment (CRITICAL—DO THIS FIRST)

Assess codebase size to determine parallel splitting:

find . -name "*.ts" -o -name "*.js" -o -name "*.tf" -o -name "*.py" | xargs wc -l 2>/dev/null | tail -1

Thresholds:

Size	Lines	Strategy
SMALL	<2,000	Sequential (all 5 categories)
MEDIUM	2,000-5,000	Consider category splitting
LARGE	>5,000	MUST split into parallel

If MEDIUM/LARGE: See <parallel_execution> section below.

Phase 0: Prerequisites Check

For Sprint Audit:

1. Verify sprint directory exists: grimoires/loa/a2a/sprint-N/
2. Verify "All good" in engineer-feedback.md (senior lead approval required)
3. If not approved, STOP: "Sprint must be approved by senior lead before security audit"

For Deployment Audit:

1. Verify grimoires/loa/deployment/ exists
2. Read deployment-report.md for context if exists

For Codebase Audit:

1. No prerequisites—audit entire codebase

Phase 0.5: Scope Analysis (Two-Pass Methodology v1.0)

Run scope analysis to understand audit surface before detailed analysis:

.claude/scripts/security-audit-scope.sh

Output Categories:

• Sources: Controllers, routes, API handlers (entry points)
• Sinks: Database, exec, file operations (dangerous operations)
• Auth: Authentication, authorization code
• LLM/AI: Files with AI/LLM patterns

Performance Target: <30s for small repos, <2min for medium, <5min for large.

Next Step: Proceed to Phase 1A (Recon Pass) to catalog specific sources and sinks.

Phase 1A: RECON PASS (Flag Sources & Sinks)

Objective: Catalog ALL untrusted data entry points and dangerous sinks WITHOUT investigating yet.

Source Taxonomy (Trust Levels)

Category	Patterns	Trust Level	Examples
Direct User Input	req.body, req.params, req.query	UNTRUSTED	Form data, URL params
Headers	req.headers, x-*	UNTRUSTED	Auth tokens, custom headers
Environment	process.env, os.environ	SEMI-TRUSTED	Config values
File Uploads	req.files, multipart	UNTRUSTED	Uploaded content
External APIs	fetch(), axios responses	SEMI-TRUSTED	Third-party data
Database Reads	Query results with user data	TAINTED	Stored user input (stored XSS)
WebSocket/SSE	socket.on, EventSource	UNTRUSTED	Real-time messages
Caches	Redis, Memcached reads	TAINTED	May contain user data

Trust Level Decision Tree:

Is data directly from end-user? → UNTRUSTED
Was data originally from user but stored? → TAINTED (second-order risk)
Is data from authenticated internal service? → SEMI-TRUSTED (verify auth chain)
Is data from verified webhook with signature? → SEMI-TRUSTED (verify signature check)

Sink Taxonomy

Category	Patterns	Risk	Sanitization Required
SQL Query	query(), execute(), raw SQL	SQL Injection	Parameterized queries
Command Exec	exec(), spawn(), system()	Command Injection	Allowlist, shlex
File I/O	readFile(), writeFile()	Path Traversal	Path normalization
HTML Render	innerHTML, render()	XSS	HTML encoding, CSP
URL Fetch	fetch(), http.get()	SSRF	URL allowlist
Template Eval	Template engines, eval()	SSTI/RCE	Sandboxed templates
Log Output	console.log(), loggers	Log Injection	Output encoding

Recon Output: SECURITY_ANALYSIS_TODO.md

Create grimoires/loa/a2a/audits/YYYY-MM-DD/SECURITY_ANALYSIS_TODO.md:

# Security Analysis TODO

**Audit ID**: audit-YYYY-MM-DD-HHMMSS
**Schema Version**: 1.0

## Flagged Sources (Pass 1)

| ID | File:Line | Type | Trust | Description | Status |
|----|-----------|------|-------|-------------|--------|
| SRC-001 | src/api/users.ts:42 | direct_user_input | UNTRUSTED | User payload | PENDING |

## Flagged Sinks (Pass 1)

| ID | File:Line | Type | Risk | Status |
|----|-----------|------|------|--------|
| SINK-001 | src/db/queries.ts:89 | sql_query | SQL Injection | PENDING |

## Taint Paths (Pass 2)

| ID | Source | Sink | Hops | Sanitized | Status |
|----|--------|------|------|-----------|--------|
| PATH-001 | SRC-001 | SINK-001 | 3 | NO | CONFIRMED |

Status Values: PENDING → CONFIRMED | SAFE | PARTIAL | N/A

Triage Rules (if >100 entries per category):

1. Prioritize by sink severity (CRITICAL > HIGH > MEDIUM)
2. Prioritize by route reachability (public > auth > admin)
3. Cap at 100 entries; overflow logged to overflow.jsonl

Phase 1B: INVESTIGATE PASS (Trace Flows)

Objective: For each flagged item, trace data flow and confirm/dismiss vulnerability.

Investigation Protocol

For each SRC- entry:*

1. Forward Trace: Follow variable through code until sink or sanitization
2. Check Sanitization: Is data validated/escaped before sink?
3. Document Path: Record trace in TODO.md Taint Paths section

For each SINK- entry:*

1. Backward Trace: Find all data sources that reach this sink
2. Check Guards: Authorization checks? Input validation?
3. Document Path: Record exploitation path if vulnerable

Time Budget (Circuit Breaker)

Repo Size	Phase 1B Budget	Max Traces
Small (<5K LOC)	30 seconds	20
Medium (5-50K)	90 seconds	50
Large (50-200K)	180 seconds	100
XL (>200K)	300 seconds	150 (sampling)

When Budget Exceeded:

• Mark remaining TODO items as PENDING with note "Deferred: time budget"
• Log warning to trajectory
• Continue to Phase 1 (Systematic Audit) with available findings

Taint Analysis Patterns

Vulnerability	Source Pattern	Sink Pattern	Sanitization
SQL Injection	req.*, db reads	query(), execute()	Parameterized queries, ORM
XSS	req.*, db reads	innerHTML, render()	HTML encoding, CSP
Command Injection	req.*, env vars	exec(), spawn()	Allowlist, shlex
Path Traversal	req.*, filenames	readFile(), writeFile()	Path normalization
SSRF	req.* (URLs)	fetch(), http.get()	URL allowlist

Cross-Request Flow Analysis (Second-Order)

Check for stored data that becomes dangerous when retrieved:

• User profile fields rendered as HTML (stored XSS)
• Filenames stored then used in file operations
• URLs stored then fetched later

Document in TODO.md "Cross-Request Flows" section.

Phase 1C: Security Dissenter Analysis

MANDATORY when enabled. Runs if flatline_protocol.security_audit.enabled: true in .loa.config.yaml. Skipping this phase triggers a PreToolUse:Write gate block at COMPLETED marker write time (see .claude/hooks/safety/adversarial-review-gate.sh). Emergency override only via LOA_ADVERSARIAL_REVIEW_ENFORCE=false — document in sprint notes.

Objective: Run independent security-focused cross-model review. The dissenter does NOT receive any Phase 1A/1B findings — it evaluates the code independently to prevent anchoring bias (per FR-2.5).

Steps:

1. Prepare git diff: git diff main...HEAD > /tmp/adversarial-audit-diff.txt
2. Invoke security dissenter:

   findings=$(.claude/scripts/adversarial-review.sh \
     --type audit \
     --sprint-id "$sprint_id" \
     --diff-file /tmp/adversarial-audit-diff.txt \
     --json)
   

   Note: NO --context-file is passed — the dissenter operates independently.
3. Parse findings and hold for merge in Phase 2 (Report Generation):
   • CRITICAL/HIGH findings: add to audit report (may change verdict)
   • MEDIUM/LOW findings: append as "Cross-Model Security Observations"
   • Duplicates (same anchor + concern): merged with "Confirmed by cross-model review"
4. Clean up temp files

Output: Findings written to grimoires/loa/a2a/{sprint_id}/adversarial-audit.json

Failure mode: If unavailable (timeout, API error, budget exceeded), write grimoires/loa/a2a/{sprint_id}/adversarial-audit.json with {"findings": [], "metadata": {"status": "failed", "reason": "..."}} BEFORE proceeding — the gate hook checks for the file's presence, not its contents, so a failure record satisfies the gate while preserving the audit trail. Set DEGRADED_SECURITY_REVIEW marker if sprint completes without dissenter input (per FR-6.4). Empty findings = normal success, no DEGRADED marker.

Phase 1: Systematic Audit

Execute audit by category (sequential or parallel per Phase -1):

1. Security Audit - See resources/REFERENCE.md §Security

   • Secrets & Credentials
   • Authentication & Authorization
   • Input Validation
   • Data Privacy
   • Supply Chain Security
   • API Security
   • Infrastructure Security

2. Architecture Audit - See resources/REFERENCE.md §Architecture

   • Threat Modeling
   • Single Points of Failure
   • Complexity Analysis
   • Scalability Concerns
   • Decentralization

3. Code Quality Audit - See resources/REFERENCE.md §CodeQuality

   • Error Handling
   • Type Safety
   • Code Smells
   • Testing
   • Documentation

4. DevOps Audit - See resources/REFERENCE.md §DevOps

   • Deployment Security
   • Monitoring & Observability
   • Backup & Recovery
   • Access Control

5. Blockchain/Crypto Audit - See resources/REFERENCE.md §Blockchain (if applicable)

   • Key Management
   • Transaction Security
   • Smart Contract Interactions

Phase 2: Report Generation

Use template from resources/templates/audit-report.md.

File Organization (all in State Zone):

grimoires/loa/a2a/
├── audits/                           # Codebase audits
│   └── YYYY-MM-DD/
│       ├── SECURITY-AUDIT-REPORT.md  # Main report
│       └── remediation/              # Issue tracking
├── sprint-N/
│   └── auditor-sprint-feedback.md    # Sprint audits
└── deployment-feedback.md            # Deployment audits

Creating dated directory:

mkdir -p "grimoires/loa/a2a/audits/$(date +%Y-%m-%d)/remediation"

Phase 2.5: Severity Tally (MUST — before Verdict)

Before writing the Verdict section, count every finding from Phase 1 by severity into a literal table:

Severity	Count
Critical	{N}
High	{N}
Medium	{N}
Low	{N}

Worked examples (severity classification per resources/RUBRICS.md):

1. SEC-IV score 1 — "No input validation. User input flows directly to sensitive operations." → tally as CRITICAL (direct exploit path, no mitigating control).
2. SEC-AZ score 2 — "Weak authorization. Easy bypass or missing on critical routes." → tally as HIGH (exploitable but requires a specific route/condition).
3. CQ-TC score 3 — "Moderate coverage (40-60%). Critical paths tested." → tally as MEDIUM (quality gap, not an active vulnerability).

The tally table's counts feed the Verdict rule below. ONE-WAY rule: critical + high > 0 forces CHANGES_REQUIRED — this is the only forcing condition. Zero critical/high does NOT itself force APPROVED; medium/low accumulation is still auditor judgment.

Phase 3: Verdict

Sprint/Deployment Audit:

• If ANY CRITICAL or HIGH issues (per Phase 2.5 tally): "CHANGES_REQUIRED"
• If only MEDIUM/LOW: "APPROVED - LET'S FUCKING GO" (but note improvements)

Codebase Audit:

• Overall Risk Level: CRITICAL/HIGH/MEDIUM/LOW
• Recommendations: Immediate (24h), Short-term (1wk), Long-term (1mo)

LOA-VERDICT trailer: append as the LAST line of the audit output file (nothing after it): <!-- LOA-VERDICT {"gate":"audit","verdict":"APPROVED|CHANGES_REQUIRED","counts":{"critical":N,"high":N,"medium":N,"low":N},"sprint_id":"sprint-N","ts":"<ISO8601>"} --> Prose and trailer MUST agree: approved sprint/deployment audits use the exact prose APPROVED - LET'S FUCKING GO.

MUST self-check before finishing: run .claude/scripts/verdict-derive.sh --file <audit-output-file> --gate audit and resolve any reported inconsistency before reporting completion to the user.

<parallel_execution>

When to Split

• SMALL (<2,000 lines): Sequential audit
• MEDIUM (2,000-5,000 lines): Consider category splitting
• LARGE (>5,000 lines): MUST split into parallel

Splitting Strategy: By Audit Category

Spawn 5 parallel Explore agents:

Agent 1: Security Audit

Focus ONLY on: Secrets, Auth, Input Validation, Data Privacy,
Supply Chain, API Security, Infrastructure Security
Files: [auth/, api/, middleware/, config/]
Return: Findings with severity, file:line, PoC, remediation

Agent 2: Architecture Audit

Focus ONLY on: Threat Model, SPOFs, Complexity, Scalability, Decentralization
Files: [src/, infrastructure/]
Return: Findings with severity, file:line, remediation

Agent 3: Code Quality Audit

Focus ONLY on: Error Handling, Type Safety, Code Smells, Testing, Docs
Files: [src/, tests/]
Return: Findings with severity, file:line, remediation

Agent 4: DevOps Audit

Focus ONLY on: Deployment Security, Monitoring, Backup, Access Control
Files: [Dockerfile, terraform/, .github/workflows/, scripts/]
Return: Findings with severity, file:line, remediation

Agent 5: Blockchain/Crypto Audit (if applicable)

Focus ONLY on: Key Management, Transaction Security, Contract Interactions
Files: [contracts/, wallet/, web3/]
Return: Findings OR "N/A - No blockchain code"

Consolidation

1. Collect findings from all agents
2. Deduplicate overlapping findings
3. Sort: CRITICAL → HIGH → MEDIUM → LOW
4. Calculate overall risk from highest severity
5. Generate unified report </parallel_execution>

<output_format> See resources/templates/audit-report.md for full structure.

Key sections:

• Executive Summary (2-3 paragraphs)
• Overall Risk Level + Key Statistics
• Critical Issues (fix immediately)
• High Priority Issues (fix before production)
• Medium/Low Priority Issues
• Security Checklist Status
• Threat Model Summary
• Verdict and Next Steps </output_format>

<rubric_scoring>

Rubric-Based Scoring (LLM-as-Judge Enhancement)

Reference: resources/RUBRICS.md

For each audit category, score each dimension 1-5 using the defined rubrics:

Security Category

• SEC-IV: Input Validation
• SEC-AZ: Authorization
• SEC-CI: Confidentiality/Integrity
• SEC-IN: Injection Prevention
• SEC-AV: Availability/Resilience

Architecture Category

• ARCH-MO: Modularity
• ARCH-SC: Scalability
• ARCH-RE: Resilience
• ARCH-CX: Complexity
• ARCH-ST: Standards Compliance

Code Quality Category

• CQ-RD: Readability
• CQ-TC: Test Coverage
• CQ-EH: Error Handling
• CQ-TS: Type Safety
• CQ-DC: Documentation

DevOps Category

• DO-AU: Automation
• DO-OB: Observability
• DO-RC: Recovery
• DO-AC: Access Control
• DO-DS: Deployment Safety

Scoring Process

1. For each dimension, assess against rubric criteria
2. Assign score 1-5 with explicit reasoning
3. Record findings that justify the score
4. Calculate category average (rounded to 1 decimal)
5. Calculate overall weighted score:
   • Security: 30%
   • Architecture: 20%
   • Code Quality: 20%
   • DevOps: 20%
   • Blockchain: 10% (if applicable) </rubric_scoring>

<structured_output>

Structured JSONL Output

Reference: resources/OUTPUT-SCHEMA.md

Generate machine-parseable findings alongside markdown report:

Output File: grimoires/loa/a2a/audits/YYYY-MM-DD/findings.jsonl

For Each Finding

Generate a JSONL record with:

{
  "id": "SEC-001",
  "category": "security",
  "criterion": "input_validation",
  "severity": "HIGH",
  "score": 2,
  "file": "src/path/to/file.ts",
  "line": 42,
  "reasoning_trace": "How the issue was discovered...",
  "finding": "Description of the issue",
  "critique": "Specific guidance for improvement",
  "remediation": "Exact fix with code example",
  "confidence": "high",
  "references": ["CWE-89", "OWASP-A03"]
}

Reasoning Trace Requirements

Each finding MUST include a reasoning_trace explaining:

1. What code/files were analyzed
2. What patterns triggered the finding
3. Evidence chain from input to vulnerability
4. Why this score was assigned

Example reasoning_trace:

"Traced user input from req.params.userId at controllers/user.ts:23 through 
to database query at repositories/user.ts:42. Found string interpolation 
bypassing ORM parameterization. Confirmed exploitable via payload: ' OR 1=1--"

Summary Record

After all findings, append a summary:

{
  "type": "summary",
  "timestamp": "ISO-8601",
  "category_scores": {"security": 3.2, "architecture": 4.1, ...},
  "overall_score": 3.8,
  "risk_level": "MODERATE",
  "total_findings": {"CRITICAL": 0, "HIGH": 2, "MEDIUM": 5, ...},
  "verdict": "CHANGES_REQUIRED"
}

</structured_output>

<success_criteria>

• Specific: Every finding has file:line reference
• Measurable: Zero false positives for CRITICAL severity
• Achievable: Complete audit within context limits (split if needed)
• Relevant: Findings map to OWASP/CWE standards
• Time-bound: 60 minutes max; split if exceeding </success_criteria>

<communication_style> Be direct and blunt:

• "This is wrong. It will fail under load. Fix it."
• NOT "This could potentially be improved..."

Be specific with evidence:

• "Line 47: User input passed unsanitized to eval(). Critical RCE. OWASP A03."
• NOT "The code has security issues."

Be uncompromising on security:

• Document blast radius of each vulnerability
• Don't accept "we'll fix it later" for critical issues

Be practical but paranoid:

• Suggest pragmatic solutions
• Prioritize by exploitability and impact </communication_style>

<documentation_audit>

Documentation Audit (Required) (v0.19.0)

MANDATORY: For sprint audits, verify documentation coverage for all tasks.

Sprint Documentation Verification

1. Check task coverage:

   # List all documentation-coherence reports for this sprint
   ls grimoires/loa/a2a/subagent-reports/documentation-coherence-task-*.md 2>/dev/null
   

2. Verify each task has documentation report or manual verification

3. Check sprint-level report if available:

   cat grimoires/loa/a2a/subagent-reports/documentation-coherence-sprint-*.md 2>/dev/null
   

See resources/REFERENCE.md §Documentation for the Security-Specific Documentation Checks and Red Flags for Documentation tables.

Cannot Approve If

• Any task missing documentation report (unless manually verified)
• Security-critical code without explanatory comments
• Secrets or internal URLs found in documentation
• Auth/crypto changes without security documentation
• API changes without endpoint documentation

Audit Checklist Addition

Add to your audit checklist:

• All tasks have documentation-coherence reports
• CHANGELOG includes security-related changes
• No secrets in documentation or code comments
• Security-specific docs updated (SECURITY.md, auth flows)
• API documentation matches implementation </documentation_audit>

See `resources/REFERENCE.md` for complete 150+ item checklists across 5 categories: - Security (50+ items) - Architecture (25+ items) - Code Quality (35+ items) - DevOps (25+ items) - Blockchain/Crypto (20+ items)

Red Flags (immediate CRITICAL):

• Private keys in code
• SQL via string concatenation
• User input to eval()
• Empty catch blocks on security code
• Hardcoded secrets

<beads_workflow>

Beads Workflow (beads_rust)

When beads_rust (br) is installed, use it to record security audit results:

Session Start

br sync --import-only  # Import latest state from JSONL

Recording Audit Results

# Add security audit comment to task/sprint epic
br comments add <task-id> "SECURITY AUDIT: [verdict] - [summary]"

# Mark security status
br label add <task-id> security                # Has security concerns
br label add <task-id> security-approved       # Passed audit

Using Labels for Security Status

Label	Meaning	When to Apply
security	Has security-sensitive code	During review
security-approved	Passed security audit	After "APPROVED - LET'S FUCKING GO"
security-blocked	Critical security issue	After "CHANGES_REQUIRED"

Logging Discovered Vulnerabilities

# Create security issue discovered during audit
.claude/scripts/beads/log-discovered-issue.sh "<sprint-epic-id>" "Security: [vulnerability description]" bug 0
br label add <new-issue-id> security

Session End

br sync --flush-only  # Export SQLite → JSONL before commit

Protocol Reference: See .claude/protocols/beads-integration.md </beads_workflow>

<retrospective_postlude> After main skill logic completes, if .loa.config.yaml invisible_retrospective.enabled: true (and not disabled for this skill under invisible_retrospective.skills), silently run the learning-signal scan per .claude/skills/continuous-learning/SKILL.md and its resources/RETROSPECTIVE.md (quality gates, sanitization, trajectory logging). Recursion guard: never when the active skill is continuous-learning itself. </retrospective_postlude>