rad-security/goal-blueprints

This repo is a library of reusable prompt templates for security engineers who are working with AI coding assistants. The templates are written for the /goal feature in tools like Claude Code and the experimental /goal in Codex CLI. The /goal feature lets you set a longer-lived objective with a built-in checking loop, so the agent keeps working across many turns until a stated condition is met instead of treating each prompt as a one-off. The argument behind the project is that security work is rarely one action. It is a loop of mapping the attack surface, testing assumptions, looking at code, APIs, data, logs, and product behavior, verifying the evidence, writing up the risk and remediation, and repeating until the original question is actually answered. A blueprint here turns that loop into a written contract so the same template can be reused across projects. The catalog is organized by category. Product Trust includes a product-wide security audit and a launch-readiness review. Access Boundaries covers authorization plus tenant isolation, and a hardening review of login, sessions, cookies, MFA, OAuth, OIDC, and CSRF. AI Security has an evaluation template for prompt injection, tool abuse, and retrieval leakage in AI features. Software Supply Chain covers secrets and dependency risk plus repository and CI integrity. There are also blueprints for cloud and IaC exposure, incident replay and detection validation, and privacy, logging, and telemetry tracing. Each blueprint follows the same structure: GOAL with a verifiable end state, CONTEXT for the repo and threat model, CONSTRAINTS such as sandbox-only and no production data, PRIORITY trade-offs, an expected PLAN, DONE WHEN criteria, a VERIFY section listing the proof commands or artifacts, an OUTPUT description, and STOP RULES that tell the agent to halt rather than improvise. A template file and a docs page on writing goals are included. The README is clear about limits and safety. /goal is not a sandbox, so permissions, credentials, network access, and isolation are still the operator's responsibility. The goal needs an observable stop condition, evidence must be visible inside the session for the agent to judge it, and synthetic data and isolated accounts are the default. Stop rules should fire if production risk, credential ambiguity, or any destructive action appears. The repo notes that no license has been picked yet, and that the prompts are intended for authorized work on systems you own or have permission to test.