[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FWWJBJCJHW7CQG31XKTXP":3,"skill-same:01M71FWWJBJCJHW7CQG31XKTXP":78},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":14,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M71FWWJBJCJHW7CQG31XKTXP","audit-tests",null,"Test-evidence audit methodology — judges whether a spec node's tests provide behavior-coupled evidence its assertions are fulfilled, covering predicate ownership, source ownership, coupling, falsifiability, and full-chain coverage.","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\u002Fproduct-tree\u002Fskills\u002Faudit-tests\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"audit tests","audit","tests","evidence","Falsifiability","assertions","coupling","scope","chain","audit methodology","show","test","diff","use","coverage","branch","tool","Bash","git branch","git merge","2026-11-10 10:12:30",false,"---\nname: audit-tests\ndescription: >-\n  Test-evidence audit methodology — judges whether a spec node's tests provide\n  behavior-coupled evidence its assertions are fulfilled, covering predicate\n  ownership, source ownership, coupling, falsifiability, and full-chain coverage.\nargument-hint: \"\u003Cspec-node-path-or-evidence-scope>\"\nallowed-tools: Read, Grep, Glob, {{! tool('use_skill') !}}, Bash(git diff:*), Bash(git merge-base:*), Bash(git branch --show-current:*)\n---\n\n\u003Cobjective>\n\nA verdict on whether a spec node's tests provide behavior-coupled evidence its assertions are fulfilled — APPROVED, REJECTED with each finding on touched text naming the assertion, the failed evidence property or cross-assertion architectural duplication, and the evidentiary gap, with every other finding returned as `FILED`, or NOT_APPLICABLE with the retired subjects and their lack of current evidence ownership explained.\n\n\u003C\u002Fobjective>\n\n\u003Cconstraints>\n\n- NEVER modify the tests under audit or any other file — this audit produces a verdict, never a fix or a commit.\n- NEVER run the project's coverage command, test command, linter, type-checker, or any other deterministic verification inside the audit — deterministic verification on the changeset is a precondition; establish coverage by reading whether the test drives execution into the assertion-relevant path.\n- ALWAYS name the assertion, the failed property, and the evidentiary gap in every REJECT finding — the author repairs from the finding alone, and a finding missing any of the three leaves the repair unbounded.\n- ALWAYS construct every finding as one complete record containing `id`, `file`, `locations`, `property`, `rule`, `severity`, `message`, and `remediation_target` before adding it to a row — required fields are never deferred to verdict rendering.\n- ALWAYS reject an incomplete evidence-chain inventory before approval — an absent artifact is missing evidence, never permission to infer its contents.\n- NEVER issue a finding the evidence model does not support — drop an unbacked finding rather than reject the tests for it; NEVER reject on text the changeset leaves unchanged and does not invalidate — return that finding with severity `FILED`, and NEVER raise a recorded finding's severity or let a `FILED` finding start to reject unless the run names a changed basis. `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftouched-text.md` defines touched text, the finding key, and the `FILED` form; `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frule-catalog.md` defines the rule identifiers.\n- NEVER substitute a code-quality signal for an evidence judgment — mocking patterns, skip patterns, and type annotations are linting concerns for other tools; identify declarations by reading the test file and judge ownership from the evidence role of each declaration.\n\n\u003C\u002Fconstraints>\n\n\u003Caudit_workflow>\n\nJudge in strict order: the complete evidence-chain inventory, source testability, ownership of every declaration, then the four properties coupling, falsifiability, alignment, and coverage. A test missing any of those four properties has zero evidentiary value regardless of code quality.\n\nBind the spec-node path or evidence scope: `$ARGUMENTS` supplies it when that argument is non-empty; when it is empty, the target is the one the request text carries, and the empty substitution binds nothing. Resolve evidence paths to their governing node or lowest common ancestor before context loading; never infer a target from adjacent conversation.\n\nIf the request carries no target, return `REJECTED` with only `gate-1-assertion` as `FAIL`: one finding with `id: \"f-001\"`, `file: \"input\"`, `locations: [\"input\"]`, `property: \"evidence-chain-completeness\"`, `rule: \"missing-target\"`, `severity: \"REJECT\"`, a message naming the required node or evidence scope, and `remediation_target: \"language-partition\"`. Set `target` to the supplied string and both evidence inventory arrays to empty; set `metadata.branch` to JSON `null`. Gate 2 has no established language applicability and is omitted.\n\n\u003Cstep name=\"load_standards\">\n\n**Step 0: Load shared test-evidence standards**\n\n{!% require_skill 'product-tree:test-evidence-standards' %!} Apply its complete predicate-seam, semantic-binding, case-provenance, oracle-independence, assertion-type-litmus, mutation litmus, and assertion-design-record rules. A missing reference blocks the audit because `\u002Ftest` and this audit must judge from the same standards.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"load_context\">\n\n**Step 1: Load context**\n\nWhen the live `\u003CPRODUCT_TREE_FOUNDATION>` marker is absent: Use skill `product-tree:understand`. Then, on the spec node whose tests are being audited: Use skill `product-tree:contextualize`. This loads the spec's assertions, ancestor ADRs\u002FPDRs, and the full hierarchy context.\n\nDo not proceed without live `\u003CPRODUCT_TREE_FOUNDATION>` and `\u003CPRODUCT_TREE_CONTEXT>` markers.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"map_assertions\">\n\n**Step 2: Map assertions to test files**\n\nRead the spec's Assertions section. Only assertions carrying `[test]` evidence enter this audit. Skip assertions tagged `[eval]`, `[audit:{rule-slug}]`, or the pathless `[audit]` that the foundation admits for a toolchain without slug support; their evidence belongs to other verification workflows.\n\nFor each included assertion, extract:\n\n| Field          | Extract                                                  |\n| -------------- | -------------------------------------------------------- |\n| Assertion text | The claim being tested                                   |\n| Assertion type | Scenario \u002F Mapping \u002F Conformance \u002F Property \u002F Compliance |\n| Test link      | Path from `([test](path))`                               |\n| Link status    | File exists or missing                                   |\n\n**Missing test file = finding** with rule `missing-test-file` against the missing path. Record it and continue to next assertion.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"full_chain_ownership\">\n\n**Step 2b: Inventory the complete evidence chain**\n\nStarting from the test links mapped in Step 2, follow each repository import recursively. Record one inventory entry per artifact:\n\n| Field               | Meaning                                                                                                                      |\n| ------------------- | ---------------------------------------------------------------------------------------------------------------------------- |\n| `path`              | Repository-relative artifact path                                                                                            |\n| `role`              | `test`, `harness`, `generator`, `fixture`, `discovery`, or `production`                                                      |\n| `imported_from`     | Path that introduced the artifact, or null for root artifacts such as the linked test and applicable discovery configuration |\n| `inspection_status` | `inspected` or `unresolved`                                                                                                  |\n\nRead every resolved artifact before continuing. A referenced fixture is inventoried even when consumed only by path. Include every applicable discovery or module-resolution artifact the repository carries for the linked tests: examples include `conftest.py` or pytest configuration, Vitest configuration, `Cargo.toml`, and `go.mod`. A discovery artifact remains in `metadata.evidence_chain` when it produces no finding. The final inventory MUST contain exactly one entry for every artifact used to resolve imports, ownership, collection, or discovery.\n\nIf an import cannot be resolved from the repository, add a `gate-1-assertion` REJECT finding against the unresolved repository-relative path with rule `incomplete-evidence-chain` and `remediation_target: \"test-infrastructure\"`. Do not attribute the finding to the thin test file. Continue every check supported by the available artifacts; report a property whose required evidence is unavailable as failed missing evidence rather than inferring a judgment from unread content.\n\n**Step 3: Testability precondition**\n\nFor each assertion, read the governed production source and identify the observable boundary, seam, or injection point through which a test can exercise the assertion-relevant behavior. Judge the source shape before judging the linked test.\n\nIf the source exposes no way to observe or drive that behavior, add a `gate-1-assertion` REJECT finding against the source file with rule `untestable-source` and `remediation_target: \"source-file\"`. State the missing seam and its evidentiary consequence. Continue ownership and every other inspectable property check; preserve the testability failure regardless of those results.\n\n**Step 3a: Ownership across the evidence chain**\n\nRead each linked test file before coupling. Identify every variable, constant, local function, fixture parameter, property-generated parameter, predicate, and assertion API call and classify the proper owner:\n\nUse language syntax while reading to enumerate declarations, then classify ownership by reading the declaration and its evidence role. Do not outsource the verdict to a grep pattern or validation command.\n\nBefore classifying data bindings, resolve anything that looks like case data through the per-assertion-type litmus from `\u002Ftest-evidence-standards`, applied below. A case that litmus assigns to the test itself is correctly owned there and is never a REJECT; demanding it move into a production module is the source laundering the standard forbids.\n\nClassify each binding and predicate under `\u003Csemantic_binding_ownership>` of `\u002Ftest-evidence-standards`: assertion flow and linked-test predicates are accepted; an infrastructure predicate, test-owned configuration, test-owned data, and source-owned vocabulary copied into the test are rejected.\n\nDo not treat casing or syntax as evidence. Renaming `MAPPING_RUNS` to `mappingRuns`, changing an assignment to destructuring, or receiving a value through a parameter does not change what the binding chooses.\n\nUse property `predicate-ownership` with rule `assertion-seam` and remediation target `test-file` when infrastructure owns a predicate, matcher, expected-value parameter, assertion call, or verdict helper. Use property `oracle-independence` with rule `oracle-independence` and remediation target `independent-oracle` when an expected result derives from the production table, algorithm, parser, branch logic, or other implementation path that produces the actual result. Use property `source-ownership` with rule `source-ownership` when the test copies a source-owned singleton shape or vocabulary. Use property `declarations` for the remaining two rejections, with rule `test-owned-configuration` for a binding that chooses runner settings, seed policy, or setup or lifecycle policy, and rule `test-owned-data` for a binding that chooses boundary bags, expected outputs, fixture contents, generator domains, or case data the assertion type does not assign to the test.\n\nFor property-based tests, verify seed and replay behavior by reading the imported harness or property wrapper. If a property test has no harness-owned seed policy and no failure output that includes the seed or replay path, REJECT with rule `test-owned-configuration` or `missing-property-seed-reporting`.\n\nApply `\u003Cartifact_ownership>` of `\u002Ftest-evidence-standards` to every imported harness, generator, fixture, and discovery artifact; an artifact that owns anything those rules assign elsewhere is REJECT with `source-ownership`.\n\nJudge a source symbol the test cites by declared-contract ownership: does production consume it, emit it, publish it as API, register it, or serialize it against a declared schema? An absent in-repository caller opens that question rather than settling it, so inspect the declared surfaces the checkout carries — packaging entry points and export declarations, plugin and protocol implementations, registry and reflective lookups, generated use, and declared schemas — before reporting the symbol as laundered. Name the surfaces inspected in the finding. Report the finding when none of them requires the symbol: a consumer outside the checkout is not evidence this audit can gather, so its bare possibility never withholds a finding the declared surfaces support.\n\nFor every case input, expected value, protocol key, command token, status value, rule identifier, and payload member, name its source and independent oracle in the inventory. Apply the per-assertion-type litmus questions from `\u002Ftest-evidence-standards`. A value with no valid owner produces a `source-ownership` finding; an expectation derived from the production path under test produces an `oracle-independence` finding. The finding's `file` names the artifact that copied or coupled the value. Every `source-ownership` finding sets `remediation_target` to `source-contract`, even when the copied value appears in a harness, generator, fixture, discovery file, or test; the defect location never becomes the semantic owner. The `\u003Cassertion_design_record>` of `\u002Ftest-evidence-standards` is judged as one unit through the steps and properties that already own its fields: the assertion through Step 2's assertion mapping, the production subject through Step 3's testability precondition, case provenance through `source-ownership`, oracle owner through `oracle-independence`, and the rejected mutation with its failure observation through `falsifiability` in Step 3c.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"audit_coupling\">\n\n**Step 3b: Coupling**\n\nRead the test file's import statements. Classify each import:\n\n| Import source                                  | Classification             |\n| ---------------------------------------------- | -------------------------- |\n| Test framework (vitest, pytest, jest)          | Framework — does not count |\n| Node modules \u002F pip packages                    | Library — does not count   |\n| Codebase path (relative import, product alias) | Codebase — counts          |\n\n**Zero codebase imports → REJECT with rule `no-coupling` (tautology).**\n\nIf codebase imports exist, classify using this coupling taxonomy:\n\n| Category           | Definition                                                                                        | Verdict                                    |\n| ------------------ | ------------------------------------------------------------------------------------------------- | ------------------------------------------ |\n| Direct             | Test imports the module under test                                                                | Proceed                                    |\n| Indirect           | Test imports a harness wrapping the module                                                        | Proceed — verify harness has real coupling |\n| Transitive         | Test imports a consumer of the module                                                             | Proceed — verify test level matches        |\n| Laundered indirect | Imports a test-infrastructure module that exists only to expose hardcoded values back to the test | REJECT — rule `laundered-coupling`         |\n| False              | Imports module but never calls assertion-relevant functions                                       | REJECT — rule `false-coupling`             |\n| Partial            | Calls functions but on wrong inputs or wrong code paths                                           | REJECT — rule `partial-coupling`           |\n| None               | Test imports only its test framework                                                              | REJECT — rule `no-coupling` (tautology)    |\n| Severed            | Imports the module under test and replaces its behavior with a mock, fake, stub, or monkeypatch   | REJECT — rule `severed-coupling`           |\n| Prose-coupling     | Reads an authored prose\u002Fdoc body and asserts its content                                          | REJECT — rule `prose-coupling`             |\n\nCoupling means exercising executable **behavior**, never reading a document's content. A test whose \"subject\" is an authored prose or documentation artifact — a skill body, a spec body, a prompt, any text the product authors and maintains — that the test reads and asserts substrings of is NOT behavioral coupling, even when that artifact is the thing the assertion names. The text passes whatever it literally contains; no code runs. This holds full-chain: a harness that exposes the authored path as a constant, or a reader function that performs the read inside test infrastructure, does not convert a prose assertion into behavioral coupling — follow the read to its source and classify by what is ultimately exercised.\n\n**A test whose evidence is reading an authored prose or documentation body and asserting on its content → REJECT with rule `prose-coupling`.** The claim verifies that prose was authored, not that code behaves; its verification type belongs in `[eval]` (a graded judgment over a producer's structured verdict) or `[audit]` (a semantic constraint), and the spec assertion is retagged accordingly. Reading an authored *source-code* file for a structural lint that exercises a rule is not prose-coupling; the discriminator is whether the subject is authored prose\u002Fdocumentation or executable behavior.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"audit_falsifiability\">\n\n**Step 3c: Falsifiability**\n\nFor each codebase import, name a concrete mutation to the imported module that would cause this test to fail. Write it down:\n\n```text\nModule: src\u002Fconfig-parser.ts\nMutation: parseConfig returns empty object instead of parsed result\nImpact: \"parses nested sections\" fails — expect(result.section.key) throws\n```\n\n**Cannot name a mutation for any import → REJECT with rule `unfalsifiable`.**\n\nCheck for mocking. If the test imports a module then replaces it with a mock, the coupling is severed:\n\n```typescript\nimport { database } from \"..\u002Fsrc\u002Fdatabase\";\nvi.mock(\"..\u002Fsrc\u002Fdatabase\", () => ({ query: vi.fn() }));\n\u002F\u002F Real database.query never runs — coupling severed\n```\n\n**Import + mock = REJECT with rule `severed-coupling`.**\n\n**Exception**: a test double used under the controlled-implementation relief of `\u002Ftest-evidence-standards`, one of the seven named exception cases of the `\u002Ftest` methodology, is not `severed-coupling`. Identify the matching exception and verify the double is the type that case names.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"audit_alignment\">\n\n**Step 3d: Alignment**\n\nRead the spec assertion text. Read the test's expect\u002Fassert statements. Answer:\n\n1. Does the test exercise the exact behavior the assertion describes?\n2. Could the spec assertion be unfulfilled while the test passes?\n\nIf yes to question 2: **REJECT with rule `misaligned`.**\n\nJudge the test against the executable source contract without making the test\nduplicate or parse the authored spec text. When production exports a value or\ntyped contract, uses it in the behavior under test, and the test imports that\nsame contract while exercising the behavior, a change to the source contract is\nan intentional behavior change rather than a mutation the test must reject.\nName a mutation to the consuming behavior that would break the test. NEVER\nrequire a test or test-infrastructure artifact to parse spec or decision Markdown\nor copy a literal from that prose as an independent oracle; authored prose is\nverified through spec audit and review, and duplicated literals violate source\nownership.\n\nJudge the test strategy against `\u003Ctype_level_permissions>` and `\u003Cassertion_type_litmus>` of `\u002Ftest-evidence-standards` for the assertion type; a strategy those rules do not permit for that type is REJECT with rule `misaligned`.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"audit_coverage\">\n\n**Step 3e: Coverage**\n\nEstablish coverage by tracing whether the test reaches the assertion-relevant behavior in source.\n\nTrace, by reading, whether the test drives execution into the assertion-relevant code path:\n\n1. Read the production code the assertion governs and identify the assertion-relevant functions, branches, and lines.\n2. Read the test and follow what it calls into that production code.\n3. Judge whether the test's execution reaches the assertion-relevant path — the lines whose behavior the assertion claims.\n\n**Interpret the trace:**\n\n- **Reaches the assertion-relevant path**: the test exercises the behavior the assertion claims. ✓\n- **Imports the module but never drives execution into the assertion-relevant path**: REJECT with rule `no-coverage`. Name the specific assertion-relevant path the test fails to reach, traced from the code.\n- **The assertion-relevant path is trivially total** (the test obviously exercises every line the assertion claims): record `judgment: \"saturated\"` in `metadata.coverage_traces`. The test's evidentiary value comes from the other three properties.\n\nCoverage here is execution breadth (does the test reach the assertion-relevant lines), not assertion strength. A property-based test that exercises the same lines over a broader input domain adds behavior-coupled evidence that reading captures and a line count would not.\n\nThe judgment is traced from the code and named in the finding — never a measured percentage, and never an unbacked \"probably covers.\"\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"compose_language\">\n\n**Step 3f: Compose language-specific test-evidence concerns**\n\nThe four evidence properties above are language-neutral. Language-specific test-evidence concerns — the per-language check IDs and extraction targets named in `\u003Cverdict_format>` — are owned by the language test audit skill, not by this one.\n\nDerive language partitions from the linked-test filenames and the installed language plugins. Take the installed language skills from the skill listing already in context; no directory scan is needed. The language skills the composition reaches are:\n\n| Language   | Standards skill                        | Audit skill                        |\n| ---------- | -------------------------------------- | ---------------------------------- |\n| Python     | `python:python-test-standards`         | `python:audit-python-test`         |\n| TypeScript | `typescript:typescript-test-standards` | `typescript:audit-typescript-test` |\n| Go         | `go:go-test-standards`                 | `go:audit-go-test`                 |\n| Rust       | `rust:rust-test-standards`             | `rust:audit-rust-test`             |\n\nFor each language whose audit skill appears in the listing, load only that language's standards skill:\n\n- Python: Use skill `python:python-test-standards`.\n- TypeScript: Use skill `typescript:typescript-test-standards`.\n- Go: Use skill `go:go-test-standards`.\n- Rust: Use skill `rust:rust-test-standards`.\n\nRead the loaded skill's filename instantiation of `\u003Csubject>.\u003Cevidence>.\u003Clevel>[.\u003Crunner>]` — the concrete pattern the standard states, such as `test_\u003Csubject>.\u003Cevidence>.\u003Clevel>[.\u003Crunner>].py`. The text after the last closing bracket is the declared suffix: a compound suffix such as `.test.ts` as readily as a bare `.py` or `_test.go`. Map every linked test whose filename ends in an installed plugin's declared suffix to that language. Reject a suffix no installed plugin declares, or an ambiguous partition, with property and rule `unsupported-language` and remediation target `language-partition` instead of guessing; never map an extension from a list this skill carries.\n\nFor each language partition, invoke only that language's audit skill:\n\n- Python: Use skill `python:audit-python-test`.\n- TypeScript: Use skill `typescript:audit-typescript-test`.\n- Go: Use skill `go:audit-go-test`.\n- Rust: Use skill `rust:audit-rust-test`.\n\nValidate its output against that skill's declared verdict contract: output shape, required fields, applicable rows, and agreement between findings, row statuses, and overall status. Malformed or incomplete evidence adds a `gate-1-assertion` `REJECT` finding with property and rule `language-composition`; continue the remaining languages.\n\nMerge each valid result's findings into the matching rows by `name` — append, never replace — and derive their statuses under `\u003Cverdict_format>`. A composed finding keeps the rule identifier from the rule catalog of the invoked `audit-\u003Clang>-test` skill and is keyed `\u003Cfile>:\u003Cthat identifier>`; composed findings sharing a key join into one finding whose `locations` list holds each of their locations. Merge its evidence-chain entries and coverage traces with the shared inspection, preserving every inspected artifact and assertion without duplicate entries. A composed rejection remains a rejection in the merged result. When a required `audit-\u003Clang>-test` skill is absent or unavailable, mark `gate-1-assertion` as `FAIL` and append a `REJECT` finding there naming the missing skill, property and rule `language-composition`, and remediation target `skill-installation`; never approve incomplete coverage.\n\nA language audit returns a third shape when its own scope step finds that every subject it was given is a retired path with no current `[test]` assertion and no current evidence-chain owner: `{\"status\": \"NOT_APPLICABLE\", \"subjects\": [...], \"explanation\": \"...\"}`, carrying no rows and no findings. Treat it as neither a pass nor a failure of that language's concerns. Record the language, reported subjects, and explanation as one `metadata.not_applicable` entry, compose the remaining languages normally, and decide the overall verdict from the rows that do exist. When every language in scope returns `NOT_APPLICABLE` and no language-neutral finding was raised, emit that same shape rather than an approval, because no evidence was judged.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"compose_architectural\">\n\n**Step 3g: Roll up composed architectural duplication**\n\nGate 2 is a composed-language concern. It applies when at least one language-specific verdict returns a `gate-2-architectural` row. Merge every applicable Gate 2 finding by row name, preserving each finding's language-specific rule and extraction target.\n\n- Return Gate 2 `FAIL` when any composed Gate 2 row contains a `REJECT` finding.\n- Return Gate 2 `PASS` when every applicable composed Gate 2 row passes.\n- Omit Gate 2 only when every composed language verdict omits it — as non-applicable, or because that language's Gate 1 rejected the evidence, so its Gate 2 never ran.\n- Treat a malformed or unevaluated applicable Gate 2 row as failed `language-composition` evidence; never infer architectural approval.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"verdict\">\n\n**Step 4: Issue verdict**\n\nScan all findings across all assertions, including any folded in from the composed language audit; any REJECT finding makes the verdict **REJECTED**.\n\nBefore row rollup, inspect every finding as a complete record. Require every finding field from `\u003Cverdict_format>`, including `remediation_target`, and derive that target from the semantic owner named by the evidence model. Complete a missing field before adding the finding to a row; never emit a partial finding and rely on its message to imply the omitted field.\n\n\u003C\u002Fstep>\n\n\u003C\u002Faudit_workflow>\n\n\u003Cverdict_format>\n\nThe `NOT_APPLICABLE` result defined in Step 3f is the alternate output when no evidence is applicable; it contains only `status`, `subjects`, and `explanation`, and the gate-verdict schema below does not apply. Every gate verdict includes `metadata.branch`: the output of `git branch --show-current`, an empty string for a detached HEAD, or JSON `null` when unavailable.\n\nEmit the verdict as a single JSON object. This JSON is the skill's entire output; never emit a prose or markdown verdict.\n\nThe skill's `overall` is `APPROVED` iff every applicable gate row is `PASS`; otherwise it is `REJECTED`. A required gate that cannot be evaluated is a `FAIL` row with a `REJECT` finding naming the missing evidence. Findings within each row carry severity `REJECT` for blocking findings (these are what flip a row to `FAIL`), `FILED` for a finding outside touched text, which fails no row and additionally carries `key`, `baseRefEvidence`, and `issuesEntry` (`path`, `heading`), and `WARNING` or `INFO` for non-blocking observations. Every finding MUST include every field shown in its row schema: `id`, `file`, `locations`, `property`, `rule`, `severity`, `message`, and `remediation_target`; omission of any field is an invalid verdict. A finding is keyed `\u003Cfile>:\u003Crule-id>`, where `file` is the repository-relative path of the artifact that holds the defect, or `input` when the request carries no target, and `\u003Crule-id>` comes from `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frule-catalog.md`. One key covers every location in that file where the rule is violated, and `locations` lists each as the assertion, full text or stable id, joined to the declaration or call that violates the rule, named by its text and never by a line number. A `\u003Crule-id>` outside that catalog and the catalogs of the composed language skills is never emitted.\n\nThe `metadata.evidence_chain` array MUST project the complete inspected inventory. Preserve every applicable discovery artifact even when it carries no finding. The `metadata.coverage_traces` array projects Step 3e: a language-specific concern includes traces for the coverage it judges and leaves the array empty only when coverage is outside its declared scope; this audit's merged verdict MUST carry one entry per audited assertion, naming the assertion-relevant source path, the test path followed into it, and the coverage judgment. Use `saturated` only for a trivially total path reached by the test. The `metadata.not_applicable` array holds one entry per language that returned `NOT_APPLICABLE`, and stays empty otherwise.\n\n```json\n{\n  \"schema_version\": 1,\n  \"skill\": \"audit-tests\",\n  \"target\": \"\u003Cspec-node-path>\",\n  \"overall\": \"APPROVED | REJECTED\",\n  \"rows\": [\n    {\n      \"name\": \"gate-1-assertion\",\n      \"status\": \"PASS | FAIL\",\n      \"findings\": [\n        {\n          \"id\": \"f-002\",\n          \"file\": \"\u003Ctest-file>\",\n          \"locations\": [\"\u003Cfull-assertion-text-or-stable-id>: \u003Cdeclaration-or-call-text>\"],\n          \"property\": \"\u003Ctestability | evidence-chain-completeness | declarations | predicate-ownership | source-ownership | oracle-independence | coupling | falsifiability | alignment | coverage | language-composition | unsupported-language>\",\n          \"rule\": \"\u003Crule-id from references\u002Frule-catalog.md>\",\n          \"severity\": \"REJECT | FILED | WARNING | INFO\",\n          \"message\": \"\u003Cone-line evidentiary gap>\",\n          \"remediation_target\": \"\u003Csource-contract | harness | generator | fixture | eval-case | test-file | source-file | test-infrastructure | independent-oracle | skill-installation | language-partition>\"\n        }\n      ]\n    },\n    {\n      \"name\": \"gate-2-architectural\",\n      \"status\": \"PASS | FAIL\",\n      \"findings\": [\n        {\n          \"id\": \"f-003\",\n          \"file\": \"\u003Ctest-file>\",\n          \"locations\": [\"\u003Cfull-assertion-text-or-stable-id | cross-assertion>: \u003Cduplicated-declaration-text>\"],\n          \"property\": \"architectural-duplication\",\n          \"rule\": \"\u003Crule-id from the composed language skill's rule catalog>\",\n          \"severity\": \"REJECT | FILED | WARNING | INFO\",\n          \"message\": \"\u003Cextraction target>: \u003Cnearest common test-infrastructure location>\",\n          \"remediation_target\": \"\u003Csource-contract | harness | generator | fixture | eval-case | test-file | source-file | test-infrastructure | independent-oracle | skill-installation | language-partition>\"\n        }\n      ]\n    }\n  ],\n  \"metadata\": {\n    \"branch\": null,\n    \"evidence_chain\": [\n      {\n        \"path\": \"\u003Crepository-relative-path>\",\n        \"role\": \"test | harness | generator | fixture | discovery | production\",\n        \"imported_from\": \"\u003Crepository-relative-path-or-null>\",\n        \"inspection_status\": \"inspected | unresolved\"\n      }\n    ],\n    \"coverage_traces\": [\n      {\n        \"assertion\": \"\u003Cfull-assertion-text-or-stable-id>\",\n        \"source_path\": \"\u003Crepository-relative-assertion-relevant-path>\",\n        \"test_path\": \"\u003Crepository-relative-test-path-and-call-chain>\",\n        \"judgment\": \"reaches | saturated | missing\"\n      }\n    ],\n    \"not_applicable\": [{ \"language\": \"\u003Clanguage>\", \"subjects\": [\"\u003Crepository-relative-path>\"], \"explanation\": \"\u003Creason>\" }]\n  }\n}\n```\n\nA non-applicable Gate 2 row is omitted. A required gate that cannot be evaluated uses `status: \"FAIL\"` with a `REJECT` finding naming the missing evidence. A `source-ownership` finding uses `property: \"source-ownership\"`, `rule: \"source-ownership\"`, and `remediation_target: \"source-contract\"`; other findings select the failed property, the catalogued rule, and the owner that must change from the enumerated values. This verdict schema contains no `gate-0-deterministic` row.\n\n\u003C\u002Fverdict_format>\n\n\u003Cfailure_modes>\n\n**Failure 1: Accepted a tautological test file**\n\nClaude approved a test file that imported only vitest. It declared OKLCH color constants and verified they satisfied contrast thresholds — pure math with zero connection to any CSS file, theme, or component. The tests pass if the entire codebase is deleted. Claude was distracted by clean types, good structure, and comprehensive scenarios, and never checked the imports.\n\nHow to avoid: Step 3b checks imports before the other evidence properties. Zero codebase imports = instant REJECT.\n\n**Failure 2: Accepted mocking as legitimate coupling**\n\nClaude saw `import { database } from \"..\u002Fsrc\u002Fdatabase\"` and classified it as direct coupling. The next line was `vi.mock(\"..\u002Fsrc\u002Fdatabase\")`. The real module never ran.\n\nHow to avoid: Step 3c checks for mocking after confirming coupling. Import + mock = coupling severed.\n\n**Failure 3: Re-ran the project's coverage command inside the audit**\n\nClaude ran the project's coverage command three times (baseline, with-test, isolated) to measure a delta. Those runs added no audit evidence and repeated work excluded by `\u003Cconstraints>`.\n\nHow to avoid: Step 3e traces coverage by reading whether the test drives execution into the assertion-relevant path. Name the path from the code; never run the coverage or test command, and never substitute an unbacked \"probably covers\" for the trace.\n\n**Failure 4: Distracted by code quality signals**\n\nClaude spent the entire audit checking for `as any`, verifying return types, and searching for skip patterns. The test had perfect TypeScript quality and zero evidentiary value. Quality signals are linting concerns, not audit concerns.\n\nHow to avoid: Follow the complete ordered audit sequence: inventory the evidence chain, check source testability, screen test-owned declarations, then judge coupling, falsifiability, alignment, and coverage.\n\n**Failure 5: Approved a prose-body substring test as direct coupling**\n\nClaude audited a test that read an authored skill body and asserted that policy substrings were present, and rated coupling PASS — \"direct coupling to the artifact; the text is the thing under test\" — and falsifiability PASS — \"removing the clause from the skill body breaks the test.\" The test exercises no code; only an edit to the authored prose falsifies it, so it carries no behavioral evidence, yet the four-property model rationalized it as conformance.\n\nHow to avoid: Step 3b — after identifying what a test reads, classify by whether the subject is executable behavior or authored prose\u002Fdocumentation, not by whether the path resolves to a repository file. A read of an authored prose or documentation body asserted for its content is prose-coupling → REJECT, however the path is resolved and whatever harness mediates the read.\n\n**Failure 6: Accepted renamed test-local configuration**\n\nClaude saw a validation warning for a SCREAMING_CASE test constant used as a property-test run count, renamed it to camelCase, and approved the audit because the validator stopped flagging it. The value was still runner configuration in the executed test file. The rename only evaded a heuristic.\n\nHow to avoid: Step 3a reads declarations before coupling and classifies ownership. Runner counts, seeds, replay policy, setup choices, boundary bags, expected outputs, fixture paths, and generated domains belong in harnesses, generators, source contracts, inert fixtures, or eval cases — never in the test file under a different name.\n\n**Failure 7: Approved a thin test without auditing its harness**\n\nClaude inspected a linked Python test that imported a harness, then reviewed only three repeated `file.txt` values in the harness and approved them as harness-owned synthetic vocabulary. The harness also declared SPX payload keys, command tokens, producer identities, status values, and expected projection fields. The verdict omitted the imported-artifact inventory and never classified most values.\n\nHow to avoid: Step 2b inventories and reads the complete evidence chain before judgment. Step 3a names the source of every protocol value and rejects harness-declared domain truth with `source-ownership`. Approval requires the inventory in verdict metadata.\n\n**Failure 8: Rejected observation and resource bindings by syntax**\n\nClaude rejected a temporary-directory fixture parameter and a local `observations` binding even though both only received values selected by their owning infrastructure. The proposed remediation moved those handles into the harness, obscuring assertion flow without changing any semantic owner.\n\nHow to avoid: Step 3a classifies each binding by the semantic-binding rule of `\u002Ftest-evidence-standards`, never by its syntax.\n\n**Failure 9: Used the defect location as the remediation owner**\n\nClaude correctly found copied protocol fields in a harness and emitted `source-ownership`, then set `remediation_target` to `harness` because that file contained the defect. The verdict failed its structural contract: copied domain truth belongs to a source contract regardless of where the copy appears.\n\nHow to avoid: Keep location and ownership separate. Set `file` to the artifact containing the copy and set every `source-ownership` finding's `remediation_target` to `source-contract`.\n\n**Failure 10: Omitted a language manifest from the evidence chain**\n\nClaude inspected a Rust test, harness, generator, and production module, then omitted the package's `Cargo.toml` from `metadata.evidence_chain` because it carried no finding. The manifest established package and test discovery, so the verdict's inventory was incomplete.\n\nHow to avoid: Inventory applicable discovery and module-resolution artifacts even when they produce no finding. This includes pytest and Vitest configuration, Cargo manifests, and Go module files when they establish the test boundary.\n\n**Failure 11: Emitted a semantically correct but structurally incomplete finding**\n\nClaude rejected a production-derived oracle with the correct assertion, property, rule, artifact, and evidence chain, then omitted `remediation_target` from the finding. The prose diagnosis named the need for an independent oracle, but prose cannot substitute for a required verdict field and the structured verdict was invalid.\n\nHow to avoid: Construct each finding atomically from the canonical finding schema before row rollup, derive `remediation_target` from the evidence model, and perform the Step 4 completeness check before emitting the verdict.\n\n**Failure 12: Read an absent in-repository caller as proof of laundering**\n\nClaude rejected a package's `__version__` as source-ownership laundering because no module in the checkout consumed it. The packaging manifest declares it as published API, a surface the audit never opened, so a real contract was reported as a test-only address.\n\nHow to avoid: Judge ownership by the contract outside the test tree, and read the checkout's declared surfaces — packaging entry points and export declarations, plugin and protocol implementations, registry and reflective lookups, generated use, and declared schemas — before reporting a symbol as laundered.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\nThe verdict is sound when:\n\n- Every in-scope assertion and required language concern has a gate determination, with no evidence partition left unevaluated.\n- Every imported evidence artifact appears in verdict metadata with its role, import origin, and inspection status; approval contains only inspected entries.\n- Every protocol and domain value resolves to its production or platform owner; generated variable data resolves to a generator, inert whole payloads to fixtures, setup policy to harnesses, and curated examples to eval cases.\n- The overall APPROVED\u002FREJECTED value agrees with every applicable gate row.\n- Every REJECT finding lies on touched text, carries the complete canonical schema, and names a falsifiable evidentiary gap against the affected assertion and artifact; every finding outside touched text appears as `FILED` with its key, `baseRefEvidence`, and `issuesEntry`.\n- Every coverage determination identifies the assertion-relevant source path reached or omitted, and the same evidence yields the same verdict.\n\n\u003C\u002Fsuccess_criteria>\n","\u003Cobjective>\n\nA verdict on whether a spec node's tests provide behavior-coupled evidence its assertions are fulfilled — APPROVED, REJECTED with each finding on touched text naming the assertion, the failed evidence property or cross-assertion architectural duplication, and the evidentiary gap, with every other finding returned as `FILED`, or NOT_APPLICABLE with the retired subjects and their lack of current evidence ownership explained.\n\n\u003C\u002Fobjective>\n\n\u003Cconstraints>\n\n- NEVER modify the tests under audit or any other file — this audit produces a verdict, never a fix or a commit.\n- NEVER run the project's coverage command, test command, linter, type-checker, or any other deterministic verification inside the audit — deterministic verification on the changeset is a precondition; establish coverage by reading whether the test drives execution into the assertion-relevant path.\n- ALWAYS name the assertion, the failed property, and the evidentiary gap in every REJECT finding — the author repairs from the finding alone, and a finding missing any of the three leaves the repair unbounded.\n- ALWAYS construct every finding as one complete record containing `id`, `file`, `locations`, `property`, `rule`, `severity`, `message`, and `remediation_target` before adding it to a row — required fields are never deferred to verdict rendering.\n- ALWAYS reject an incomplete evidence-chain inventory before approval — an absent artifact is missing evidence, never permission to infer its contents.\n- NEVER issue a finding the evidence model does not support — drop an unbacked finding rather than reject the tests for it; NEVER reject on text the changeset leaves unchanged and does not invalidate — return that finding with severity `FILED`, and NEVER raise a recorded finding's severity or let a `FILED` finding start to reject unless the run names a changed basis. `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftouched-text.md` defines touched text, the finding key, and the `FILED` form; `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frule-catalog.md` defines the rule identifiers.\n- NEVER substitute a code-quality signal for an evidence judgment — mocking patterns, skip patterns, and type annotations are linting concerns for other tools; identify declarations by reading the test file and judge ownership from the evidence role of each declaration.\n\n\u003C\u002Fconstraints>\n\n\u003Caudit_workflow>\n\nJudge in strict order: the complete evidence-chain inventory, source testability, ownership of every declaration, then the four properties coupling, falsifiability, alignment, and coverage. A test missing any of those four properties has zero evidentiary value regardless of code quality.\n\nBind the spec-node path or evidence scope: `$ARGUMENTS` supplies it when that argument is non-empty; when it is empty, the target is the one the request text carries, and the empty substitution binds nothing. Resolve evidence paths to their governing node or lowest common ancestor before context loading; never infer a target from adjacent conversation.\n\nIf the request carries no target, return `REJECTED` with only `gate-1-assertion` as `FAIL`: one finding with `id: \"f-001\"`, `file: \"input\"`, `locations: [\"input\"]`, `property: \"evidence-chain-completeness\"`, `rule: \"missing-target\"`, `severity: \"REJECT\"`, a message naming the required node or evidence scope, and `remediation_target: \"language-partition\"`. Set `target` to the supplied string and both evidence inventory arrays to empty; set `metadata.branch` to JSON `null`. Gate 2 has no established language applicability and is omitted.\n\n\u003Cstep name=\"load_standards\">\n\n**Step 0: Load shared test-evidence standards**\n\n{!% require_skill 'product-tree:test-evidence-standards' %!} Apply its complete predicate-seam, semantic-binding, case-provenance, oracle-independence, assertion-type-litmus, mutation litmus, and assertion-design-record rules. A missing reference blocks the audit because `\u002Ftest` and this audit must judge from the same standards.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"load_context\">\n\n**Step 1: Load context**\n\nWhen the live `\u003CPRODUCT_TREE_FOUNDATION>` marker is absent: Use skill `product-tree:understand`. Then, on the spec node whose tests are being audited: Use skill `product-tree:contextualize`. This loads the spec's assertions, ancestor ADRs\u002FPDRs, and the full hierarchy context.\n\nDo not proceed without live `\u003CPRODUCT_TREE_FOUNDATION>` and `\u003CPRODUCT_TREE_CONTEXT>` markers.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"map_assertions\">\n\n**Step 2: Map assertions to test files**\n\nRead the spec's Assertions section. Only assertions carrying `[test]` evidence enter this audit. Skip assertions tagged `[eval]`, `[audit:{rule-slug}]`, or the pathless `[audit]` that the foundation admits for a toolchain without slug support; their evidence belongs to other verification workflows.\n\nFor each included assertion, extract:\n\n| Field          | Extract                                                  |\n| -------------- | -------------------------------------------------------- |\n| Assertion text | The claim being tested                                   |\n| Assertion type | Scenario \u002F Mapping \u002F Conformance \u002F Property \u002F Compliance |\n| Test link      | Path from `([test](path))`                               |\n| Link status    | File exists or missing                                   |\n\n**Missing test file = finding** with rule `missing-test-file` against the missing path. Record it and continue to next assertion.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"full_chain_ownership\">\n\n**Step 2b: Inventory the complete evidence chain**\n\nStarting from the test links mapped in Step 2, follow each repository import recursively. Record one inventory entry per artifact:\n\n| Field               | Meaning                                                                                                                      |\n| ------------------- | ---------------------------------------------------------------------------------------------------------------------------- |\n| `path`              | Repository-relative artifact path                                                                                            |\n| `role`              | `test`, `harness`, `generator`, `fixture`, `discovery`, or `production`                                                      |\n| `imported_from`     | Path that introduced the artifact, or null for root artifacts such as the linked test and applicable discovery configuration |\n| `inspection_status` | `inspected` or `unresolved`                                                                                                  |\n\nRead every resolved artifact before continuing. A referenced fixture is inventoried even when consumed only by path. Include every applicable discovery or module-resolution artifact the repository carries for the linked tests: examples include `conftest.py` or pytest configuration, Vitest configuration, `Cargo.toml`, and `go.mod`. A discovery artifact remains in `metadata.evidence_chain` when it produces no finding. The final inventory MUST contain exactly one entry for every artifact used to resolve imports, ownership, collection, or discovery.\n\nIf an import cannot be resolved from the repository, add a `gate-1-assertion` REJECT finding against the unresolved repository-relative path with rule `incomplete-evidence-chain` and `remediation_target: \"test-infrastructure\"`. Do not attribute the finding to the thin test file. Continue every check supported by the available artifacts; report a property whose required evidence is unavailable as failed missing evidence rather than inferring a judgment from unread content.\n\n**Step 3: Testability precondition**\n\nFor each assertion, read the governed production source and identify the observable boundary, seam, or injection point through which a test can exercise the assertion-relevant behavior. Judge the source shape before judging the linked test.\n\nIf the source exposes no way to observe or drive that behavior, add a `gate-1-assertion` REJECT finding against the source file with rule `untestable-source` and `remediation_target: \"source-file\"`. State the missing seam and its evidentiary consequence. Continue ownership and every other inspectable property check; preserve the testability failure regardless of those results.\n\n**Step 3a: Ownership across the evidence chain**\n\nRead each linked test file before coupling. Identify every variable, constant, local function, fixture parameter, property-generated parameter, predicate, and assertion API call and classify the proper owner:\n\nUse language syntax while reading to enumerate declarations, then classify ownership by reading the declaration and its evidence role. Do not outsource the verdict to a grep pattern or validation command.\n\nBefore classifying data bindings, resolve anything that looks like case data through the per-assertion-type litmus from `\u002Ftest-evidence-standards`, applied below. A case that litmus assigns to the test itself is correctly owned there and is never a REJECT; demanding it move into a production module is the source laundering the standard forbids.\n\nClassify each binding and predicate under `\u003Csemantic_binding_ownership>` of `\u002Ftest-evidence-standards`: assertion flow and linked-test predicates are accepted; an infrastructure predicate, test-owned configuration, test-owned data, and source-owned vocabulary copied into the test are rejected.\n\nDo not treat casing or syntax as evidence. Renaming `MAPPING_RUNS` to `mappingRuns`, changing an assignment to destructuring, or receiving a value through a parameter does not change what the binding chooses.\n\nUse property `predicate-ownership` with rule `assertion-seam` and remediation target `test-file` when infrastructure owns a predicate, matcher, expected-value parameter, assertion call, or verdict helper. Use property `oracle-independence` with rule `oracle-independence` and remediation target `independent-oracle` when an expected result derives from the production table, algorithm, parser, branch logic, or other implementation path that produces the actual result. Use property `source-ownership` with rule `source-ownership` when the test copies a source-owned singleton shape or vocabulary. Use property `declarations` for the remaining two rejections, with rule `test-owned-configuration` for a binding that chooses runner settings, seed policy, or setup or lifecycle policy, and rule `test-owned-data` for a binding that chooses boundary bags, expected outputs, fixture contents, generator domains, or case data the assertion type does not assign to the test.\n\nFor property-based tests, verify seed and replay behavior by reading the imported harness or property wrapper. If a property test has no harness-owned seed policy and no failure output that includes the seed or replay path, REJECT with rule `test-owned-configuration` or `missing-property-seed-reporting`.\n\nApply `\u003Cartifact_ownership>` of `\u002Ftest-evidence-standards` to every imported harness, generator, fixture, and discovery artifact; an artifact that owns anything those rules assign elsewhere is REJECT with `source-ownership`.\n\nJudge a source symbol the test cites by declared-contract ownership: does production consume it, emit it, publish it as API, register it, or serialize it against a declared schema? An absent in-repository caller opens that question rather than settling it, so inspect the declared surfaces the checkout carries — packaging entry points and export declarations, plugin and protocol implementations, registry and reflective lookups, generated use, and declared schemas — before reporting the symbol as laundered. Name the surfaces inspected in the finding. Report the finding when none of them requires the symbol: a consumer outside the checkout is not evidence this audit can gather, so its bare possibility never withholds a finding the declared surfaces support.\n\nFor every case input, expected value, protocol key, command token, status value, rule identifier, and payload member, name its source and independent oracle in the inventory. Apply the per-assertion-type litmus questions from `\u002Ftest-evidence-standards`. A value with no valid owner produces a `source-ownership` finding; an expectation derived from the production path under test produces an `oracle-independence` finding. The finding's `file` names the artifact that copied or coupled the value. Every `source-ownership` finding sets `remediation_target` to `source-contract`, even when the copied value appears in a harness, generator, fixture, discovery file, or test; the defect location never becomes the semantic owner. The `\u003Cassertion_design_record>` of `\u002Ftest-evidence-standards` is judged as one unit through the steps and properties that already own its fields: the assertion through Step 2's assertion mapping, the production subject through Step 3's testability precondition, case provenance through `source-ownership`, oracle owner through `oracle-independence`, and the rejected mutation with its failure observation through `falsifiability` in Step 3c.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"audit_coupling\">\n\n**Step 3b: Coupling**\n\nRead the test file's import statements. Classify each import:\n\n| Import source                                  | Classification             |\n| ---------------------------------------------- | -------------------------- |\n| Test framework (vitest, pytest, jest)          | Framework — does not count |\n| Node modules \u002F pip packages                    | Library — does not count   |\n| Codebase path (relative import, product alias) | Codebase — counts          |\n\n**Zero codebase imports → REJECT with rule `no-coupling` (tautology).**\n\nIf codebase imports exist, classify using this coupling taxonomy:\n\n| Category           | Definition                                                                                        | Verdict                                    |\n| ------------------ | ------------------------------------------------------------------------------------------------- | ------------------------------------------ |\n| Direct             | Test imports the module under test                                                                | Proceed                                    |\n| Indirect           | Test imports a harness wrapping the module                                                        | Proceed — verify harness has real coupling |\n| Transitive         | Test imports a consumer of the module                                                             | Proceed — verify test level matches        |\n| Laundered indirect | Imports a test-infrastructure module that exists only to expose hardcoded values back to the test | REJECT — rule `laundered-coupling`         |\n| False              | Imports module but never calls assertion-relevant functions                                       | REJECT — rule `false-coupling`             |\n| Partial            | Calls functions but on wrong inputs or wrong code paths                                           | REJECT — rule `partial-coupling`           |\n| None               | Test imports only its test framework                                                              | REJECT — rule `no-coupling` (tautology)    |\n| Severed            | Imports the module under test and replaces its behavior with a mock, fake, stub, or monkeypatch   | REJECT — rule `severed-coupling`           |\n| Prose-coupling     | Reads an authored prose\u002Fdoc body and asserts its content                                          | REJECT — rule `prose-coupling`             |\n\nCoupling means exercising executable **behavior**, never reading a document's content. A test whose \"subject\" is an authored prose or documentation artifact — a skill body, a spec body, a prompt, any text the product authors and maintains — that the test reads and asserts substrings of is NOT behavioral coupling, even when that artifact is the thing the assertion names. The text passes whatever it literally contains; no code runs. This holds full-chain: a harness that exposes the authored path as a constant, or a reader function that performs the read inside test infrastructure, does not convert a prose assertion into behavioral coupling — follow the read to its source and classify by what is ultimately exercised.\n\n**A test whose evidence is reading an authored prose or documentation body and asserting on its content → REJECT with rule `prose-coupling`.** The claim verifies that prose was authored, not that code behaves; its verification type belongs in `[eval]` (a graded judgment over a producer's structured verdict) or `[audit]` (a semantic constraint), and the spec assertion is retagged accordingly. Reading an authored *source-code* file for a structural lint that exercises a rule is not prose-coupling; the discriminator is whether the subject is authored prose\u002Fdocumentation or executable behavior.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"audit_falsifiability\">\n\n**Step 3c: Falsifiability**\n\nFor each codebase import, name a concrete mutation to the imported module that would cause this test to fail. Write it down:\n\n```text\nModule: src\u002Fconfig-parser.ts\nMutation: parseConfig returns empty object instead of parsed result\nImpact: \"parses nested sections\" fails — expect(result.section.key) throws\n```\n\n**Cannot name a mutation for any import → REJECT with rule `unfalsifiable`.**\n\nCheck for mocking. If the test imports a module then replaces it with a mock, the coupling is severed:\n\n```typescript\nimport { database } from \"..\u002Fsrc\u002Fdatabase\";\nvi.mock(\"..\u002Fsrc\u002Fdatabase\", () => ({ query: vi.fn() }));\n\u002F\u002F Real database.query never runs — coupling severed\n```\n\n**Import + mock = REJECT with rule `severed-coupling`.**\n\n**Exception**: a test double used under the controlled-implementation relief of `\u002Ftest-evidence-standards`, one of the seven named exception cases of the `\u002Ftest` methodology, is not `severed-coupling`. Identify the matching exception and verify the double is the type that case names.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"audit_alignment\">\n\n**Step 3d: Alignment**\n\nRead the spec assertion text. Read the test's expect\u002Fassert statements. Answer:\n\n1. Does the test exercise the exact behavior the assertion describes?\n2. Could the spec assertion be unfulfilled while the test passes?\n\nIf yes to question 2: **REJECT with rule `misaligned`.**\n\nJudge the test against the executable source contract without making the test\nduplicate or parse the authored spec text. When production exports a value or\ntyped contract, uses it in the behavior under test, and the test imports that\nsame contract while exercising the behavior, a change to the source contract is\nan intentional behavior change rather than a mutation the test must reject.\nName a mutation to the consuming behavior that would break the test. NEVER\nrequire a test or test-infrastructure artifact to parse spec or decision Markdown\nor copy a literal from that prose as an independent oracle; authored prose is\nverified through spec audit and review, and duplicated literals violate source\nownership.\n\nJudge the test strategy against `\u003Ctype_level_permissions>` and `\u003Cassertion_type_litmus>` of `\u002Ftest-evidence-standards` for the assertion type; a strategy those rules do not permit for that type is REJECT with rule `misaligned`.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"audit_coverage\">\n\n**Step 3e: Coverage**\n\nEstablish coverage by tracing whether the test reaches the assertion-relevant behavior in source.\n\nTrace, by reading, whether the test drives execution into the assertion-relevant code path:\n\n1. Read the production code the assertion governs and identify the assertion-relevant functions, branches, and lines.\n2. Read the test and follow what it calls into that production code.\n3. Judge whether the test's execution reaches the assertion-relevant path — the lines whose behavior the assertion claims.\n\n**Interpret the trace:**\n\n- **Reaches the assertion-relevant path**: the test exercises the behavior the assertion claims. ✓\n- **Imports the module but never drives execution into the assertion-relevant path**: REJECT with rule `no-coverage`. Name the specific assertion-relevant path the test fails to reach, traced from the code.\n- **The assertion-relevant path is trivially total** (the test obviously exercises every line the assertion claims): record `judgment: \"saturated\"` in `metadata.coverage_traces`. The test's evidentiary value comes from the other three properties.\n\nCoverage here is execution breadth (does the test reach the assertion-relevant lines), not assertion strength. A property-based test that exercises the same lines over a broader input domain adds behavior-coupled evidence that reading captures and a line count would not.\n\nThe judgment is traced from the code and named in the finding — never a measured percentage, and never an unbacked \"probably covers.\"\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"compose_language\">\n\n**Step 3f: Compose language-specific test-evidence concerns**\n\nThe four evidence properties above are language-neutral. Language-specific test-evidence concerns — the per-language check IDs and extraction targets named in `\u003Cverdict_format>` — are owned by the language test audit skill, not by this one.\n\nDerive language partitions from the linked-test filenames and the installed language plugins. Take the installed language skills from the skill listing already in context; no directory scan is needed. The language skills the composition reaches are:\n\n| Language   | Standards skill                        | Audit skill                        |\n| ---------- | -------------------------------------- | ---------------------------------- |\n| Python     | `python:python-test-standards`         | `python:audit-python-test`         |\n| TypeScript | `typescript:typescript-test-standards` | `typescript:audit-typescript-test` |\n| Go         | `go:go-test-standards`                 | `go:audit-go-test`                 |\n| Rust       | `rust:rust-test-standards`             | `rust:audit-rust-test`             |\n\nFor each language whose audit skill appears in the listing, load only that language's standards skill:\n\n- Python: Use skill `python:python-test-standards`.\n- TypeScript: Use skill `typescript:typescript-test-standards`.\n- Go: Use skill `go:go-test-standards`.\n- Rust: Use skill `rust:rust-test-standards`.\n\nRead the loaded skill's filename instantiation of `\u003Csubject>.\u003Cevidence>.\u003Clevel>[.\u003Crunner>]` — the concrete pattern the standard states, such as `test_\u003Csubject>.\u003Cevidence>.\u003Clevel>[.\u003Crunner>].py`. The text after the last closing bracket is the declared suffix: a compound suffix such as `.test.ts` as readily as a bare `.py` or `_test.go`. Map every linked test whose filename ends in an installed plugin's declared suffix to that language. Reject a suffix no installed plugin declares, or an ambiguous partition, with property and rule `unsupported-language` and remediation target `language-partition` instead of guessing; never map an extension from a list this skill carries.\n\nFor each language partition, invoke only that language's audit skill:\n\n- Python: Use skill `python:audit-python-test`.\n- TypeScript: Use skill `typescript:audit-typescript-test`.\n- Go: Use skill `go:audit-go-test`.\n- Rust: Use skill `rust:audit-rust-test`.\n\nValidate its output against that skill's declared verdict contract: output shape, required fields, applicable rows, and agreement between findings, row statuses, and overall status. Malformed or incomplete evidence adds a `gate-1-assertion` `REJECT` finding with property and rule `language-composition`; continue the remaining languages.\n\nMerge each valid result's findings into the matching rows by `name` — append, never replace — and derive their statuses under `\u003Cverdict_format>`. A composed finding keeps the rule identifier from the rule catalog of the invoked `audit-\u003Clang>-test` skill and is keyed `\u003Cfile>:\u003Cthat identifier>`; composed findings sharing a key join into one finding whose `locations` list holds each of their locations. Merge its evidence-chain entries and coverage traces with the shared inspection, preserving every inspected artifact and assertion without duplicate entries. A composed rejection remains a rejection in the merged result. When a required `audit-\u003Clang>-test` skill is absent or unavailable, mark `gate-1-assertion` as `FAIL` and append a `REJECT` finding there naming the missing skill, property and rule `language-composition`, and remediation target `skill-installation`; never approve incomplete coverage.\n\nA language audit returns a third shape when its own scope step finds that every subject it was given is a retired path with no current `[test]` assertion and no current evidence-chain owner: `{\"status\": \"NOT_APPLICABLE\", \"subjects\": [...], \"explanation\": \"...\"}`, carrying no rows and no findings. Treat it as neither a pass nor a failure of that language's concerns. Record the language, reported subjects, and explanation as one `metadata.not_applicable` entry, compose the remaining languages normally, and decide the overall verdict from the rows that do exist. When every language in scope returns `NOT_APPLICABLE` and no language-neutral finding was raised, emit that same shape rather than an approval, because no evidence was judged.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"compose_architectural\">\n\n**Step 3g: Roll up composed architectural duplication**\n\nGate 2 is a composed-language concern. It applies when at least one language-specific verdict returns a `gate-2-architectural` row. Merge every applicable Gate 2 finding by row name, preserving each finding's language-specific rule and extraction target.\n\n- Return Gate 2 `FAIL` when any composed Gate 2 row contains a `REJECT` finding.\n- Return Gate 2 `PASS` when every applicable composed Gate 2 row passes.\n- Omit Gate 2 only when every composed language verdict omits it — as non-applicable, or because that language's Gate 1 rejected the evidence, so its Gate 2 never ran.\n- Treat a malformed or unevaluated applicable Gate 2 row as failed `language-composition` evidence; never infer architectural approval.\n\n\u003C\u002Fstep>\n\n\u003Cstep name=\"verdict\">\n\n**Step 4: Issue verdict**\n\nScan all findings across all assertions, including any folded in from the composed language audit; any REJECT finding makes the verdict **REJECTED**.\n\nBefore row rollup, inspect every finding as a complete record. Require every finding field from `\u003Cverdict_format>`, including `remediation_target`, and derive that target from the semantic owner named by the evidence model. Complete a missing field before adding the finding to a row; never emit a partial finding and rely on its message to imply the omitted field.\n\n\u003C\u002Fstep>\n\n\u003C\u002Faudit_workflow>\n\n\u003Cverdict_format>\n\nThe `NOT_APPLICABLE` result defined in Step 3f is the alternate output when no evidence is applicable; it contains only `status`, `subjects`, and `explanation`, and the gate-verdict schema below does not apply. Every gate verdict includes `metadata.branch`: the output of `git branch --show-current`, an empty string for a detached HEAD, or JSON `null` when unavailable.\n\nEmit the verdict as a single JSON object. This JSON is the skill's entire output; never emit a prose or markdown verdict.\n\nThe skill's `overall` is `APPROVED` iff every applicable gate row is `PASS`; otherwise it is `REJECTED`. A required gate that cannot be evaluated is a `FAIL` row with a `REJECT` finding naming the missing evidence. Findings within each row carry severity `REJECT` for blocking findings (these are what flip a row to `FAIL`), `FILED` for a finding outside touched text, which fails no row and additionally carries `key`, `baseRefEvidence`, and `issuesEntry` (`path`, `heading`), and `WARNING` or `INFO` for non-blocking observations. Every finding MUST include every field shown in its row schema: `id`, `file`, `locations`, `property`, `rule`, `severity`, `message`, and `remediation_target`; omission of any field is an invalid verdict. A finding is keyed `\u003Cfile>:\u003Crule-id>`, where `file` is the repository-relative path of the artifact that holds the defect, or `input` when the request carries no target, and `\u003Crule-id>` comes from `${CLAUDE_SKILL_DIR}\u002Freferences\u002Frule-catalog.md`. One key covers every location in that file where the rule is violated, and `locations` lists each as the assertion, full text or stable id, joined to the declaration or call that violates the rule, named by its text and never by a line number. A `\u003Crule-id>` outside that catalog and the catalogs of the composed language skills is never emitted.\n\nThe `metadata.evidence_chain` array MUST project the complete inspected inventory. Preserve every applicable discovery artifact even when it carries no finding. The `metadata.coverage_traces` array projects Step 3e: a language-specific concern includes traces for the coverage it judges and leaves the array empty only when coverage is outside its declared scope; this audit's merged verdict MUST carry one entry per audited assertion, naming the assertion-relevant source path, the test path followed into it, and the coverage judgment. Use `saturated` only for a trivially total path reached by the test. The `metadata.not_applicable` array holds one entry per language that returned `NOT_APPLICABLE`, and stays empty otherwise.\n\n```json\n{\n  \"schema_version\": 1,\n  \"skill\": \"audit-tests\",\n  \"target\": \"\u003Cspec-node-path>\",\n  \"overall\": \"APPROVED | REJECTED\",\n  \"rows\": [\n    {\n      \"name\": \"gate-1-assertion\",\n      \"status\": \"PASS | FAIL\",\n      \"findings\": [\n        {\n          \"id\": \"f-002\",\n          \"file\": \"\u003Ctest-file>\",\n          \"locations\": [\"\u003Cfull-assertion-text-or-stable-id>: \u003Cdeclaration-or-call-text>\"],\n          \"property\": \"\u003Ctestability | evidence-chain-completeness | declarations | predicate-ownership | source-ownership | oracle-independence | coupling | falsifiability | alignment | coverage | language-composition | unsupported-language>\",\n          \"rule\": \"\u003Crule-id from references\u002Frule-catalog.md>\",\n          \"severity\": \"REJECT | FILED | WARNING | INFO\",\n          \"message\": \"\u003Cone-line evidentiary gap>\",\n          \"remediation_target\": \"\u003Csource-contract | harness | generator | fixture | eval-case | test-file | source-file | test-infrastructure | independent-oracle | skill-installation | language-partition>\"\n        }\n      ]\n    },\n    {\n      \"name\": \"gate-2-architectural\",\n      \"status\": \"PASS | FAIL\",\n      \"findings\": [\n        {\n          \"id\": \"f-003\",\n          \"file\": \"\u003Ctest-file>\",\n          \"locations\": [\"\u003Cfull-assertion-text-or-stable-id | cross-assertion>: \u003Cduplicated-declaration-text>\"],\n          \"property\": \"architectural-duplication\",\n          \"rule\": \"\u003Crule-id from the composed language skill's rule catalog>\",\n          \"severity\": \"REJECT | FILED | WARNING | INFO\",\n          \"message\": \"\u003Cextraction target>: \u003Cnearest common test-infrastructure location>\",\n          \"remediation_target\": \"\u003Csource-contract | harness | generator | fixture | eval-case | test-file | source-file | test-infrastructure | independent-oracle | skill-installation | language-partition>\"\n        }\n      ]\n    }\n  ],\n  \"metadata\": {\n    \"branch\": null,\n    \"evidence_chain\": [\n      {\n        \"path\": \"\u003Crepository-relative-path>\",\n        \"role\": \"test | harness | generator | fixture | discovery | production\",\n        \"imported_from\": \"\u003Crepository-relative-path-or-null>\",\n        \"inspection_status\": \"inspected | unresolved\"\n      }\n    ],\n    \"coverage_traces\": [\n      {\n        \"assertion\": \"\u003Cfull-assertion-text-or-stable-id>\",\n        \"source_path\": \"\u003Crepository-relative-assertion-relevant-path>\",\n        \"test_path\": \"\u003Crepository-relative-test-path-and-call-chain>\",\n        \"judgment\": \"reaches | saturated | missing\"\n      }\n    ],\n    \"not_applicable\": [{ \"language\": \"\u003Clanguage>\", \"subjects\": [\"\u003Crepository-relative-path>\"], \"explanation\": \"\u003Creason>\" }]\n  }\n}\n```\n\nA non-applicable Gate 2 row is omitted. A required gate that cannot be evaluated uses `status: \"FAIL\"` with a `REJECT` finding naming the missing evidence. A `source-ownership` finding uses `property: \"source-ownership\"`, `rule: \"source-ownership\"`, and `remediation_target: \"source-contract\"`; other findings select the failed property, the catalogued rule, and the owner that must change from the enumerated values. This verdict schema contains no `gate-0-deterministic` row.\n\n\u003C\u002Fverdict_format>\n\n\u003Cfailure_modes>\n\n**Failure 1: Accepted a tautological test file**\n\nClaude approved a test file that imported only vitest. It declared OKLCH color constants and verified they satisfied contrast thresholds — pure math with zero connection to any CSS file, theme, or component. The tests pass if the entire codebase is deleted. Claude was distracted by clean types, good structure, and comprehensive scenarios, and never checked the imports.\n\nHow to avoid: Step 3b checks imports before the other evidence properties. Zero codebase imports = instant REJECT.\n\n**Failure 2: Accepted mocking as legitimate coupling**\n\nClaude saw `import { database } from \"..\u002Fsrc\u002Fdatabase\"` and classified it as direct coupling. The next line was `vi.mock(\"..\u002Fsrc\u002Fdatabase\")`. The real module never ran.\n\nHow to avoid: Step 3c checks for mocking after confirming coupling. Import + mock = coupling severed.\n\n**Failure 3: Re-ran the project's coverage command inside the audit**\n\nClaude ran the project's coverage command three times (baseline, with-test, isolated) to measure a delta. Those runs added no audit evidence and repeated work excluded by `\u003Cconstraints>`.\n\nHow to avoid: Step 3e traces coverage by reading whether the test drives execution into the assertion-relevant path. Name the path from the code; never run the coverage or test command, and never substitute an unbacked \"probably covers\" for the trace.\n\n**Failure 4: Distracted by code quality signals**\n\nClaude spent the entire audit checking for `as any`, verifying return types, and searching for skip patterns. The test had perfect TypeScript quality and zero evidentiary value. Quality signals are linting concerns, not audit concerns.\n\nHow to avoid: Follow the complete ordered audit sequence: inventory the evidence chain, check source testability, screen test-owned declarations, then judge coupling, falsifiability, alignment, and coverage.\n\n**Failure 5: Approved a prose-body substring test as direct coupling**\n\nClaude audited a test that read an authored skill body and asserted that policy substrings were present, and rated coupling PASS — \"direct coupling to the artifact; the text is the thing under test\" — and falsifiability PASS — \"removing the clause from the skill body breaks the test.\" The test exercises no code; only an edit to the authored prose falsifies it, so it carries no behavioral evidence, yet the four-property model rationalized it as conformance.\n\nHow to avoid: Step 3b — after identifying what a test reads, classify by whether the subject is executable behavior or authored prose\u002Fdocumentation, not by whether the path resolves to a repository file. A read of an authored prose or documentation body asserted for its content is prose-coupling → REJECT, however the path is resolved and whatever harness mediates the read.\n\n**Failure 6: Accepted renamed test-local configuration**\n\nClaude saw a validation warning for a SCREAMING_CASE test constant used as a property-test run count, renamed it to camelCase, and approved the audit because the validator stopped flagging it. The value was still runner configuration in the executed test file. The rename only evaded a heuristic.\n\nHow to avoid: Step 3a reads declarations before coupling and classifies ownership. Runner counts, seeds, replay policy, setup choices, boundary bags, expected outputs, fixture paths, and generated domains belong in harnesses, generators, source contracts, inert fixtures, or eval cases — never in the test file under a different name.\n\n**Failure 7: Approved a thin test without auditing its harness**\n\nClaude inspected a linked Python test that imported a harness, then reviewed only three repeated `file.txt` values in the harness and approved them as harness-owned synthetic vocabulary. The harness also declared SPX payload keys, command tokens, producer identities, status values, and expected projection fields. The verdict omitted the imported-artifact inventory and never classified most values.\n\nHow to avoid: Step 2b inventories and reads the complete evidence chain before judgment. Step 3a names the source of every protocol value and rejects harness-declared domain truth with `source-ownership`. Approval requires the inventory in verdict metadata.\n\n**Failure 8: Rejected observation and resource bindings by syntax**\n\nClaude rejected a temporary-directory fixture parameter and a local `observations` binding even though both only received values selected by their owning infrastructure. The proposed remediation moved those handles into the harness, obscuring assertion flow without changing any semantic owner.\n\nHow to avoid: Step 3a classifies each binding by the semantic-binding rule of `\u002Ftest-evidence-standards`, never by its syntax.\n\n**Failure 9: Used the defect location as the remediation owner**\n\nClaude correctly found copied protocol fields in a harness and emitted `source-ownership`, then set `remediation_target` to `harness` because that file contained the defect. The verdict failed its structural contract: copied domain truth belongs to a source contract regardless of where the copy appears.\n\nHow to avoid: Keep location and ownership separate. Set `file` to the artifact containing the copy and set every `source-ownership` finding's `remediation_target` to `source-contract`.\n\n**Failure 10: Omitted a language manifest from the evidence chain**\n\nClaude inspected a Rust test, harness, generator, and production module, then omitted the package's `Cargo.toml` from `metadata.evidence_chain` because it carried no finding. The manifest established package and test discovery, so the verdict's inventory was incomplete.\n\nHow to avoid: Inventory applicable discovery and module-resolution artifacts even when they produce no finding. This includes pytest and Vitest configuration, Cargo manifests, and Go module files when they establish the test boundary.\n\n**Failure 11: Emitted a semantically correct but structurally incomplete finding**\n\nClaude rejected a production-derived oracle with the correct assertion, property, rule, artifact, and evidence chain, then omitted `remediation_target` from the finding. The prose diagnosis named the need for an independent oracle, but prose cannot substitute for a required verdict field and the structured verdict was invalid.\n\nHow to avoid: Construct each finding atomically from the canonical finding schema before row rollup, derive `remediation_target` from the evidence model, and perform the Step 4 completeness check before emitting the verdict.\n\n**Failure 12: Read an absent in-repository caller as proof of laundering**\n\nClaude rejected a package's `__version__` as source-ownership laundering because no module in the checkout consumed it. The packaging manifest declares it as published API, a surface the audit never opened, so a real contract was reported as a test-only address.\n\nHow to avoid: Judge ownership by the contract outside the test tree, and read the checkout's declared surfaces — packaging entry points and export declarations, plugin and protocol implementations, registry and reflective lookups, generated use, and declared schemas — before reporting a symbol as laundered.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\nThe verdict is sound when:\n\n- Every in-scope assertion and required language concern has a gate determination, with no evidence partition left unevaluated.\n- Every imported evidence artifact appears in verdict metadata with its role, import origin, and inspection status; approval contains only inspected entries.\n- Every protocol and domain value resolves to its production or platform owner; generated variable data resolves to a generator, inert whole payloads to fixtures, setup policy to harnesses, and curated examples to eval cases.\n- The overall APPROVED\u002FREJECTED value agrees with every applicable gate row.\n- Every REJECT finding lies on touched text, carries the complete canonical schema, and names a falsifiable evidentiary gap against the affected assertion and artifact; every finding outside touched text appears as `FILED` with its key, `baseRefEvidence`, and `issuesEntry`.\n- Every coverage determination identifies the assertion-relevant source path reached or omitted, and the same evidence yields the same verdict.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":44,"argument-hint":45},"Read, Grep, Glob, {{! tool('use_skill') !}}, Bash(git diff:*), Bash(git merge-base:*), Bash(git branch --show-current:*)","\u003Cspec-node-path-or-evidence-scope>","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-tests","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":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add outcomeeng\u002Fplugins --skill audit-tests",{"tool":60,"command":61},"bunx","bunx skills add outcomeeng\u002Fplugins --skill audit-tests",{"tool":63,"command":64},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill audit-tests","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-tests\u002FSKILL.md",true,[68,74],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Frule-catalog.md","REFERENCE","参考文档",9830,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-tests\u002Freferences\u002Frule-catalog.md",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Ftouched-text.md",4129,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fproduct-tree\u002Fskills\u002Faudit-tests\u002Freferences\u002Ftouched-text.md",[79,85,122,138,154,167],{"skillNo":80,"name":81,"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":82,"categories":83,"keywords":84,"publishedAt":39},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[81],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":101,"publishedAt":39},"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",[91,96],{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","never","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master","invoke","when",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":39},"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",[],[129,130,131,132,133,109,120,134,135,121,136,137],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":147,"publishedAt":39},"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",[144],{"categoryNo":145,"categoryName":146,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000008","测试与质量",[148,149,30,150,151,152,153],"typescript","typescript test standards","standards","false","read","across",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":163,"publishedAt":39},"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",[160],{"categoryNo":161,"categoryName":162,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000030","开发工程师",[148,164,165,166,150,151,152,153],"code","typescript code standards","code standards",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":39},"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",[],[174,150,175,176,148,177,178,153,152,179,151,180],"architecture standards","typescript architecture standards","architecture","adr","architect","auditor","conventions"]