[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C4869BXD41Y4HEVSMSJQDW":3,"skill-same:01M6C4869BXD41Y4HEVSMSJQDW":127},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M6C4869BXD41Y4HEVSMSJQDW","test-driven-development",null,"Test-Driven Development workflow guidance, quality standards, and practical patterns. Use when writing tests first, implementing to pass tests, validating quality gates, or refactoring safely; also when placing a hazardous or non-returning test file, when changing CI suite selection or a dot-sourced runner library, when a suite passes locally and fails only on CI, when claiming a rule is covered by the surrounding tests, when writing a test docstring that names a cross-surface invariant, and when writing a test that fabricates hostile input. DO NOT USE FOR: debugging existing failures (use systematic-debugging), React component test patterns (use ui-testing), E2E browser tests (use webapp-testing), randomized property verification (use property-based-testing), or architecture evaluation and design decisions (use software-architecture)","Grimblaz\u002Fagent-orchestra","Grimblaz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F74755849?v=4","01M6C430M9XZDHGHPWQVTQ3KMA","01M6C430RJY3MMX0QAZ3X8DR3Y",3,"MIT","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"test","test driven development","development","webapp","testing","only","dot","refactoring","Evaluation","ci","verification","browser","component test","debugging","architecture","component","react","workflow","writing","design","2026-11-10 10:12:30",false,"---\nname: test-driven-development\ndescription: \"Test-Driven Development workflow guidance, quality standards, and practical patterns. Use when writing tests first, implementing to pass tests, validating quality gates, or refactoring safely; also when placing a hazardous or non-returning test file, when changing CI suite selection or a dot-sourced runner library, when a suite passes locally and fails only on CI, when claiming a rule is covered by the surrounding tests, when writing a test docstring that names a cross-surface invariant, and when writing a test that fabricates hostile input. DO NOT USE FOR: debugging existing failures (use systematic-debugging), React component test patterns (use ui-testing), E2E browser tests (use webapp-testing), randomized property verification (use property-based-testing), or architecture evaluation and design decisions (use software-architecture)\"\n---\n\n\u003C!-- platform-assumptions: markdown skill guidance for VS Code custom agents in Agent Orchestra; assumes tests are authored against repo-defined commands, architecture rules, and quality thresholds. -->\n\u003C!-- markdownlint-disable-file MD041 MD003 MD033 -->\n\n# Test-Driven Development Skill\n\n## Overview\n\nThis skill module provides comprehensive TDD workflow guidance, including the RED-GREEN-REFACTOR cycle, quality gates, test patterns, and anti-patterns to avoid.\n\n> **[CUSTOMIZE]** Examples may use a sample stack. Adapt commands and tooling for your project while preserving the same TDD principles.\n\n## Iron Law of TDD\n\n> A behavior is not done until a failing test proves the need, passing tests prove correctness, and refactoring preserves green tests.\n\n\u003Cessential_principles>\n\n## TDD Cycle: RED → GREEN → REFACTOR\n\n1. **RED**: Write a failing test that describes the expected behavior\n2. **GREEN**: Implement the minimum code to make the test pass\n3. **REFACTOR**: Improve code quality while keeping tests green\n\n## Quality Hierarchy\n\nQuality gates are enforced in priority order:\n\n| Priority     | Gate             | Tool                      | Threshold | Enforcement     |\n| ------------ | ---------------- | ------------------------- | --------- | --------------- |\n| ? PRIMARY   | Mutation Testing | [CUSTOMIZE] Mutation tool | ≥80%      | Blocks merge    |\n| ? SECONDARY | Code Coverage    | [CUSTOMIZE] Coverage tool | ≥80%      | Blocks merge    |\n| ? BASELINE  | Tests Pass       | [CUSTOMIZE] Test runner   | 100%      | Always required |\n\n**Why this order?**\n\n- Code coverage can be 100% with weak assertions (tests run but don't verify)\n- Mutation testing validates that tests actually catch bugs\n- Both together ensure comprehensive, high-quality test suites\n\n## Core Testing Principles\n\n- **Test behavior, not implementation**: Test what code should do, not how it does it\n- **No reflection hacks**: Don't test private methods via reflection\n- **Test rules, not formulas**: \"higher values produce larger results\" not exact arithmetic\n- **Keep test files focused**: Split by behavior if tests become unwieldy\n\n## Behavior Quality Standards\n\n- Use business-language test names that describe expected outcomes, not method names or internal branches\n- Prefer one observable behavior per test with a clear Arrange-Act-Assert structure\n- Cover realistic edge cases and requirement boundaries, not speculative permutations\n- Use parameterized tests for data tables, formulas, or repeated rule checks that differ only by inputs and outcomes\n- Treat every added test as a requirement statement; avoid \"vibe coding\" assertions that do not map to a concrete behavior\n\n## Integration-First Test Strategy\n\nPrefer the narrowest test that still exercises the real behavior, but bias toward integration tests when meaningful behavior depends on collaboration between adjacent components or layers.\n\n- Mock or stub at explicit layer boundaries, not deep inside a layer's own internals\n- Exercise adjacent layers together when the architecture permits it, so wiring failures are caught where they matter\n- Verify production code paths directly in integration tests; do not simulate the system with custom test helpers that bypass the real integration\n- If a test could pass while the production wiring is missing, it is too synthetic for the intended confidence level\n\n### Critical Integration Rule\n\nIntegration tests must call actual production code paths, not helper functions that manually recreate the expected side effects.\n\n**Wrong**: A helper mutates state directly and the test asserts on that fake state.\n\n**Right**: The test invokes the real pipeline, service, controller, or workflow that is responsible for the state change.\n\nWhy this matters: helper-driven tests can stay green even when the real system is not wired in.\n\nExample anti-pattern:\n\n```typescript\nfunction markAsProcessed(record: WorkItem): void {\n  record.status = \"processed\";\n}\n```\n\nPreferred shape:\n\n```typescript\nconst processor = new ProcessingPipeline(...);\nprocessor.execute(record, context);\nexpect(record.status).toBe(\"processed\");\n```\n\nWhy this matters: a helper-driven integration test can stay green even when the real production wiring is missing.\n\n### Producer-Shape Fidelity\n\nA fixture for a function whose input comes from a _named upstream producer_ (a parser, converter, deserializer, or dot-sourced library call) must use the producer's actual runtime type, verified by reading the producer — not whichever type is easiest to construct in the test language.\n\n**Trap**: a `[pscustomobject]` fixture can make a `.PSObject.Properties.Match(...)` check pass while the real shape (`[hashtable]`, e.g. from a YAML\u002FJSON parser) makes the same check silently no-op in production.\n\nThis is _type_ fidelity — distinct from the path-wiring fidelity above and the cardinality fidelity in Collection \u002F Iteration Coverage below. Mutation testing cannot catch it: mutations only prove tests catch changes within the fixture's own shape.\n\n## Quality Gates In Practice\n\n- Run the repository's configured test command for fast red-green feedback\n- Use the repository's configured coverage threshold for the domain under test\n- Use mutation testing to evaluate assertion strength when the project supports it\n- Prefer incremental mutation runs during development and broader validation in CI or completion gates\n- Report coverage and mutation results as evidence, not as substitutes for behavior-focused assertions\n\n## Refactor Safely\n\n- Refactor only after the current behavior is proven green\n- Remove duplication in tests as long as the behavior remains easy to read\n- Keep factories and helpers subordinate to readability; do not hide the behavior under heavy indirection\n- When a refactor changes test setup shape, confirm the assertions still describe user-visible or domain-visible behavior\n\n## Collection \u002F Iteration Coverage\n\nFor any function that iterates a persisted collection (`getAll()` or\n`for...of` across repository results), the test plan **must** include at\nleast one 2-record scenario that verifies the loop applies semantics to\nall members, not only the first or primary record.\n\n- **Single-record fixtures** confirm field-level semantics.\n- **Multi-record fixtures** confirm loop-level correctness.\n\n\u003C\u002Fessential_principles>\n\n\u003Cintake>\n\n## What do you need help with?\n\n**TDD Phase:**\n\n1. **write** - Writing tests first (RED phase)\n2. **implement** - Making tests pass (GREEN phase)\n3. **validate** - Running quality gates (coverage + mutation)\n4. **refactor** - Improving code while keeping tests green (REFACTOR phase)\n5. **lookup** - Reference information (patterns, commands, anti-patterns)\n\n**What phase are you in?** _(write\u002Fimplement\u002Fvalidate\u002Frefactor\u002Flookup)_\n\n\u003C\u002Fintake>\n\n\u003Crouting>\n\n## Response Routing\n\n| Response             | Workflow\u002FReference             | Description                                                                     |\n| -------------------- | ------------------------------ | ------------------------------------------------------------------------------- |\n| write                | workflows\u002Fwrite-tests-first.md | RED phase - write failing tests                                                 |\n| implement            | workflows\u002Fmake-tests-pass.md   | GREEN phase - implement code                                                    |\n| validate             | workflows\u002Fvalidate-coverage.md | Run quality gates                                                               |\n| refactor             | workflows\u002Frefactor-safely.md   | REFACTOR phase - improve code                                                   |\n| lookup patterns      | references\u002Ftest-patterns.md    | AAA, parameterized tests, factories                                             |\n| lookup commands      | references\u002Fcommands.md         | Test commands reference                                                         |\n| lookup gates         | references\u002Fquality-gates.md    | Thresholds and enforcement                                                      |\n| lookup anti-patterns | ## Gotchas (below)             | Summary of what to avoid; see references\u002Fanti-patterns.md for detailed examples |\n\n\u003C\u002Frouting>\n\n\u003Creference_index>\n\n## Composite References\n\n- [references\u002Fanti-patterns.md](references\u002Fanti-patterns.md): test anti-patterns and what to write instead\n- [references\u002Fcommands.md](references\u002Fcommands.md): per-stack test invocation commands\n- [references\u002Fquality-gates.md](references\u002Fquality-gates.md): the quality-gate tiers and what each one asserts\n- [references\u002Ftest-patterns.md](references\u002Ftest-patterns.md): reusable test shapes for the common cases\n- [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md): the incident detail behind § Test-Authoring Lenses — the placements, leaks, false greens and undefended rules each lens was extracted from\n\n## Reference Files\n\n### Workflows\n\n- `workflows\u002Fwrite-tests-first.md` - RED phase workflow\n- `workflows\u002Fmake-tests-pass.md` - GREEN phase workflow\n- `workflows\u002Fvalidate-coverage.md` - Quality gate validation\n- `workflows\u002Frefactor-safely.md` - REFACTOR phase workflow\n\n### References\n\n> Note: ## Composite References above is the complete list for this directory and is what the promotion check reads. This older grouping is kept for its per-file commentary and does not include `references\u002Ftest-authoring-exhibits.md`.\n\n- `references\u002Fquality-gates.md` - Mutation and coverage thresholds\n- `references\u002Ftest-patterns.md` - AAA pattern, parameterized tests, factories\n- `references\u002Fanti-patterns.md` - Common anti-patterns to avoid\n- `references\u002Fcommands.md` - Test and validation commands\n\n### Templates\n\n- `templates\u002Ftest-file.md` - New test file structure\n- `templates\u002Fdescribe-block.md` - Behavior-organized test structure\n\n\u003C\u002Freference_index>\n\n## Quick Reference\n\n```bash\n# [CUSTOMIZE] Replace with your project's test commands\n\n# Run tests\n.\u002Fgradlew test\n\n# Run with coverage (JaCoCo)\n.\u002Fgradlew test jacocoTestReport\n\n# Run mutation testing (PIT)\n.\u002Fgradlew pitest\n```\n\n## Test-Authoring Lenses\n\n> **Authoritative source**: which lessons are promoted here, what anchor each one lives at, and the trigger text that has to reach a reader are recorded in `Documents\u002FPlanning\u002Flesson-promotion-manifest.json`. `.github\u002Fscripts\u002FTests\u002Flesson-promotion-manifest.Tests.ps1` is what stops this section and that manifest drifting apart, and it is the suite a red comes from. **Renaming a heading below is a migration, not a regression** — update that lesson's `anchor` in the manifest in the same commit as the rename. A red naming an anchor you just renamed is reporting a manifest row left behind, not a lost lens.\n\nSix ways a suite is green about the wrong thing. Incident detail sits in [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md), cited per lens.\n\n### When you are placing a test file, changing CI selection, or judging whether a rule is defended\n\n#### Blast radius comes from what executes a path, not from what selects from it\n\nBefore placing anything hazardous — a deliberately non-returning control suite, a fixture that must never be collected — **grep for what runs that path, not for what filters it**. A selector and an executor are different things, and safety is a property of the executors. Checking every selector in the repository and finding them all non-recursive and all agreeing on a file count reads as safety while the consumers that would actually hang were never in the searched set: directory-level test invocations, the commands documented in contributor instructions and pull-request templates, baseline-capture helpers. Pester's directory discovery is **recursive**, so a subdirectory placement that the non-recursive gate glob never yields still lands inside the loop every contributor runs before opening a pull request, on a machine with no job ceiling to stop it. And a quarantine entry cannot rescue it: **the registry binds the gate's _selection_, not a raw directory run**, so an entry protects CI and leaves every human exposed. Only outside the tests root is actually safe; the convention that has kept this from biting is that fixtures under that root do not carry the suite suffix. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § A \"safe\" placement inside the pre-PR command.\n\n#### CI selects suites by glob minus the quarantine registry, and a file-scope StrictMode in a dot-sourced library reddens the whole run\n\nSuite selection here is a **glob minus `.github\u002Fscripts\u002FTests\u002Fci-quarantine.json`**, not an allowlist — there is nothing to forget to update, and skipping a suite means adding an entry with a `class` and a `reason`. Keep the classes distinct: never-measured backlog, measured-failing (which requires an issue number, because a temporary exclusion with no ticket is a permanent one that has not admitted it), and structurally-cannot-run. Collapsing them is how a registry becomes a graveyard nobody reads. The trap that ships alongside: **a file-scope `Set-StrictMode` in a library the workflow dot-sources leaks into the entire Pester run**, because the workflow dot-sources and then invokes in the same session — so strictness applies to every suite executed afterwards and reddens subsystems the change never touched. A library dot-sourced by a _runner_ sets strictness **inside its functions**; file scope is only safe for libraries dot-sourced inside a `BeforeAll`, where the blast radius is one file. The verification method worth reusing for any of this: **do not approximate a workflow locally — extract its own `run:` block from the YAML and execute those exact bytes** in a fresh process, swapping the exit-on-failure setting for pass-through. A hand-rolled approximation dot-sources in a different order and misses exactly this class. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § A StrictMode leak that reddened 218 untouched tests.\n\n#### For a CI-only failure, dump the whole decision state in one run\n\nOne hypothesis per round-trip is the slow, wrong method: each narrow assertion comes back clean and kills its hypothesis without pointing anywhere. Push a temporary block that dumps **everything the decision reads plus the product's own output**, unconditionally, written so it lands in the log whether or not the assertion fails. Capture, roughly in value order: the product's own log lines (usually decisive — the executor naming which branch it took ends the search instantly); every probe's exit code _and_ its stdout, not just the boolean you derive from it; the identity facts side by side (the SHAs and refs the decision compares); tool versions and relevant configuration; and whether the mocks were reached at all, since an empty call log is a loud signal. Two traps this method catches: **a shim that only works on one platform makes tests pass for the wrong reason** — every fixture expecting a decline still passes when the tool is simply unavailable, so assert the mock was actually invoked; and a cherry-pick can reproduce a source commit's exact SHA when tree, parent, message, author and committer-second all match, so the branch has zero unique commits and the test silently exercises another path. General rule: a test depending on an unasserted precondition reports the _downstream_ symptom — pin the precondition and the failure names itself. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § Three CI round-trips against one dump.\n\n#### A rule you cannot invoke cannot be defended, however many tests surround it\n\nIf a rule lives inline — a `Where-Object` block, a condition inside a long function — and the only path reaching it runs behind a worker-runspace boundary, a fail-open `catch`, or a guard with conjuncts you cannot satisfy hermetically, then **no test can drive it**: reverting the rule leaves the whole repository green. That is not \"covered by the surrounding tests\", it is undefended, and prose saying it \"moved in lockstep\" reads as defended. **Before claiming a rule is defended, revert it in a scratch tree and run everything — per rule, not per file.** A rule with no reachable red state gets one of exactly two things: **extraction into a named, callable unit** the real code path then calls, or an explicit written record that it ships undefended. The bigger harness is not the fix; testability is a design property of where you put the rule, not of how many tests you wrote. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § A reverted rule that left 23 tests green.\n\n#### A test docstring can name a check the body never performs\n\nWhen a docstring names a cross-surface invariant, check the body actually **reads both surfaces**. A test that enumerates a constant it also authored is self-consistent by construction and can never fail for the reason its documentation gives — and the unwritten check is usually exactly what would have caught the defect sitting next to it, so the overclaim and the gap are one hole seen from two sides. Read the canonical source at runtime instead of typing out a hashtable. The corollary that rides along: an **absence-assertion set is only as good as its enumeration** — pinning that three moved sections are gone while silently omitting a fourth means a re-addition passes everything. And always run the negative control: after fixing, restore the pre-fix file and confirm the new tests actually fail against it; a test that passes both before and after is correctly identified as covering already-working behaviour, not as evidence. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § A docstring that named a check the body never ran.\n\n#### A test that fabricates hostile input can corrupt the aggregate artifact it protects\n\nWhen the property under test is a property of the **whole run's output**, a test that fabricates an adversarial input can satisfy itself and break that property at the same time — unit-level green says nothing, and only the aggregate re-run shows it. Before writing such a test, ask: _does this test run inside the artifact whose aggregate property I am protecting?_ If yes, resolve the adversarial cases through the **pure helper** so nothing is emitted, and keep only end-to-end cases whose output is indistinguishable from a legitimate participant. Watch the harness too, not just your code: a runner that echoes the path of every file it executes will inject a record-shaped string into the same log from a **fixture directory name**, which is the reading hazard the criterion existed to remove, emitted from a line the code never wrote. And check the aggregate rather than the unit — where a criterion is stated over a whole run, the verification has to be a whole run. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § A test that stamped six false records into its own run.\n\n## Gotchas\n\n| Trigger                                                                | Gotcha                                                                               | Fix                                                                              |\n| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- |\n| Testing a private method via reflection (`setAccessible(true)`)        | Couples test to implementation; breaks on rename or visibility change                | Test through the public interface that exercises the private logic               |\n| Asserting `verify(repo, times(1)).findById(...)` instead of the result | Breaks on caching, batching, or any refactor — tests the mechanism, not the behavior | Assert on the returned result or observable side effect, not how it was obtained |\n| Testing null\u002Fempty inputs that can never occur in the system           | Bloats test suite; encourages defensive code that hides real bugs                    | Test realistic input ranges only; match edge cases to actual system boundaries   |\n| `assertThat(health).isEqualTo(150)` with an exact formula match        | Breaks on any formula tweak; encodes the implementation, not the business rule       | Test comparative invariant (`highVit.health > lowVit.health`) not exact values   |\n| 100% line coverage with assertions that don't verify correctness       | Coverage is green; mutations survive                                                 | Run mutation testing; require ≥80% score; review asserts on each changed line    |\n| Organizing tests as one method per production method                   | Misses behavior variations and error cases; becomes a checklist                      | Organize by scenario\u002Fbehavior with descriptive names; use `@Nested` groups       |\n\n| Trigger                                                    | Gotcha                                                         | Fix                                                                |\n| ---------------------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------ |\n| An integration test uses a helper that sets state directly | The test never proves the real production path or wiring works | Invoke the real service, pipeline, handler, or workflow under test |\n\n| Trigger                                           | Gotcha                                                                | Fix                                                                        |\n| ------------------------------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------- |\n| Mocking inside a layer instead of at its boundary | Tests become implementation-aware and break during harmless refactors | Stub only the external seam and let the layer's internal collaborators run |\n\nFor detailed examples of each anti-pattern, see `references\u002Fanti-patterns.md`.\n\n## Frame Ports Filled By This Skill\n\n| Port | Work adapter | Auto-N\u002FA adapter | Explicit-skip adapter |\n| --- | --- | --- | --- |\n| `implement-test` | [agents\u002FTest-Writer.agent.md](..\u002F..\u002Fagents\u002FTest-Writer.agent.md); [adapters\u002Fimplement-test-adapter.md](adapters\u002Fimplement-test-adapter.md) | [adapters\u002Fimplement-test-auto-na-adapter.md](adapters\u002Fimplement-test-auto-na-adapter.md) | [adapters\u002Fimplement-test-explicit-skip-adapter.md](adapters\u002Fimplement-test-explicit-skip-adapter.md) |\n\nIn `\u002Fspine-run`, the `implement-test` port resolves through [adapters\u002Fimplement-test-adapter.md](adapters\u002Fimplement-test-adapter.md) as the work adapter executed by Senior Engineer. Hub-flow dispatch uses `agents\u002FTest-Writer.agent.md` directly. This split-declaration state is documented in [Documents\u002FDesign\u002Fframe-architecture.md](..\u002F..\u002FDocuments\u002FDesign\u002Fframe-architecture.md); see footnote ‡ (split-declaration #612).\n\n## Cross-platform path conventions\n\nWhen authoring tests that reference filesystem paths via `Join-Path`, use forward\nslashes in child-path arguments. See `.github\u002Farchitecture-rules.md §Validation`\nfor the authoritative convention and enforcement gate.\n","\u003C!-- platform-assumptions: markdown skill guidance for VS Code custom agents in Agent Orchestra; assumes tests are authored against repo-defined commands, architecture rules, and quality thresholds. -->\n\u003C!-- markdownlint-disable-file MD041 MD003 MD033 -->\n\n# Test-Driven Development Skill\n\n## Overview\n\nThis skill module provides comprehensive TDD workflow guidance, including the RED-GREEN-REFACTOR cycle, quality gates, test patterns, and anti-patterns to avoid.\n\n> **[CUSTOMIZE]** Examples may use a sample stack. Adapt commands and tooling for your project while preserving the same TDD principles.\n\n## Iron Law of TDD\n\n> A behavior is not done until a failing test proves the need, passing tests prove correctness, and refactoring preserves green tests.\n\n\u003Cessential_principles>\n\n## TDD Cycle: RED → GREEN → REFACTOR\n\n1. **RED**: Write a failing test that describes the expected behavior\n2. **GREEN**: Implement the minimum code to make the test pass\n3. **REFACTOR**: Improve code quality while keeping tests green\n\n## Quality Hierarchy\n\nQuality gates are enforced in priority order:\n\n| Priority     | Gate             | Tool                      | Threshold | Enforcement     |\n| ------------ | ---------------- | ------------------------- | --------- | --------------- |\n| ? PRIMARY   | Mutation Testing | [CUSTOMIZE] Mutation tool | ≥80%      | Blocks merge    |\n| ? SECONDARY | Code Coverage    | [CUSTOMIZE] Coverage tool | ≥80%      | Blocks merge    |\n| ? BASELINE  | Tests Pass       | [CUSTOMIZE] Test runner   | 100%      | Always required |\n\n**Why this order?**\n\n- Code coverage can be 100% with weak assertions (tests run but don't verify)\n- Mutation testing validates that tests actually catch bugs\n- Both together ensure comprehensive, high-quality test suites\n\n## Core Testing Principles\n\n- **Test behavior, not implementation**: Test what code should do, not how it does it\n- **No reflection hacks**: Don't test private methods via reflection\n- **Test rules, not formulas**: \"higher values produce larger results\" not exact arithmetic\n- **Keep test files focused**: Split by behavior if tests become unwieldy\n\n## Behavior Quality Standards\n\n- Use business-language test names that describe expected outcomes, not method names or internal branches\n- Prefer one observable behavior per test with a clear Arrange-Act-Assert structure\n- Cover realistic edge cases and requirement boundaries, not speculative permutations\n- Use parameterized tests for data tables, formulas, or repeated rule checks that differ only by inputs and outcomes\n- Treat every added test as a requirement statement; avoid \"vibe coding\" assertions that do not map to a concrete behavior\n\n## Integration-First Test Strategy\n\nPrefer the narrowest test that still exercises the real behavior, but bias toward integration tests when meaningful behavior depends on collaboration between adjacent components or layers.\n\n- Mock or stub at explicit layer boundaries, not deep inside a layer's own internals\n- Exercise adjacent layers together when the architecture permits it, so wiring failures are caught where they matter\n- Verify production code paths directly in integration tests; do not simulate the system with custom test helpers that bypass the real integration\n- If a test could pass while the production wiring is missing, it is too synthetic for the intended confidence level\n\n### Critical Integration Rule\n\nIntegration tests must call actual production code paths, not helper functions that manually recreate the expected side effects.\n\n**Wrong**: A helper mutates state directly and the test asserts on that fake state.\n\n**Right**: The test invokes the real pipeline, service, controller, or workflow that is responsible for the state change.\n\nWhy this matters: helper-driven tests can stay green even when the real system is not wired in.\n\nExample anti-pattern:\n\n```typescript\nfunction markAsProcessed(record: WorkItem): void {\n  record.status = \"processed\";\n}\n```\n\nPreferred shape:\n\n```typescript\nconst processor = new ProcessingPipeline(...);\nprocessor.execute(record, context);\nexpect(record.status).toBe(\"processed\");\n```\n\nWhy this matters: a helper-driven integration test can stay green even when the real production wiring is missing.\n\n### Producer-Shape Fidelity\n\nA fixture for a function whose input comes from a _named upstream producer_ (a parser, converter, deserializer, or dot-sourced library call) must use the producer's actual runtime type, verified by reading the producer — not whichever type is easiest to construct in the test language.\n\n**Trap**: a `[pscustomobject]` fixture can make a `.PSObject.Properties.Match(...)` check pass while the real shape (`[hashtable]`, e.g. from a YAML\u002FJSON parser) makes the same check silently no-op in production.\n\nThis is _type_ fidelity — distinct from the path-wiring fidelity above and the cardinality fidelity in Collection \u002F Iteration Coverage below. Mutation testing cannot catch it: mutations only prove tests catch changes within the fixture's own shape.\n\n## Quality Gates In Practice\n\n- Run the repository's configured test command for fast red-green feedback\n- Use the repository's configured coverage threshold for the domain under test\n- Use mutation testing to evaluate assertion strength when the project supports it\n- Prefer incremental mutation runs during development and broader validation in CI or completion gates\n- Report coverage and mutation results as evidence, not as substitutes for behavior-focused assertions\n\n## Refactor Safely\n\n- Refactor only after the current behavior is proven green\n- Remove duplication in tests as long as the behavior remains easy to read\n- Keep factories and helpers subordinate to readability; do not hide the behavior under heavy indirection\n- When a refactor changes test setup shape, confirm the assertions still describe user-visible or domain-visible behavior\n\n## Collection \u002F Iteration Coverage\n\nFor any function that iterates a persisted collection (`getAll()` or\n`for...of` across repository results), the test plan **must** include at\nleast one 2-record scenario that verifies the loop applies semantics to\nall members, not only the first or primary record.\n\n- **Single-record fixtures** confirm field-level semantics.\n- **Multi-record fixtures** confirm loop-level correctness.\n\n\u003C\u002Fessential_principles>\n\n\u003Cintake>\n\n## What do you need help with?\n\n**TDD Phase:**\n\n1. **write** - Writing tests first (RED phase)\n2. **implement** - Making tests pass (GREEN phase)\n3. **validate** - Running quality gates (coverage + mutation)\n4. **refactor** - Improving code while keeping tests green (REFACTOR phase)\n5. **lookup** - Reference information (patterns, commands, anti-patterns)\n\n**What phase are you in?** _(write\u002Fimplement\u002Fvalidate\u002Frefactor\u002Flookup)_\n\n\u003C\u002Fintake>\n\n\u003Crouting>\n\n## Response Routing\n\n| Response             | Workflow\u002FReference             | Description                                                                     |\n| -------------------- | ------------------------------ | ------------------------------------------------------------------------------- |\n| write                | workflows\u002Fwrite-tests-first.md | RED phase - write failing tests                                                 |\n| implement            | workflows\u002Fmake-tests-pass.md   | GREEN phase - implement code                                                    |\n| validate             | workflows\u002Fvalidate-coverage.md | Run quality gates                                                               |\n| refactor             | workflows\u002Frefactor-safely.md   | REFACTOR phase - improve code                                                   |\n| lookup patterns      | references\u002Ftest-patterns.md    | AAA, parameterized tests, factories                                             |\n| lookup commands      | references\u002Fcommands.md         | Test commands reference                                                         |\n| lookup gates         | references\u002Fquality-gates.md    | Thresholds and enforcement                                                      |\n| lookup anti-patterns | ## Gotchas (below)             | Summary of what to avoid; see references\u002Fanti-patterns.md for detailed examples |\n\n\u003C\u002Frouting>\n\n\u003Creference_index>\n\n## Composite References\n\n- [references\u002Fanti-patterns.md](references\u002Fanti-patterns.md): test anti-patterns and what to write instead\n- [references\u002Fcommands.md](references\u002Fcommands.md): per-stack test invocation commands\n- [references\u002Fquality-gates.md](references\u002Fquality-gates.md): the quality-gate tiers and what each one asserts\n- [references\u002Ftest-patterns.md](references\u002Ftest-patterns.md): reusable test shapes for the common cases\n- [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md): the incident detail behind § Test-Authoring Lenses — the placements, leaks, false greens and undefended rules each lens was extracted from\n\n## Reference Files\n\n### Workflows\n\n- `workflows\u002Fwrite-tests-first.md` - RED phase workflow\n- `workflows\u002Fmake-tests-pass.md` - GREEN phase workflow\n- `workflows\u002Fvalidate-coverage.md` - Quality gate validation\n- `workflows\u002Frefactor-safely.md` - REFACTOR phase workflow\n\n### References\n\n> Note: ## Composite References above is the complete list for this directory and is what the promotion check reads. This older grouping is kept for its per-file commentary and does not include `references\u002Ftest-authoring-exhibits.md`.\n\n- `references\u002Fquality-gates.md` - Mutation and coverage thresholds\n- `references\u002Ftest-patterns.md` - AAA pattern, parameterized tests, factories\n- `references\u002Fanti-patterns.md` - Common anti-patterns to avoid\n- `references\u002Fcommands.md` - Test and validation commands\n\n### Templates\n\n- `templates\u002Ftest-file.md` - New test file structure\n- `templates\u002Fdescribe-block.md` - Behavior-organized test structure\n\n\u003C\u002Freference_index>\n\n## Quick Reference\n\n```bash\n# [CUSTOMIZE] Replace with your project's test commands\n\n# Run tests\n.\u002Fgradlew test\n\n# Run with coverage (JaCoCo)\n.\u002Fgradlew test jacocoTestReport\n\n# Run mutation testing (PIT)\n.\u002Fgradlew pitest\n```\n\n## Test-Authoring Lenses\n\n> **Authoritative source**: which lessons are promoted here, what anchor each one lives at, and the trigger text that has to reach a reader are recorded in `Documents\u002FPlanning\u002Flesson-promotion-manifest.json`. `.github\u002Fscripts\u002FTests\u002Flesson-promotion-manifest.Tests.ps1` is what stops this section and that manifest drifting apart, and it is the suite a red comes from. **Renaming a heading below is a migration, not a regression** — update that lesson's `anchor` in the manifest in the same commit as the rename. A red naming an anchor you just renamed is reporting a manifest row left behind, not a lost lens.\n\nSix ways a suite is green about the wrong thing. Incident detail sits in [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md), cited per lens.\n\n### When you are placing a test file, changing CI selection, or judging whether a rule is defended\n\n#### Blast radius comes from what executes a path, not from what selects from it\n\nBefore placing anything hazardous — a deliberately non-returning control suite, a fixture that must never be collected — **grep for what runs that path, not for what filters it**. A selector and an executor are different things, and safety is a property of the executors. Checking every selector in the repository and finding them all non-recursive and all agreeing on a file count reads as safety while the consumers that would actually hang were never in the searched set: directory-level test invocations, the commands documented in contributor instructions and pull-request templates, baseline-capture helpers. Pester's directory discovery is **recursive**, so a subdirectory placement that the non-recursive gate glob never yields still lands inside the loop every contributor runs before opening a pull request, on a machine with no job ceiling to stop it. And a quarantine entry cannot rescue it: **the registry binds the gate's _selection_, not a raw directory run**, so an entry protects CI and leaves every human exposed. Only outside the tests root is actually safe; the convention that has kept this from biting is that fixtures under that root do not carry the suite suffix. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § A \"safe\" placement inside the pre-PR command.\n\n#### CI selects suites by glob minus the quarantine registry, and a file-scope StrictMode in a dot-sourced library reddens the whole run\n\nSuite selection here is a **glob minus `.github\u002Fscripts\u002FTests\u002Fci-quarantine.json`**, not an allowlist — there is nothing to forget to update, and skipping a suite means adding an entry with a `class` and a `reason`. Keep the classes distinct: never-measured backlog, measured-failing (which requires an issue number, because a temporary exclusion with no ticket is a permanent one that has not admitted it), and structurally-cannot-run. Collapsing them is how a registry becomes a graveyard nobody reads. The trap that ships alongside: **a file-scope `Set-StrictMode` in a library the workflow dot-sources leaks into the entire Pester run**, because the workflow dot-sources and then invokes in the same session — so strictness applies to every suite executed afterwards and reddens subsystems the change never touched. A library dot-sourced by a _runner_ sets strictness **inside its functions**; file scope is only safe for libraries dot-sourced inside a `BeforeAll`, where the blast radius is one file. The verification method worth reusing for any of this: **do not approximate a workflow locally — extract its own `run:` block from the YAML and execute those exact bytes** in a fresh process, swapping the exit-on-failure setting for pass-through. A hand-rolled approximation dot-sources in a different order and misses exactly this class. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § A StrictMode leak that reddened 218 untouched tests.\n\n#### For a CI-only failure, dump the whole decision state in one run\n\nOne hypothesis per round-trip is the slow, wrong method: each narrow assertion comes back clean and kills its hypothesis without pointing anywhere. Push a temporary block that dumps **everything the decision reads plus the product's own output**, unconditionally, written so it lands in the log whether or not the assertion fails. Capture, roughly in value order: the product's own log lines (usually decisive — the executor naming which branch it took ends the search instantly); every probe's exit code _and_ its stdout, not just the boolean you derive from it; the identity facts side by side (the SHAs and refs the decision compares); tool versions and relevant configuration; and whether the mocks were reached at all, since an empty call log is a loud signal. Two traps this method catches: **a shim that only works on one platform makes tests pass for the wrong reason** — every fixture expecting a decline still passes when the tool is simply unavailable, so assert the mock was actually invoked; and a cherry-pick can reproduce a source commit's exact SHA when tree, parent, message, author and committer-second all match, so the branch has zero unique commits and the test silently exercises another path. General rule: a test depending on an unasserted precondition reports the _downstream_ symptom — pin the precondition and the failure names itself. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § Three CI round-trips against one dump.\n\n#### A rule you cannot invoke cannot be defended, however many tests surround it\n\nIf a rule lives inline — a `Where-Object` block, a condition inside a long function — and the only path reaching it runs behind a worker-runspace boundary, a fail-open `catch`, or a guard with conjuncts you cannot satisfy hermetically, then **no test can drive it**: reverting the rule leaves the whole repository green. That is not \"covered by the surrounding tests\", it is undefended, and prose saying it \"moved in lockstep\" reads as defended. **Before claiming a rule is defended, revert it in a scratch tree and run everything — per rule, not per file.** A rule with no reachable red state gets one of exactly two things: **extraction into a named, callable unit** the real code path then calls, or an explicit written record that it ships undefended. The bigger harness is not the fix; testability is a design property of where you put the rule, not of how many tests you wrote. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § A reverted rule that left 23 tests green.\n\n#### A test docstring can name a check the body never performs\n\nWhen a docstring names a cross-surface invariant, check the body actually **reads both surfaces**. A test that enumerates a constant it also authored is self-consistent by construction and can never fail for the reason its documentation gives — and the unwritten check is usually exactly what would have caught the defect sitting next to it, so the overclaim and the gap are one hole seen from two sides. Read the canonical source at runtime instead of typing out a hashtable. The corollary that rides along: an **absence-assertion set is only as good as its enumeration** — pinning that three moved sections are gone while silently omitting a fourth means a re-addition passes everything. And always run the negative control: after fixing, restore the pre-fix file and confirm the new tests actually fail against it; a test that passes both before and after is correctly identified as covering already-working behaviour, not as evidence. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § A docstring that named a check the body never ran.\n\n#### A test that fabricates hostile input can corrupt the aggregate artifact it protects\n\nWhen the property under test is a property of the **whole run's output**, a test that fabricates an adversarial input can satisfy itself and break that property at the same time — unit-level green says nothing, and only the aggregate re-run shows it. Before writing such a test, ask: _does this test run inside the artifact whose aggregate property I am protecting?_ If yes, resolve the adversarial cases through the **pure helper** so nothing is emitted, and keep only end-to-end cases whose output is indistinguishable from a legitimate participant. Watch the harness too, not just your code: a runner that echoes the path of every file it executes will inject a record-shaped string into the same log from a **fixture directory name**, which is the reading hazard the criterion existed to remove, emitted from a line the code never wrote. And check the aggregate rather than the unit — where a criterion is stated over a whole run, the verification has to be a whole run. Exhibit: [references\u002Ftest-authoring-exhibits.md](references\u002Ftest-authoring-exhibits.md) § A test that stamped six false records into its own run.\n\n## Gotchas\n\n| Trigger                                                                | Gotcha                                                                               | Fix                                                                              |\n| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- |\n| Testing a private method via reflection (`setAccessible(true)`)        | Couples test to implementation; breaks on rename or visibility change                | Test through the public interface that exercises the private logic               |\n| Asserting `verify(repo, times(1)).findById(...)` instead of the result | Breaks on caching, batching, or any refactor — tests the mechanism, not the behavior | Assert on the returned result or observable side effect, not how it was obtained |\n| Testing null\u002Fempty inputs that can never occur in the system           | Bloats test suite; encourages defensive code that hides real bugs                    | Test realistic input ranges only; match edge cases to actual system boundaries   |\n| `assertThat(health).isEqualTo(150)` with an exact formula match        | Breaks on any formula tweak; encodes the implementation, not the business rule       | Test comparative invariant (`highVit.health > lowVit.health`) not exact values   |\n| 100% line coverage with assertions that don't verify correctness       | Coverage is green; mutations survive                                                 | Run mutation testing; require ≥80% score; review asserts on each changed line    |\n| Organizing tests as one method per production method                   | Misses behavior variations and error cases; becomes a checklist                      | Organize by scenario\u002Fbehavior with descriptive names; use `@Nested` groups       |\n\n| Trigger                                                    | Gotcha                                                         | Fix                                                                |\n| ---------------------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------ |\n| An integration test uses a helper that sets state directly | The test never proves the real production path or wiring works | Invoke the real service, pipeline, handler, or workflow under test |\n\n| Trigger                                           | Gotcha                                                                | Fix                                                                        |\n| ------------------------------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------- |\n| Mocking inside a layer instead of at its boundary | Tests become implementation-aware and break during harmless refactors | Stub only the external seam and let the layer's internal collaborators run |\n\nFor detailed examples of each anti-pattern, see `references\u002Fanti-patterns.md`.\n\n## Frame Ports Filled By This Skill\n\n| Port | Work adapter | Auto-N\u002FA adapter | Explicit-skip adapter |\n| --- | --- | --- | --- |\n| `implement-test` | [agents\u002FTest-Writer.agent.md](..\u002F..\u002Fagents\u002FTest-Writer.agent.md); [adapters\u002Fimplement-test-adapter.md](adapters\u002Fimplement-test-adapter.md) | [adapters\u002Fimplement-test-auto-na-adapter.md](adapters\u002Fimplement-test-auto-na-adapter.md) | [adapters\u002Fimplement-test-explicit-skip-adapter.md](adapters\u002Fimplement-test-explicit-skip-adapter.md) |\n\nIn `\u002Fspine-run`, the `implement-test` port resolves through [adapters\u002Fimplement-test-adapter.md](adapters\u002Fimplement-test-adapter.md) as the work adapter executed by Senior Engineer. Hub-flow dispatch uses `agents\u002FTest-Writer.agent.md` directly. This split-declaration state is documented in [Documents\u002FDesign\u002Fframe-architecture.md](..\u002F..\u002FDocuments\u002FDesign\u002Fframe-architecture.md); see footnote ‡ (split-declaration #612).\n\n## Cross-platform path conventions\n\nWhen authoring tests that reference filesystem paths via `Join-Path`, use forward\nslashes in child-path arguments. See `.github\u002Farchitecture-rules.md §Validation`\nfor the authoritative convention and enforcement gate.\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Ftest-driven-development",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill test-driven-development",{"tool":61,"command":62},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill test-driven-development",{"tool":64,"command":65},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill test-driven-development","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",true,[69,75,79,83,87,91,95,99,103,107,111,115,119,123],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"adapters\u002Fimplement-test-adapter.md","REFERENCE","参考文档",3712,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Fadapters\u002Fimplement-test-adapter.md",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"adapters\u002Fimplement-test-auto-na-adapter.md",294,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Fadapters\u002Fimplement-test-auto-na-adapter.md",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"adapters\u002Fimplement-test-explicit-skip-adapter.md",331,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Fadapters\u002Fimplement-test-explicit-skip-adapter.md",{"path":84,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fanti-patterns.md",6035,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Freferences\u002Fanti-patterns.md",{"path":88,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fcommands.md",2258,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Freferences\u002Fcommands.md",{"path":92,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fquality-gates.md",2631,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Freferences\u002Fquality-gates.md",{"path":96,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Ftest-authoring-exhibits.md",12086,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Freferences\u002Ftest-authoring-exhibits.md",{"path":100,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Ftest-patterns.md",4190,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Freferences\u002Ftest-patterns.md",{"path":104,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":105,"sourceHtmlUrl":106},"templates\u002Fdescribe-block.md",3488,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Ftemplates\u002Fdescribe-block.md",{"path":108,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":109,"sourceHtmlUrl":110},"templates\u002Ftest-file.md",4897,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Ftemplates\u002Ftest-file.md",{"path":112,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":113,"sourceHtmlUrl":114},"workflows\u002Fmake-tests-pass.md",3765,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Fworkflows\u002Fmake-tests-pass.md",{"path":116,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":117,"sourceHtmlUrl":118},"workflows\u002Frefactor-safely.md",5306,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Fworkflows\u002Frefactor-safely.md",{"path":120,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":121,"sourceHtmlUrl":122},"workflows\u002Fvalidate-coverage.md",3250,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Fworkflows\u002Fvalidate-coverage.md",{"path":124,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":125,"sourceHtmlUrl":126},"workflows\u002Fwrite-tests-first.md",5354,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftest-driven-development\u002Fworkflows\u002Fwrite-tests-first.md",[128,149,173,189,217,236],{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":138,"publishedAt":43},"01M6C48YMJVFHM7DVGG1WWW5RJ","webapp-testing","Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[134,135],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":136,"categoryName":137,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",[27,139,26,140,141,40,142,23,143,39,38,36,25,34,32,144,145,146,147,148],"webapp testing","canvas","tdd","playwright","web","execution","e2e","game","coverage","use",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":43},"01M6C48TNNP2KCSQXV8YK7SK49","verification-before-completion","Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any \"I'm finished\" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[33,156,157,158,159,160,161,162,163,164,165,166,32,167,168,169,170,148,171,172],"verification before completion","review","change","commit","merge","pr","cleanup","run","code","code-review","intake","loop","verification loop","work","check","evidence","campaign",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":43},"01M6C48QZWNTP7JGKD32QZAKKX","validation-methodology","Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fvalidation-methodology\u002FSKILL.md",[],[180,181,182,157,183,184,185,186,164,187,144,148,188],"validation","methodology","validation methodology","triage","orchestration","setup","adversarial review","flow","dispatch",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":203,"publishedAt":43},"01M6C48MCAHG5Z79BJ369CRYRZ","upstream-onboarding","Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fupstream-onboarding\u002FSKILL.md",[195,198],{"categoryNo":196,"categoryName":197,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":199,"categoryName":200,"taxonomyType":201,"taxonomyTypeDesc":202},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[204,205,157,206,207,160,208,161,164,209,210,211,212,213,214,169,170,215,216,148],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":231,"publishedAt":43},"01M6C48GPVE120TGPMD1CS365H","ui-testing","Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-testing\u002FSKILL.md",[223,224,225,228],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":136,"categoryName":137,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":226,"categoryName":227,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":229,"categoryName":230,"taxonomyType":201,"taxonomyTypeDesc":202},"01JBSEEDCAT000000000000032","设计师",[27,232,233,234,42,41,140,40,142,23,39,38,36,25,34,235,145,146,148,26],"ui","ui testing","frontend","testing patterns",{"skillNo":237,"name":238,"nameZh":6,"description":239,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":240,"categories":241,"keywords":244,"publishedAt":43},"01M6C48DRJ9XBDR2FW0W37DY53","ui-iteration","Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-iteration\u002FSKILL.md",[242,243],{"categoryNo":136,"categoryName":137,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":229,"categoryName":230,"taxonomyType":201,"taxonomyTypeDesc":202},[232,245,234,42,157,40,246,164,247,248,249,250,251,169,252,253,148,28],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy"]