一键导入
edc-audit
Identifies code quality, maintainability, overengineering, bloat, duplication, and test-value risks by comparing EDC context expectations to actual code
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Identifies code quality, maintainability, overengineering, bloat, duplication, and test-value risks by comparing EDC context expectations to actual code
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Enables ultra-granular, line-by-line code analysis to build deep architectural context for any codebase.
Reviews whether code changes deliver the stated goal/spec and fit the repository architecture. Use this for PRs, branches, task implementations, plans, or diffs when the question is whether the implementation built the right thing in the right place: requirement coverage, scope creep, module ownership, source-of-truth choices, contracts, migrations, docs, and rollout.
Performs security/adversarial differential review of code changes (PRs, commits, diffs). Use this for auth, validation, trust-boundary, injection, crypto, memory-safety, external-call, state-mutation, or security-regression risk. It leverages git history and edc-context for blast radius and writes markdown security reports.
Builds or updates deep architectural context for any codebase (v2 layout)
Incrementally updates edc-context/ files based on branch changes (v2 layout)
Constrained doc-only edit pass for generated EDC context after report-only curation.
| name | edc-audit |
| description | Identifies code quality, maintainability, overengineering, bloat, duplication, and test-value risks by comparing EDC context expectations to actual code |
Analyze code quality and maintainability using the edc-context/ files as the baseline for what the code SHOULD look like. This is a read-only scoped analysis pass: audit workers must not mutate source code, branch state, generated context, or canonical reports outside their assigned report artifact.
Clean Slate Rule: When spawning subagents for analysis, they MUST be fresh agents with NO access to the current conversation context. This prevents bias from user discussion influencing findings. See edc-build-impl for rationale.
Read these bundled references before producing findings:
references/scope-and-standards.md — scope discipline, standards sources, evidence rules, and tooling-skip policyreferences/smell-baseline.md — Fowler smell baseline; use as heuristics and label baseline-only findings as possible smellreferences/quality-checks.md — concrete code-quality checks for maintainability, correctness smells, error handling, tests, type/contracts, and simplicityreferences/reporting.md — canonical report targets and finding formatThe runtime embeds these files below this SKILL.md for orchestrated audit runs. If invoking the skill manually and the references are not embedded, read them from this skill directory before continuing.
This skill usually runs inside an audit subprocess spawned by plugins/edc/scripts/edc-audit.sh or a build-time audit orchestration step. The orchestrator is responsible for context freshness and for assigning scope.
When invoked for the current whole-repo audit command, assume edc-context/modules/ and edc-context/manifest.json exist and reflect HEAD. During build-time module audit, a task may provide module files directly before the final manifest exists; in that case, use the task-provided module doc and file list rather than requiring manifest.json.
If required scope inputs are missing, fail loudly. Do not repair the context layout from inside the skill.
references/scope-and-standards.md. Identify documented standards sources for the assigned scope and record any rules that materially affect findings.references/smell-baseline.md. Repo standards override baseline smells; baseline-only findings are judgement calls.references/quality-checks.md. Verify every candidate in context before reporting it.references/reporting.md. Scoped workers write only their assigned artifact; synthesis/whole-repo runs write edc-context/reports/{complexity,issues}.md.This audit targets code quality only: maintainability, correctness smells, error handling, interface clarity, type/contracts, test value, duplication, bloat, and simplicity.
Do not turn this into a delivery/spec review. Do not judge whether the change implements the user's goal unless the issue is visible as code-quality evidence inside the assigned scope.
Do not turn this into an exploit-focused review. If a finding is primarily about adversarial misuse, leave it for the dedicated adversarial review workflow.
Reports should make quality tradeoffs actionable without prescribing a full refactor. Prefer small, boring recommendations tied to a specific file/line and explain why the issue matters for future changes or correctness.