[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71G04YDNFDSFFMAS0ZQ0QAQ":3,"skill-same:01M71G04YDNFDSFFMAS0ZQ0QAQ":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M71G04YDNFDSFFMAS0ZQ0QAQ","audit-python-code",null,"Python implementation-code audit methodology — judges the Python code files in scope for design flaws and architecture-decision compliance.","outcomeeng\u002Fplugins","outcomeeng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257335685?v=4","01M71FRVRF36XYR3HRSCGFHK2R","Outcome Engineering","01M71FRVS4BZG17DWANFJ7EPNY",1,"MIT","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Faudit-python-code\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"audit","python","audit python code","code","python code","audit methodology","code audit","use","architecture-decision","implementation","files","design","methodology","grep","decision","tool","read","for","compliance","scope","2026-11-10 10:12:30",false,"---\nname: audit-python-code\ndescription: >-\n  Python implementation-code audit methodology — judges the Python code files in\n  scope for design flaws and architecture-decision compliance.\nallowed-tools: Read, Grep, Glob, {{! tool('use_skill') !}}\n---\n\n{!% require_skill 'python:python-code-standards' %!}\n\n\u003Cobjective>\n\nA verdict on Python implementation code — `APPROVED`, or `REJECTED` with each finding naming the design flaw, the violated rule, and the evidence.\n\n\u003C\u002Fobjective>\n\n\u003Cconstraints>\n\n- NEVER modify files, generate fixes, write replacement code, commit changes, or change project state — this audit produces a verdict only.\n- NEVER run deterministic validation, lint, type-check, test, or eval commands — this audit reads and judges; it never runs deterministic verification.\n- NEVER evaluate test evidence quality — `\u002Faudit-python-test` is the separate concern that judges it.\n- ALWAYS keep findings to artifact, violated rule, evidence, and why the cited code violates the rule.\n- NEVER include corrective code samples, implementation patches, prescribed refactors, or required-change summaries in the verdict.\n- `APPROVED` means every concern row passes or is explicitly not applicable. `REJECTED` means at least one concern row fails. `APPROVED` output contains no notes, warnings, or suggestions sections.\n\n\u003C\u002Fconstraints>\n\n\u003Crepo_local_overlay>\nStandards are pre-loaded above. Check for `spx\u002Flocal\u002Fpython.md` at the repository root. Read it if it exists and apply it as repo-local routing to the product's governing specs and decisions. A local overlay supplements skill behavior; it does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Cessential_principles>\n\n**Comprehension is the whole job.**\n\nThis audit reads and judges Python implementation code; it runs no deterministic verification. Do NOT run or re-check the project's linters, type-checker, or tests. Spend the whole audit on comprehension.\n\n**Comprehension is the core value.**\n\nAutomated tools catch syntax errors, type mismatches, and lint violations. Claude catches: functions that do more than their name says, dead parameters required by no Protocol, IO tangled with logic, and designs that will break under change. The predict\u002Fverify protocol (Phase 1) is how these surface.\n\n**Test evidence is out of scope.**\n\n`\u002Faudit-python-test` evaluates whether tests provide behavior-coupled evidence using the 4-property model (coupling, falsifiability, alignment, coverage). This skill judges implementation design, not test evidence, and never runs the test suite. Do not duplicate that work.\n\n**Binary verdict, no caveats.**\n\nThe verdict is the only output. Findings prove violations; they do not prescribe fixes.\n\n\u003C\u002Fessential_principles>\n\n\u003Caudit_workflow>\n\nExecute phases IN ORDER. Do not skip. This audit runs no deterministic verification — no linter, type-checker, or test run.\n\n**Phase 0: Scope and Product Config**\n\n1. Determine target files\u002Fdirectories\n2. Check `pyproject.toml` and `{{! file('root_guide') !}}`\u002F`README.md` for tool and project configuration that informs comprehension (ruff, mypy, pytest settings; naming conventions) — read for context, never to run a gate. The linters already handled type annotations, magic numbers, bare excepts, unused imports, commented-out code, modern syntax, and security rules; comprehension covers what they cannot — deep relative imports, `sys.path` manipulation, unqualified `Any`, and `# type: ignore` without justification.\n\n**Phase 1: Code Comprehension**\n\nRead every file. Understand it. Question it. Do NOT skim, sample, or check boxes.\n\n**1.1 Per-Function Protocol**\n\nFor each function\u002Fmethod:\n\n1. **Read name and signature only** -- name, parameters, return type\n2. **Predict** what it does in one sentence\n3. **Read the body** -- validate the prediction\n4. **Investigate surprises:**\n\n| Surprise                               | What it suggests                                  |\n| -------------------------------------- | ------------------------------------------------- |\n| Parameter never used in body           | Dead parameter -- required by Protocol, or remove |\n| Does more than name says               | SRP violation or misleading name                  |\n| Does less than name says               | Name overpromises or logic is incomplete          |\n| Variable assigned but never read       | Dead code or unfinished logic                     |\n| Code path that can never execute       | Dead branch given calling context                 |\n| Return value contradicts the type hint | Logic error or wrong return type                  |\n\nPrediction matched? Move on. Surprise? Document it with `file:line`.\n\n**1.2 Design Evaluation**\n\nFor the codebase as a whole:\n\n- **IO vs logic separation** -- Can core logic be tested without IO? Tangled computation and side effects need factoring.\n- **Dependency injection** -- External dependencies injected via parameters or Protocol, or imported as globals?\n- **Single responsibility** -- Each module\u002Fclass does one thing? Each function does one thing?\n- **Error quality** -- Errors include what failed and with what input?\n- **Domain exceptions** -- Custom exceptions for domain errors, or everything generic `ValueError`\u002F`RuntimeError`?\n\n**1.3 Import Evaluation**\n\nEvaluate import structure using the same vocabulary as `\u002Faudit-python-test`:\n\n| Import pattern                                            | Classification                  |\n| --------------------------------------------------------- | ------------------------------- |\n| `import pytest`                                           | Framework -- not reviewed       |\n| `from hypothesis import given`                            | Framework -- not reviewed       |\n| `import json`                                             | Stdlib -- not reviewed          |\n| `from typing import TYPE_CHECKING`                        | Type-only -- erased at runtime  |\n| `from product.config import parse_config`                 | Codebase (production) -- review |\n| `from ..config import parse_config`                       | Codebase (relative) -- review   |\n| `from product_testing.harnesses import ConfigTestHarness` | Codebase (test infra) -- review |\n\n**Import depth rules:**\n\n| Depth           | Example                   | Verdict                          |\n| --------------- | ------------------------- | -------------------------------- |\n| Package import  | `from product.config ...` | OK -- preferred                  |\n| 1 level         | `from ..config ...`       | Review -- truly module-internal? |\n| 2+ levels       | `from ....helpers ...`    | REJECT -- use package import     |\n| sys.path manip. | `sys.path.insert(0, ...)` | REJECT -- always                 |\n\nFor stable locations (`product_testing.harnesses.*`, `product_testing.generators.*`, and inert fixture path providers), package imports are mandatory.\n\nSee `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ffalse-positive-handling.md` for application context when evaluating security and linter suppression comments.\n\n**Phase 2: ADR\u002FPDR Compliance**\n\nFind applicable ADRs\u002FPDRs in the spec hierarchy (`*.adr.md`, `*.pdr.md`). Verify each constraint is followed. Undocumented deviations make this concern `FAIL`. If the product has no spec hierarchy, this concern is `NOT_APPLICABLE`.\n\n| Decision Record Constraint           | Violation Example                   | Verdict |\n| ------------------------------------ | ----------------------------------- | ------- |\n| \"Use dependency injection\" (ADR)     | Direct imports of external services | FAIL    |\n| \"`l1` tests for logic\" (ADR)         | `l1` tests hitting network          | FAIL    |\n| \"No ORM\" (ADR)                       | SQLAlchemy models introduced        | FAIL    |\n| \"Lifecycle is Draft→Published\" (PDR) | Added hidden `Archived` state       | FAIL    |\n\n\u003C\u002Faudit_workflow>\n\n\u003Cfailure_modes>\n\nThese are real failures from past audits. Study them to avoid repeating them.\n\n**Approved code that passed ruff+mypy but had a design flaw.** Claude trusted the green linters and skimmed comprehension. The code had a function named `validate_config` that also wrote the config file -- SRP violation hidden behind a reasonable name. The predict\u002Fverify protocol would have caught it: \"Given the name, I predict this validates. But the body also calls `Path.write_text()`. Surprise.\"\n\n**Rejected code for a false positive.** Claude flagged a parameter as \"dead code\" because it wasn't used in the function body. The parameter was required by a `CommandHandler` Protocol contract -- other implementations used it. Before flagging dead parameters, check if the function implements a Protocol.\n\n**Tried to evaluate test evidence instead of delegating.** Claude found `lambda cmd: (0, \"\", \"\")` in tests and spent time analyzing whether it severed coupling. That's `\u002Faudit-python-test`' job, and this audit never runs the test suite. Claude should have moved straight to comprehending the implementation code.\n\n**Distracted by style while missing a logic bug.** Claude spent review time on naming conventions, import ordering, and docstring completeness. Meanwhile, a branch condition was inverted -- `if is_valid` should have been `if not is_valid`. Comprehension (understanding what the code does) must come before style. Style is the linter's job.\n\n**Accepted code with tangled IO.** A `process_orders` function both computed order totals AND sent confirmation emails. Tests passed and types were correct. But the function was untestable without an email server -- IO and logic were tangled. The design evaluation (1.2) would have caught it: \"Can core logic be tested without IO? No.\"\n\n\u003C\u002Ffailure_modes>\n\n\u003Cverdict_format>\n\nEmit a structured verdict. The skill's entire output is the verdict payload.\n\nThe skill's `overall` is `APPROVED` iff every concern row is `PASS` or `NOT_APPLICABLE`; it is `REJECTED` if any concern is `FAIL`. An unavailable required inspection is `FAIL`, never `NOT_APPLICABLE`. Findings use severity `blocking` or `debt`.\n\n```json\n{\n  \"schema_version\": 1,\n  \"skill\": \"audit-python-code\",\n  \"target\": \"\u003Cscope-target>\",\n  \"overall\": \"APPROVED | REJECTED\",\n  \"rows\": [\n    { \"name\": \"function-comprehension\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"design-coherence\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"import-structure\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"adr-pdr-compliance\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] }\n  ],\n  \"metadata\": { \"branch\": \"\u003Cbranch>\" }\n}\n```\n\nEach finding carries `file`, `line`, `rule` (the concern name from the verdict table or a specific violation name), `severity: \"blocking | debt\"`, `message`, `observed`, and `expected`. The message names the violated rule and consequence only; it contains no corrective code sample, implementation patch, prescribed refactor, or required-change summary.\n\n\u003C\u002Fverdict_format>\n\n\u003Cwhat_to_avoid>\n\n- Do NOT run or re-check the project's linters, type-checker, or tests — this audit runs no deterministic verification\n- Do NOT evaluate test evidence quality; `\u002Faudit-python-test` is the separate concern that judges it\n- Do NOT commit or modify code (this skill is read-only)\n- Do NOT generate fixes, replacement code, refactors, or required-change summaries\n- Do NOT approve with caveats (binary verdict only)\n- Do NOT reject for code style when comprehension found no design flaws\n\n\u003C\u002Fwhat_to_avoid>\n\n\u003Cexample_review>\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fexample-audit.md` for complete PASS and FAIL examples.\n\n\u003C\u002Fexample_review>\n\n\u003Csuccess_criteria>\n\nA sound verdict has these properties:\n\n- [ ] The verdict states exactly one overall determination: `APPROVED` or `REJECTED`\n- [ ] Every applicable Python concern in the verdict table was judged, with no skipped concern hidden by an approval\n- [ ] Each `FAIL` finding names the file, line, violated concern or rule, and concrete evidence\n- [ ] Each `NOT_APPLICABLE` row explains why the concern does not apply; a missing or blocked required inspection produces `FAIL`\n- [ ] The same repository state and audit scope can reproduce the verdict from the listed evidence\n\n\u003C\u002Fsuccess_criteria>\n","{!% require_skill 'python:python-code-standards' %!}\n\n\u003Cobjective>\n\nA verdict on Python implementation code — `APPROVED`, or `REJECTED` with each finding naming the design flaw, the violated rule, and the evidence.\n\n\u003C\u002Fobjective>\n\n\u003Cconstraints>\n\n- NEVER modify files, generate fixes, write replacement code, commit changes, or change project state — this audit produces a verdict only.\n- NEVER run deterministic validation, lint, type-check, test, or eval commands — this audit reads and judges; it never runs deterministic verification.\n- NEVER evaluate test evidence quality — `\u002Faudit-python-test` is the separate concern that judges it.\n- ALWAYS keep findings to artifact, violated rule, evidence, and why the cited code violates the rule.\n- NEVER include corrective code samples, implementation patches, prescribed refactors, or required-change summaries in the verdict.\n- `APPROVED` means every concern row passes or is explicitly not applicable. `REJECTED` means at least one concern row fails. `APPROVED` output contains no notes, warnings, or suggestions sections.\n\n\u003C\u002Fconstraints>\n\n\u003Crepo_local_overlay>\nStandards are pre-loaded above. Check for `spx\u002Flocal\u002Fpython.md` at the repository root. Read it if it exists and apply it as repo-local routing to the product's governing specs and decisions. A local overlay supplements skill behavior; it does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Cessential_principles>\n\n**Comprehension is the whole job.**\n\nThis audit reads and judges Python implementation code; it runs no deterministic verification. Do NOT run or re-check the project's linters, type-checker, or tests. Spend the whole audit on comprehension.\n\n**Comprehension is the core value.**\n\nAutomated tools catch syntax errors, type mismatches, and lint violations. Claude catches: functions that do more than their name says, dead parameters required by no Protocol, IO tangled with logic, and designs that will break under change. The predict\u002Fverify protocol (Phase 1) is how these surface.\n\n**Test evidence is out of scope.**\n\n`\u002Faudit-python-test` evaluates whether tests provide behavior-coupled evidence using the 4-property model (coupling, falsifiability, alignment, coverage). This skill judges implementation design, not test evidence, and never runs the test suite. Do not duplicate that work.\n\n**Binary verdict, no caveats.**\n\nThe verdict is the only output. Findings prove violations; they do not prescribe fixes.\n\n\u003C\u002Fessential_principles>\n\n\u003Caudit_workflow>\n\nExecute phases IN ORDER. Do not skip. This audit runs no deterministic verification — no linter, type-checker, or test run.\n\n**Phase 0: Scope and Product Config**\n\n1. Determine target files\u002Fdirectories\n2. Check `pyproject.toml` and `{{! file('root_guide') !}}`\u002F`README.md` for tool and project configuration that informs comprehension (ruff, mypy, pytest settings; naming conventions) — read for context, never to run a gate. The linters already handled type annotations, magic numbers, bare excepts, unused imports, commented-out code, modern syntax, and security rules; comprehension covers what they cannot — deep relative imports, `sys.path` manipulation, unqualified `Any`, and `# type: ignore` without justification.\n\n**Phase 1: Code Comprehension**\n\nRead every file. Understand it. Question it. Do NOT skim, sample, or check boxes.\n\n**1.1 Per-Function Protocol**\n\nFor each function\u002Fmethod:\n\n1. **Read name and signature only** -- name, parameters, return type\n2. **Predict** what it does in one sentence\n3. **Read the body** -- validate the prediction\n4. **Investigate surprises:**\n\n| Surprise                               | What it suggests                                  |\n| -------------------------------------- | ------------------------------------------------- |\n| Parameter never used in body           | Dead parameter -- required by Protocol, or remove |\n| Does more than name says               | SRP violation or misleading name                  |\n| Does less than name says               | Name overpromises or logic is incomplete          |\n| Variable assigned but never read       | Dead code or unfinished logic                     |\n| Code path that can never execute       | Dead branch given calling context                 |\n| Return value contradicts the type hint | Logic error or wrong return type                  |\n\nPrediction matched? Move on. Surprise? Document it with `file:line`.\n\n**1.2 Design Evaluation**\n\nFor the codebase as a whole:\n\n- **IO vs logic separation** -- Can core logic be tested without IO? Tangled computation and side effects need factoring.\n- **Dependency injection** -- External dependencies injected via parameters or Protocol, or imported as globals?\n- **Single responsibility** -- Each module\u002Fclass does one thing? Each function does one thing?\n- **Error quality** -- Errors include what failed and with what input?\n- **Domain exceptions** -- Custom exceptions for domain errors, or everything generic `ValueError`\u002F`RuntimeError`?\n\n**1.3 Import Evaluation**\n\nEvaluate import structure using the same vocabulary as `\u002Faudit-python-test`:\n\n| Import pattern                                            | Classification                  |\n| --------------------------------------------------------- | ------------------------------- |\n| `import pytest`                                           | Framework -- not reviewed       |\n| `from hypothesis import given`                            | Framework -- not reviewed       |\n| `import json`                                             | Stdlib -- not reviewed          |\n| `from typing import TYPE_CHECKING`                        | Type-only -- erased at runtime  |\n| `from product.config import parse_config`                 | Codebase (production) -- review |\n| `from ..config import parse_config`                       | Codebase (relative) -- review   |\n| `from product_testing.harnesses import ConfigTestHarness` | Codebase (test infra) -- review |\n\n**Import depth rules:**\n\n| Depth           | Example                   | Verdict                          |\n| --------------- | ------------------------- | -------------------------------- |\n| Package import  | `from product.config ...` | OK -- preferred                  |\n| 1 level         | `from ..config ...`       | Review -- truly module-internal? |\n| 2+ levels       | `from ....helpers ...`    | REJECT -- use package import     |\n| sys.path manip. | `sys.path.insert(0, ...)` | REJECT -- always                 |\n\nFor stable locations (`product_testing.harnesses.*`, `product_testing.generators.*`, and inert fixture path providers), package imports are mandatory.\n\nSee `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ffalse-positive-handling.md` for application context when evaluating security and linter suppression comments.\n\n**Phase 2: ADR\u002FPDR Compliance**\n\nFind applicable ADRs\u002FPDRs in the spec hierarchy (`*.adr.md`, `*.pdr.md`). Verify each constraint is followed. Undocumented deviations make this concern `FAIL`. If the product has no spec hierarchy, this concern is `NOT_APPLICABLE`.\n\n| Decision Record Constraint           | Violation Example                   | Verdict |\n| ------------------------------------ | ----------------------------------- | ------- |\n| \"Use dependency injection\" (ADR)     | Direct imports of external services | FAIL    |\n| \"`l1` tests for logic\" (ADR)         | `l1` tests hitting network          | FAIL    |\n| \"No ORM\" (ADR)                       | SQLAlchemy models introduced        | FAIL    |\n| \"Lifecycle is Draft→Published\" (PDR) | Added hidden `Archived` state       | FAIL    |\n\n\u003C\u002Faudit_workflow>\n\n\u003Cfailure_modes>\n\nThese are real failures from past audits. Study them to avoid repeating them.\n\n**Approved code that passed ruff+mypy but had a design flaw.** Claude trusted the green linters and skimmed comprehension. The code had a function named `validate_config` that also wrote the config file -- SRP violation hidden behind a reasonable name. The predict\u002Fverify protocol would have caught it: \"Given the name, I predict this validates. But the body also calls `Path.write_text()`. Surprise.\"\n\n**Rejected code for a false positive.** Claude flagged a parameter as \"dead code\" because it wasn't used in the function body. The parameter was required by a `CommandHandler` Protocol contract -- other implementations used it. Before flagging dead parameters, check if the function implements a Protocol.\n\n**Tried to evaluate test evidence instead of delegating.** Claude found `lambda cmd: (0, \"\", \"\")` in tests and spent time analyzing whether it severed coupling. That's `\u002Faudit-python-test`' job, and this audit never runs the test suite. Claude should have moved straight to comprehending the implementation code.\n\n**Distracted by style while missing a logic bug.** Claude spent review time on naming conventions, import ordering, and docstring completeness. Meanwhile, a branch condition was inverted -- `if is_valid` should have been `if not is_valid`. Comprehension (understanding what the code does) must come before style. Style is the linter's job.\n\n**Accepted code with tangled IO.** A `process_orders` function both computed order totals AND sent confirmation emails. Tests passed and types were correct. But the function was untestable without an email server -- IO and logic were tangled. The design evaluation (1.2) would have caught it: \"Can core logic be tested without IO? No.\"\n\n\u003C\u002Ffailure_modes>\n\n\u003Cverdict_format>\n\nEmit a structured verdict. The skill's entire output is the verdict payload.\n\nThe skill's `overall` is `APPROVED` iff every concern row is `PASS` or `NOT_APPLICABLE`; it is `REJECTED` if any concern is `FAIL`. An unavailable required inspection is `FAIL`, never `NOT_APPLICABLE`. Findings use severity `blocking` or `debt`.\n\n```json\n{\n  \"schema_version\": 1,\n  \"skill\": \"audit-python-code\",\n  \"target\": \"\u003Cscope-target>\",\n  \"overall\": \"APPROVED | REJECTED\",\n  \"rows\": [\n    { \"name\": \"function-comprehension\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"design-coherence\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"import-structure\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] },\n    { \"name\": \"adr-pdr-compliance\", \"status\": \"PASS | FAIL | NOT_APPLICABLE\", \"explanation\": \"\u003Crequired when NOT_APPLICABLE>\", \"findings\": [] }\n  ],\n  \"metadata\": { \"branch\": \"\u003Cbranch>\" }\n}\n```\n\nEach finding carries `file`, `line`, `rule` (the concern name from the verdict table or a specific violation name), `severity: \"blocking | debt\"`, `message`, `observed`, and `expected`. The message names the violated rule and consequence only; it contains no corrective code sample, implementation patch, prescribed refactor, or required-change summary.\n\n\u003C\u002Fverdict_format>\n\n\u003Cwhat_to_avoid>\n\n- Do NOT run or re-check the project's linters, type-checker, or tests — this audit runs no deterministic verification\n- Do NOT evaluate test evidence quality; `\u002Faudit-python-test` is the separate concern that judges it\n- Do NOT commit or modify code (this skill is read-only)\n- Do NOT generate fixes, replacement code, refactors, or required-change summaries\n- Do NOT approve with caveats (binary verdict only)\n- Do NOT reject for code style when comprehension found no design flaws\n\n\u003C\u002Fwhat_to_avoid>\n\n\u003Cexample_review>\nRead `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fexample-audit.md` for complete PASS and FAIL examples.\n\n\u003C\u002Fexample_review>\n\n\u003Csuccess_criteria>\n\nA sound verdict has these properties:\n\n- [ ] The verdict states exactly one overall determination: `APPROVED` or `REJECTED`\n- [ ] Every applicable Python concern in the verdict table was judged, with no skipped concern hidden by an approval\n- [ ] Each `FAIL` finding names the file, line, violated concern or rule, and concrete evidence\n- [ ] Each `NOT_APPLICABLE` row explains why the concern does not apply; a missing or blocked required inspection produces `FAIL`\n- [ ] The same repository state and audit scope can reproduce the verdict from the listed evidence\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":49},"Read, Grep, Glob, {{! tool('use_skill') !}}","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fpython\u002Fskills\u002Faudit-python-code","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-12 11:34:11",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add outcomeeng\u002Fplugins --skill audit-python-code",{"tool":64,"command":65},"bunx","bunx skills add outcomeeng\u002Fplugins --skill audit-python-code",{"tool":67,"command":68},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill audit-python-code","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Faudit-python-code\u002FSKILL.md",true,[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fexample-audit.md","REFERENCE","参考文档",1521,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Faudit-python-code\u002Freferences\u002Fexample-audit.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Ffalse-positive-handling.md",1665,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Faudit-python-code\u002Freferences\u002Ffalse-positive-handling.md",[83,89,124,140,156,166],{"skillNo":84,"name":85,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":44},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[85],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":103,"publishedAt":44},"01M71G23DCX3SV60H63HBBKQ6J","sanitize-powerpoint","ALWAYS invoke this skill when sanitizing, cleaning up, auditing, or aligning a PowerPoint (.pptx) deck — slide-master and layout structure, layout type attributes, stray fonts, non-theme colors, or layout naming. NEVER hand-edit pptx XML without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fsanitize-powerpoint\u002FSKILL.md",[95,100],{"categoryNo":96,"categoryName":97,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000034","行政与办公人员",[104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","invoke","when",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":44},"01M71G21PQKBCDECHGVYSKPJW5","draw-excalidraw","ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts. NEVER generate Excalidraw JSON without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",[],[131,132,133,134,135,111,122,136,137,123,138,139],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":149,"publishedAt":44},"01M71G1ZMNGFD37RZYM620XM2C","typescript-test-standards","TypeScript test standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-test-standards\u002FSKILL.md",[146],{"categoryNo":147,"categoryName":148,"taxonomyType":98,"taxonomyTypeDesc":99},"01JBSEEDCAT000000000000008","测试与质量",[150,151,152,153,154,40,155],"typescript","typescript test standards","test","standards","false","across",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":163,"publishedAt":44},"01M71G1XBH0X1VCTR7269MDGSY","typescript-code-standards","TypeScript code standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-code-standards\u002FSKILL.md",[162],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[150,27,164,165,153,154,40,155],"typescript code standards","code standards",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":44},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards","TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[173,153,174,175,150,176,177,155,40,178,154,179],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]