القائمة
Audit the architecture and code quality domain — module boundaries, abstraction layers, code organization, naming, documentation. 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 database and data layer — schema design, query patterns, migrations, indexing, RLS, soft-delete, transactions. Run as part of /audit Phase E.
Audit the infra and DevOps domain — CI/CD, deployment, IaC, secrets management, environments, logging, observability. Run as part of /audit Phase E.
| name | audit-domain-02-architecture |
| description | Audit the architecture and code quality domain — module boundaries, abstraction layers, code organization, naming, documentation. 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.
Module boundaries, layering, separation of concerns, dependency direction, abstraction quality, naming consistency, documentation, technical debt indicators.
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 2: Architecture & Code Quality
═══════════════════════════════════════════════════════════════════════
▶ FOUNDER VIEW
[2-4 sentences in plain English. Sample tone:]
How well-organized is the code? Will a new engineer understand it in a week, or never?
▶ TECHNICAL EVIDENCE
Scope of this domain audit:
Files read: <count>
Files skipped: <count> (reason: outside scope or low-priority)
Findings:
F-2.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-2.1>
Verification after fix:
<command>
F-2.2 ...
Summary:
Total findings: <count>
By severity: <counts>
Most urgent: <which finding ID>
[SECTION COMPLETE: Domain 2]
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>