이게 불편했어요

코딩 에이전트에게 「보안 점검해 줘」라고 하면 그럴듯한 목록이 돌아와요. 그런데 모범 사례가 빠졌다는 지적과 실제로 뚫리는 구멍이 한 목록에 섞여 있어서, 무엇부터 고쳐야 할지 하나씩 다시 따져 봐야 했어요. 찾은 에이전트가 그 결과를 스스로 확인하니 믿기도 어려웠고요.

그래서 이렇게 풀어요

이 스킬은 찾는 쪽과 확인하는 쪽을 나눠요. 여러 hunter가 커버리지 원장의 단위를 나눠 훑어 후보를 내면, 그 후보를 찾지 않은 새 에이전트가 반박을 시도하고 살아남은 것만 confirmed가 돼요. 소스에 없는 배포 설정처럼 확인할 수 없는 사실에 막힌 건 needs_validation으로 남기고 심각도를 붙이지 않아요. 결과는 스키마로 검증한 findings.json과 REPORT.md로, 감사 대상 저장소 밖 폴더에 쌓여요.

안에서는 이렇게 돌아가요

1. 1

   나 → 코딩 에이전트 (parent)

   security audit this codebase감사나 펜테스트를 분명히 요청하면 6단계 전체를, 보안 질문이면 필요한 부분만 써요.skills/security-audit/SKILL.md
2. 2

   코딩 에이전트 (parent) → hunter 에이전트들

   coverage-ledger.json의 단위 배정정찰 에이전트들이 구조와 신뢰 경계를 그리면, parent가 원장을 만들고 단위마다 hunter를 붙여요.skills/security-audit/RECONNAISSANCE.md
3. 3

   hunter 에이전트들 → 코딩 에이전트 (parent)

   구조화된 후보 결과hunter는 자기 scratch 폴더에만 쓰고 후보를 정해진 형식으로 돌려줘요. critic 웨이브가 빈 곳을 찾아요.skills/security-audit/HUNTING.md
4. 4

   코딩 에이전트 (parent) → verifier 에이전트

   후보 하나마다 새 verifier후보를 찾지 않은 에이전트가 반박을 시도해 confirmed, needs_validation, rejected로 갈라요.skills/security-audit/VALIDATION-AND-REPORTING.md
5. 5

   코딩 에이전트 (parent) → validate-findings.cjs

   findings.jsonreport-schema.json의 형식과 판정 규칙을 검사하고, 오류가 없을 때까지 고친 뒤에야 다음 단계로 가요.skills/security-audit/validate-findings.cjs
6. 6

   코딩 에이전트 (parent) → REPORT.md

   REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.md새 에이전트가 최종 기록을 다시 확인한 뒤, 검증된 기록과 원장에서만 보고서를 만들어요.skills/security-audit/VALIDATION-AND-REPORTING.md

나한테 맞을까요

What was hard

Ask a coding agent to check your code for security issues and you get a plausible list back. Missing best practices sit next to holes someone could actually walk through, so you end up re-checking every item to know what to fix first. And the agent that found them is the one vouching for them.

What it does about it

The skill splits finding from checking. Hunters each take units from a coverage ledger and report candidates; a fresh agent that did not find a candidate tries to disprove it, and only what survives is confirmed. When a fact outside the source blocks the answer, such as a deployment setting, the lead stays needs_validation with no severity. Everything lands as a schema-checked findings.json and a REPORT.md in a folder outside the audited repository.

How it runs inside

1. 1

   You → Coding agent (parent)

   security audit this codebaseAn explicit audit or pen-test request runs all six phases; a security question uses only the parts it needs.skills/security-audit/SKILL.md
2. 2

   Coding agent (parent) → Hunter agents

   Units from coverage-ledger.jsonRecon agents map structure and trust boundaries; the parent builds the ledger and gives each unit a hunter.skills/security-audit/RECONNAISSANCE.md
3. 3

   Hunter agents → Coding agent (parent)

   Structured candidate resultsHunters write only to their own scratch folder and return candidates in a fixed shape; critic waves look for gaps.skills/security-audit/HUNTING.md
4. 4

   Coding agent (parent) → Verifier agent

   A fresh verifier per candidateAn agent that did not find the candidate tries to disprove it: confirmed, needs_validation or rejected.skills/security-audit/VALIDATION-AND-REPORTING.md
5. 5

   Coding agent (parent) → validate-findings.cjs

   findings.jsonChecked against report-schema.json and the verdict rules; every error is fixed before the run moves on.skills/security-audit/validate-findings.cjs
6. 6

   Coding agent (parent) → REPORT.md

   REPORT.md, FINDINGS-DETAIL.md, NEEDS-VALIDATION.mdAfter fresh agents re-check the final records, reports are derived only from verified records and the ledger.skills/security-audit/VALIDATION-AND-REPORTING.md

Is it for you