Sweep the codebase with the same criteria an external security team would use, and fix\nfindings ahead of time.
\nRun concurrently:
\nAgent(subagent_type: \"security-audit\") — grep-based scan of the 12 P0 code items\n (hardcoded secrets, missing auth, PII logging, ...) + 8 agent-config items\n (.claude/ hooks, MCP, permissions, prompt injection)\n# SonarQube security hotspots (TO_REVIEW only) — skip this step with a note if the\n# project has no sonar-project.properties. Never hardcode the host or token:\n# use $SONAR_HOST_URL / $SONAR_TOKEN from the environment.\nif [ -f sonar-project.properties ]; then\n key=$(grep 'sonar.projectKey' sonar-project.properties | cut -d= -f2-)\n curl -s -u \"${SONAR_TOKEN}:\" \\\n \"${SONAR_HOST_URL}/api/hotspots/search?projectKey=$key&status=TO_REVIEW&ps=500\" \\\n | python3 -c \"import sys,json; d=json.load(sys.stdin); print('TO_REVIEW:', len(d['hotspots'])); [print(h['ruleKey'], h['component'], h.get('line','')) for h in d['hotspots']]\"\nfi\nThe security-audit agent produces better results when its prompt names this project's\nconcrete context (auth mechanism, session handling, CORS config, data-access layer,\nPII fields). Don't describe these from memory — at run time, grep the repo for its\nauth/session/CORS/data-access entry points and include what you actually find.
\n.env leaked into git, etc.Report as a table: P0 N / P1 N / pass N.
Group findings by file/topic into one issue each — no issue-per-finding spam.\nExample: three findings in the same auth controller (rate limit, cookie attributes,\nconstant-time comparison) become one issue.
\n# forge CLI per rules/forge.md\ngh issue create -t \"<title>\" -b \"<pre-check background + concrete findings + files>\" # GitHub\nglab issue create -t \"<title>\" -d \"<pre-check background + concrete findings + files>\" -y # GitLab\nLocal-settings fixes (.claude/settings.local.json allow-list trimming, MCP permission\nreview, ...) are handled directly without an issue — local-scope config, not P1 workflow\nmaterial.
Split issues by nature and invoke Agent concurrently. Issues touching the same file\ngo to a single agent — splitting them causes concurrent-edit conflicts on that file.
| Work type | \nsubagent_type | \nmodel | \n
|---|---|---|
| Backend changes involving security judgment (auth/crypto/session) | \nsdlc-developer | \nopus | \n
| General implementation (logging/validation/config) | \nsdlc-developer | \nsonnet | \n
| Investigate-only review (keep if justified, fix if not) | \ngeneral-purpose | \nhaiku | \n
Every Agent call needs isolation: \"worktree\" (prevents parallel edit conflicts). Tell\neach agent to create a branch and commit only — no push, no merge; the parent session\ngates merges sequentially (multiple worktrees hitting main concurrently is a race).
As each agent completes:
\ngit pull && git merge <branch> --no-edit.claude/hooks/pre-commit.sh are the reference)git pushgit worktree remove <path> --force && git branch -d <branch>rules/forge.md)Write .claude/memory/project_security-precheck.md with the date, finding counts,\nissue numbers handled, and accepted risks (e.g. rate-limit keying may be inaccurate\nbehind a proxy; a specific MCP allow kept with rationale) — so the next pre-check does\nnot re-litigate items already reviewed and consciously kept.
request.getRemoteAddr()\nor equivalent) collapses to the proxy IP behind a reverse proxy, turning it into a\nglobal lock — verify whether the deployment topology requires X-Forwarded-For\nparsing during review.node_modules, venv, ...), so\nfrontend/build gates can fail environmentally — for backend-only changes a symlink\nworkaround is fine (never commit it); if the issue touches frontend code, tell the\nagent to run the package install (lockfile-frozen) in its worktree first.mcp__*) are granted per tool — \"read-only only\" granularity is not\npossible. If a tool is genuinely needed, don't force-remove it; record the rationale\nin memory and keep it.