메뉴
Audit what a normal production app at this scale would have but is absent — health checks, error tracking, feature flags, audit logs, on-call. Run as part of /audit Phase E.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when the user wants to add a new library, package, or dependency. Enforces the discipline that prevents framework version drift — the "AI assumes you're on version 15, generates code for 16.5" failure mode documented in the LLM failure-mode research.
Use when the user wants to add a new API endpoint, route, or handler. Enforces the "search before adding" discipline that prevents duplicate endpoints — the most common vibe-coding failure mode. Activate any time the request mentions adding a route, endpoint, handler, controller, or HTTP method.
Walk the B1-B15 AI-to-AI blind-spot catalog systematically. Use during the audit pipeline AFTER hard-stops and Tambon hunt and BEFORE the 13 domain audits. Output: PRESENT / NOT PRESENT for each B-class with evidence. Findings flow into the appropriate domains.
Audit the security domain — auth, authz, secrets, transport, sensitive data exposure, dependency CVEs. Run as part of /audit Phase E.
Audit the architecture and code quality domain — module boundaries, abstraction layers, code organization, naming, documentation. Run as part of /audit Phase E.
Audit the database and data layer — schema design, query patterns, migrations, indexing, RLS, soft-delete, transactions. Run as part of /audit Phase E.
| name | audit-domain-12-missing |
| description | Audit what a normal production app at this scale would have but is absent — health checks, error tracking, feature flags, audit logs, on-call. Run as part of /audit Phase E. |
This skill audits one specific domain. It runs in an isolated subagent context spawned by the audit-orchestrator. The subagent loads this skill and the audit rules, runs against the audit scope, and returns a ~2K-token findings report.
view @.claude/context/audit-rules.md
If you have findings from previous audit phases (hard stops, Tambon, blind spots), the orchestrator passes them as input. Use them — don't re-discover findings other phases already produced. Specifically:
If the orchestrator didn't pass you these inputs, do NOT re-run the hard-stops or blind-spots walks. Audit your domain only and trust the orchestrator to stitch.
What's absent that should be present at this stage: health checks, error tracking (Sentry/etc.), feature flags, audit logs, on-call rotation, runbooks, incident response process.
For each, find the evidence and report it. The questions are the audit's spine — every finding maps back to one of them.
Don't read everything. Read these files first:
If you exhaust these and the budget allows, expand outward. Otherwise, report what you found and note what you didn't read.
Re-read the rules. R1-R7 apply to every finding. Especially R2 (quote before cite) — for a domain skill running in a subagent, the subagent's context is fresh; don't assume you remember a file from a previous turn.
Walk the key questions. For each question, run the relevant detection commands (greps, file reads, schema lookups). Capture evidence at path:line. Verify by reading the actual code.
Cross-reference orchestrator inputs. If the orchestrator passed hard-stops or blind-spots findings tagged for this domain, include them in your report. Don't re-investigate; just include with the provided evidence.
Triage. For each finding, set severity per the audit rubric and exploitability per R4.
Produce the domain report.
═══════════════════════════════════════════════════════════════════════
DOMAIN 12: What's Missing But Expected
═══════════════════════════════════════════════════════════════════════
▶ FOUNDER VIEW
[2-4 sentences in plain English. Sample tone:]
What would an experienced engineer expect to see in a production app, that this app doesn't have? Absence is itself a signal.
▶ TECHNICAL EVIDENCE
Scope of this domain audit:
Files read: <count>
Files skipped: <count> (reason: outside scope or low-priority)
Findings:
F-12.1 — <one-line title>
Severity: Critical | High | Medium | Low
Exploitability: EXPLOITABLE-NOW | EXPLOITABLE-LOW-EFFORT | BAD-PRACTICE | UNKNOWN
Hard-stop: H<N> if applicable
Blind-spot: B<N> if applicable
Evidence:
<path:line> <one-line description>
What's wrong:
<one paragraph>
Why it matters:
<one sentence>
Recommended fix:
<one paragraph; for full fix prompt, use /audit-fix F-12.1>
Verification after fix:
<command>
F-12.2 ...
Summary:
Total findings: <count>
By severity: <counts>
Most urgent: <which finding ID>
[SECTION COMPLETE: Domain 12]
If the domain has zero findings:
▶ TECHNICAL EVIDENCE
✅ No findings in this domain.
Verification:
<commands run that produced no signal>
Confidence: High | Medium | Low
Reason for low confidence: <if applicable>