Run the Trabuco security audit

This skill is the entry point for a structured security review of a Trabuco-generated project. The actual reasoning is delegated to the `trabuco-security-audit-orchestrator` subagent, which dispatches five domain specialists in parallel and merges their findings.

When to invoke

• User says "run the security audit" / "audit this project" / "check for OWASP

Top 10 issues" / "security review before merge" / similar.

• Pre-release or pre-merge hardening sweep on a project generated by trabuco init.
• After a significant refactor of auth, AI tools, persistence, or messaging

configuration — anywhere the threat surface may have shifted.

When NOT to invoke

• Pre-existing finding triage (you already have a findings.md and want to

fix one specific item) — just open that file directly.

• Non-Trabuco project — the checklist's evidence patterns assume Trabuco's

module shape (API, AIAgent, EventConsumer, Worker, etc.). Generic OWASP audits on arbitrary Spring Boot projects will misfire.

• Turn-scoped review during interactive coding — that's the

code-reviewer subagent's job (the audit is heavier and slower).

Flow

1. Hand off to the orchestrator subagent. Invoke

trabuco-security-audit-orchestrator with the user's scope/domain arguments. The orchestrator:

• Loads the canonical checklist from ${SKILL_DIR}/checklist*.md (when

run from the plugin) or from .ai/security-audit/checklist*.md (when run inside a generated project).

• Loads .ai/security-audit/checklist-local.md if present (operator's

local rule extensions; never overwritten by trabuco sync).

• Dispatches the five domain specialists in parallel via the Task tool:

trabuco-security-audit-auth, trabuco-security-audit-ai-surface, trabuco-security-audit-aiagent-java, trabuco-security-audit-data-events, trabuco-security-audit-web-infra.

• Each specialist returns a structured finding list (check ID, severity,

file path, evidence snippet, suggested fix).

• Orchestrator merges, deduplicates, severity-sorts, writes

.ai/security-audit/findings.md.

1. Do NOT do the work yourself. This skill is a router. The orchestrator

owns the audit; you only invoke it and surface its summary.

Output

The orchestrator writes .ai/security-audit/findings.md (gitignored by default — it's a local artifact, not durable evidence). Findings are sorted Critical → High → Medium → Low → Informational. Each finding records:

• Check ID (stable; matches the checklist taxonomy)
• Severity
• File and line range where the issue was found
• Evidence snippet
• Suggested fix
• OWASP / ASVS / CWE cross-references

The skill returns to the user the count by severity plus a one-line verdict ("PASS — no Critical or High findings" / "FAIL — 3 Critical, 7 High").

Scope arguments

• --scope=changed (default in PR context): walks only files changed since

the merge base. Faster; appropriate for CI gates.

• --scope=all: full repository walk. Use for periodic deep audits.
• --domain=<name>: limit to a single domain specialist. Use for targeted

verification after fixing a specific class of issue (e.g., --domain=auth after rotating JWT validation logic).

• --domain=all (default): all five specialists run.

Operator extensions

To add project-specific rules without forking the checklist, create .ai/security-audit/checklist-local.md in the project root. The orchestrator reads it alongside the canonical files. Schema is identical to the bundled checklist files. trabuco sync never overwrites this file.

Rules for the orchestrator subagent

• No false-positive amplification. If a specialist reports a finding,

the orchestrator may downgrade severity but must NOT fabricate findings that no specialist raised. Each finding must trace back to a specialist's report.

• Evidence required. Every finding must include a file path, line

range, and evidence snippet. Findings that cite "general code-quality concerns" without grounding evidence are dropped.

• Severity floor by check ID. Each check ID has a default severity in

the checklist; the orchestrator may NOT downgrade below that floor without an explicit [suppress: <reason>] justification, which it surfaces in the report.

• Deterministic ordering. Findings are emitted in

(severity, domain, check-ID, file-path) order so re-runs produce stable diffs.

• Local extensions equal canonical. Rules from checklist-local.md

carry the same weight as canonical rules; the orchestrator does not prefer one source over the other.

Reference

• Canonical checklist: ${SKILL_DIR}/checklist.md (this directory)
• Domain detail: ${SKILL_DIR}/checklist-{auth,ai-surface,aiagent-java,data-events,web-infra}.md
• Findings output: .ai/security-audit/findings.md in the target project