1. Look for .claude/svk-meta.json in the current project. If it doesn't exist, skip this check entirely.
2. Read the svk_repo path and installed_version from the metadata file.
3. Run: git -C <svk_repo> fetch --tags --quiet 2>/dev/null
4. Run: git -C <svk_repo> tag --sort=-v:refname | head -1 to get the latest tag.
5. Compare the installed version against the latest tag (strip the leading v).
6. If they match, skip — the user is up to date.
7. If the latest tag is newer, show this message ONCE (never repeat in this session):

SVK Update Available: v{latest} is available (you're on v{installed}).

• Update now: I can pull and reinstall the changed skills in this session
• Update later: Start a new chat and run /SVK:update

8. If the git commands fail (offline, repo moved, etc.), skip silently. Never show errors from version checking.

Important: Do NOT block or delay the user's actual command. Perform this check, show the notification if needed, then proceed with the command they invoked. </svk-version-check>

Dinh's Bulwark

A comprehensive, multi-agent adversarial security audit for off-chain Solana code.

"The shield that guards everything beyond the chain."

Getting Started

Dinh's Bulwark runs as a multi-phase pipeline. Each phase is a separate command with its own fresh context window, ensuring maximum quality throughout the entire audit.

Quick Start

/DB:scan          # Detect project components, run static tools, build index
/DB:analyze       # Deploy selected auditor agents (dynamic count)
/DB:strategize    # Synthesize into architecture doc + attack hypotheses
/DB:investigate   # Priority-ordered hypothesis investigation
/DB:report        # Final synthesis — findings, attack trees, remediation
/DB:verify        # Post-fix verification
/DB:status        # Check progress at any time

Full Pipeline

scan (0+0.5) → analyze (1+1.5) → strategize (2+3) → investigate (4+4.5) → report (5) → verify (post)

Each phase reads the output of the previous phase from .bulwark/ and writes its own artifacts there. Run /clear between phases for a fresh context window.

Scope

In scope: All off-chain code with financial or operational impact — backends, APIs, trading bots, keepers/cranks, frontends, wallet integrations, transaction construction logic, infrastructure configuration, indexers, webhook handlers, RPC clients.

Out of scope: Anchor/Rust on-chain programs (that's SOS's domain). Pure code quality issues (naming, style, dead code, non-impactful performance).

Hard boundary with SOS: DB explicitly skips Anchor programs and on-chain Rust code. If it detects a programs/ directory with Anchor code, it notes "run SOS for on-chain audit" and moves on.

Auditor Agents — Dynamic Catalog

Unlike SOS (which has 10 fixed on-chain auditors), DB uses a dynamic selection system. Off-chain codebases vary enormously — a trading bot, a full-stack dApp, and a keeper service need very different security lenses.

51 auditor definitions across 14 categories:

How Selection Works

1. /DB:scan detects technologies, frameworks, and patterns in the codebase
2. Each auditor has trigger patterns — the scan matches them against the codebase
3. Matched auditors are auto-selected; user can add/remove before deployment
4. Tier budget sets the range: quick (8-10), standard (12-20), deep (15+, can be 30+)

See resources/auditor-catalog.md for the full catalog with triggers and focus guidance.

Each auditor also receives the AI-generated code pitfalls checklist for its domain.

Cross-Skill Awareness

DB participates in the SVK skill ecosystem:

• Reads SOS findings — SOS findings inform off-chain risk assessment ("the program trusts this input — does the backend validate it?")
• Reads GL documentation — GL docs serve as the spec oracle for intended behavior ("the spec says withdrawals require 2FA — does the API enforce it?")
• Detection: During scan, DB checks for .audit/ and .docs/ directories. If found, it reads the architecture doc and findings summary for cross-boundary analysis.

Model Selection

State

State lives in .bulwark/STATE.json (SVK convention: "skill": "dinhs-bulwark"). History archives in .bulwark-history/.

Knowledge Base

• 160+ exploit patterns (OC-001 through OC-160) across off-chain categories
• AI-generated code pitfalls — common LLM mistakes per auditor domain
• Core reference — false positives, secure patterns, severity calibration
• 51 auditor definitions — full catalog with detection triggers