Feature Archetype Driven Prompts
This is the heart of Argo's design: Stage 2 turns a handful of reusable prompt assets into a set of
audit prompts tailored to one specific target. Three things converge — the reusable assets
(always the same), scope.json (your links and rules), and the repo recon (stack, endpoints, CVE
history from Threat-Informed Audit) — and out come the
complementary custom prompts for that single scan.
Default model: Opus — this is the single highest-leverage stage in the pipeline. Validation can only remove false positives; it can never recover a bug a weak recon never pointed the auditor at.
The meta-prompt's first step classifies the target: web app · HTTP/GraphQL API · CMS · plugin/extension/mod · library/SDK/framework · CLI/desktop · agent/LLM/MCP · mobile · data/ML pipeline · smart-contract · firmware · IaC. Everything downstream inherits from this:
- Entry-point reconstruction in the archetype's own terms — HTTP routes for a web app, command handlers and inter-instance protocols for a plugin, public functions and insecure defaults for a library, tool definitions and prompt assembly for an agent.
- Untrusted-input and sink mapping — the general checklist (injection, SSRF, path traversal, deserialization, sensitive-data exposure) plus archetype-specific sources/sinks.
- The prompt split — instead of a fixed web-app partition, the model picks a reference split per archetype (typically 3 complementary prompts, always including one architecture-led whole-system prompt) and adapts it to the real code.
Recon does the enumeration work up front and bakes it into both the prompt prose and
ground_truth.json:
-
Invariants —
location → expected → how-to-checktriples, turning the audit from open-ended hunting into a PASS/FAIL checklist. - Baseline-correct references — the one place a systemic pattern is done right; every sibling is diffed against it.
- Variant families — repeated shapes (controller-per-operation, converter-per-type…) with a concrete enumerated member list, so the audit verifies each member, not just the first.
- False-positive carve-outs — target-specific "do not flag" rules, also handed to the validator so it doesn't re-derive them and wrongly refute a real finding.
The audit template mandates a VARIANT_HUNT_LOG (one row per family member, 🟢/🟡/🔴) as a coverage
forcing-function, and a completeness-critic re-pass loops until a pass adds nothing new.
Two deterministic, code-side mechanisms close the gap an open-ended instruction leaves: a
coverage checklist injected into every prompt (variant-family census, resource-exhaustion,
secrets-in-sinks, SSRF, memory-safety or panic-census depending on the language, crypto-primitive
review, insecure-defaults/fail-open, one-finding-per-root-cause), and a variant census worksheet
that pre-scans the repo for cheaply-detectable defect families (native free/copy/alloc sinks,
panic/abort points) and bakes the exact site count + file list into the prompt — turning "enumerate
every sibling" from an instruction a model under-executes into a closed-ended checklist it must
account for.
- Every generated prompt must name the archetype and warn against treating a non-web target as a generic web/CRUD app.
- A specificity self-check runs before the prompts are emitted: could this be pasted onto another project of the same archetype unchanged? Does it use the project's own terms?
- The orchestrator independently re-verifies every generated prompt before driving an audit session — it must carry the RoE sections, prohibited techniques verbatim, and "Do NOT patch". A prompt that loses these fails the run; the model's freedom to tailor content never drops a safety constraint. See Guardrails & Safety.
-
Adversarial Validation — consumes the same
ground_truth.jsonto avoid re-deriving carve-outs. - Design-Aware Impact Discipline — the severity-symmetry and anti-over-claim rules injected alongside the coverage checklist.