[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MESP9W32Y8KB6NSVR53ZW0":3,"skill-same:01M6MESP9W32Y8KB6NSVR53ZW0":125},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":70,"commitSha":71,"skillDirectory":72,"forksCount":73,"repositoryHtmlUrl":74,"repositoryHomepageUrl":75,"ownerHtmlUrl":76,"ownerBlogUrl":77,"ownerDescription":78,"updatedAt":79,"install":80,"resources":92},"01M6MESP9W32Y8KB6NSVR53ZW0","test",null,"Write or assess tests that prove behavior and would fail without the fix. Use when: writing tests, TDD, or asked whether a green test is enough.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1575,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fboshu2\u002Fagentops\u002Fskills\u002Ftest\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"behavioral","when","execution","tests","true","bdd","Reproducible","repo","evidence","standards","context","source","canonical","write","writing","files","fix","testing","green","coverage","2026-11-10 10:12:30",false,"---\nname: test\ndescription: 'Write or assess tests that prove behavior and would fail without the fix. Use when: writing tests, TDD, or asked whether a green test is enough.'\npractices:\n- tdd\n- property-based-testing\n- bdd-gherkin\nhexagonal_role: supporting\nconsumes:\n- standards\n- repo-context\nproduces:\n- test-evidence\ncontext_rel: []\nskill_api_version: 1\nuser-invocable: true\nmetadata:\n  capabilities: [test]\n  effects: [write_test_files, write_test_evidence, modify_source_files]\n  canonical_status: canonical\n  disposition: keep_specialist\n  tier: execution\n  dependencies: []\noutput_contract: behavioral tests and reproducible check facts; coverage results when requested\n---\n# Test\n\nThis skill makes a test assert the effect the behavior promises, with exact\nvalues, and shows that the test fails without the fix before it counts as\nproof. A user sees it worked when the handoff names each test's asserted\nvalues and how it was shown failing, or says \"not shown\".\n\nA green test is evidence for the caller's decision, never the test author's\nmerge approval; the binding verdict belongs to [Validate](..\u002Fvalidate\u002FSKILL.md).\nTo only run a known suite, run it directly.\n\n## Critical Constraints\n\n- **Assert the promised effect.** Check the state change, outbound call or count\n  the behavior promises at its boundary, reading a stored record back through\n  the product's own read path unless the stored shape is the contract. Take\n  exact expected values from a literal, worked example or the specification,\n  never the implementation's own formula or a mock's answer: for a 20% discount\n  on 50, assert 40. A status code, a returned object or the absence of an\n  exception alone does not prove the behavior; would the test stay green if the\n  code returned an empty or default result? A rejection test asserts the error\n  its name claims, since another guard can reject the same input.\n- **A regression test proves nothing until it fails on the defect.** Show that\n  it fails on the pre-fix code (see Mutation-kill proof) through the callers,\n  sequence or state that produced the report, not only at the changed line.\n  Until then, report its proof as \"not shown\"; green alone is not yet proof.\n- Derive cases from accepted observable behavior; reuse examples from the\n  conversation, bead, specification or existing contract before inventing\n  new ones. Keep established domain names; do not unify bounded-context terms\n  by renaming tests.\n- Use the repository's framework and real check recipe; keep tests free of\n  accidental timing, ordering and shared-state dependencies.\n- A test that starts green on existing correct behavior is legitimate; use such\n  tests to pin untested code before changing it, marking an odd result as a\n  suspected defect. Never manufacture a RED claim or alter acceptance to excuse\n  a product defect.\n- Repair a discovered defect when already authorized; otherwise report the reproducer and finding, never masking it by deleting or weakening a test ([fix the cause, not the oracle](..\u002Fimplement\u002FSKILL.md#rules-that-decide-the-result)).\n- Never refresh a golden or snapshot file to turn a test green. Find the source\n  change behind the diff; update the artifact only for intended behavior or\n  fixture drift and say why in the handoff; for a bug, fix the generator.\n\n## Oracle-strength hierarchy\n\nPrefer exact observable values or errors when known. Use properties or\ninvariants when they express the contract more faithfully than one example.\nDifferential agreement needs an independently credible reference. A smoke\ncheck proves only what it observes; it cannot establish an exact behavior by\nitself. When correctness is a matter of meaning, as for a summary or ranking, a\ncount is only a proxy; judge it as in [proof fidelity](references\u002Fproof-fidelity.md#output-judged-for-meaning).\nExplain a material oracle limit in the native handoff, without creating a\nworksheet or mandatory report.\n\n## Mutation-kill proof\n\nEstablish that an important new behavioral check can catch the defect it claims\nto guard. An authentic pre-fix RED or reproduction is usually sufficient. If a\nregression test was written after the fix, run it against the pre-fix version\n(revert the fix in an isolated copy) or use a safe, targeted negative control.\nMutate only when that would resolve real doubt about the oracle, then restore\nand verify the candidate. Do not demand one mutation experiment per table row\nor new test. Trust a revert or mutation result only from a copy confirmed to\nhold this candidate's commit and uncommitted changes plus that one edit; a\nworktree cut from HEAD can lack the fix or test. Never mutate a shared checkout.\n\n## Harness health floors\n\nConfirm the runner completed, the intended tests actually ran, and assertions\nobserve the promised behavior. Take the result from the runner's exit status,\nnot its printed output, and keep that status through pipes (`pipefail`):\n`make test | tail` reports `tail`. A check that edits tracked files has changed\nthe subject; report the edit. Report crashes, truncation, unexpected skips or\nexclusions as gaps. When runner discovery or failure reporting changed, use a\nnegative control through that same path before trusting green. When the change\nis itself a check standing in for a real run, also match its context to what it\nprotects ([proof fidelity](references\u002Fproof-fidelity.md#a-check-that-stands-in-for-a-real-run)).\nNo need to re-prove an unchanged healthy runner on each edit.\n\n## Modes\n\n| Mode | Use when | Result |\n|---|---|---|\n| `generate` | Existing behavior needs tests | Useful tests and focused\u002Fsuite results |\n| `coverage` | The caller asks to find or fill gaps | Before\u002Fafter coverage, valuable tests and remaining risks |\n| `tdd` | The caller asks for TDD on new behavior | A test shown failing without the change, the change, green, then refactor |\n| `strategy` | The caller wants test design only | Prioritized risks and proposed checks in the existing discussion |\n\nDefault to `generate`; mode and scope are skill prompt choices, not invented\nCLI flags. Coverage thresholds come from the caller or repository.\n\n## Workflow\n\n1. Read the accepted examples and the relevant public interface. One\n   discriminating example may suffice for a small change; add the error and\n   boundary cases that could falsify acceptance. A `.feature` file is optional;\n   if the repository already uses scenario-to-test annotations, maintain them\n   and use its scenario coverage checker. When several record kinds support\n   different actions, read\n   [kind and action pairs](references\u002Fproof-fidelity.md#several-record-kinds-and-actions).\n   Done when each accepted example and each falsifying case has a named test\n   or a `not_checked` line.\n2. Find the owning suite and a narrow baseline. For a defect, choose which test\n   carries its proof before changing code; with no seam that reaches the\n   reported chain, write no shallower stand-in\n   ([proof fidelity](references\u002Fproof-fidelity.md#place-the-proof-of-a-defect)).\n   Measure broad coverage only in `coverage` mode or under an existing\n   repository requirement.\n3. Write the smallest test that observes the promised result through a stable\n   interface: the entry point callers use. Add no export, flag or hook only\n   tests call (a time, randomness or external-boundary seam excepted), mock no\n   collaborator inside the unit, and move to the interface any test you write\n   here that a behavior-preserving rewrite would break; list existing ones under\n   `rewrite` ([suite audit](references\u002Fsuite-audit.md)).\n   In `tdd` mode the proof is a test that fails without the change for the\n   expected missing-behavior reason. Running it before implementation or\n   against the pre-change code (Mutation-kill proof) both show that; do not\n   require one order. Then refactor under green\n   ([Refactor](..\u002Frefactor\u002FSKILL.md) when the cleanup reaches beyond the\n   change). Take one behavior at a time, each next case chosen from what the\n   last cycle showed.\n4. Run focused checks while editing and the relevant integration recipe before\n   handoff; broaden only for changed risk, a failure or repository policy.\n5. Compare against the original accepted examples. New tests added after\n   implementation may supplement but never replace them.\n\n## Specialized references\n\nLoad only the guidance needed by the subject:\n\n- Service integration: [real-service E2E](references\u002Freal-service-e2e.md)\n- Selected user journeys: [exploratory QA](references\u002Fexploratory-qa.md)\n- Authorized suite maintenance: [suite audit](references\u002Fsuite-audit.md)\n- Defect proof placement, stand-in checks and judged output: [proof fidelity](references\u002Fproof-fidelity.md)\n- CLI\u002FAPI failure signals and uncertain write outcomes: [error recovery](references\u002Ferror-recovery.md)\n- Timing, shared-state or concurrency failures: [difficult-failure experiments](..\u002Fimplement\u002Freferences\u002Fdifficult-failures.md)\n- Workload baseline and candidate comparison: [subject performance](references\u002Fsubject-performance.md)\n\n## Output Specification\n\nTests belong in the repository's language-native locations. Check facts and\nlimits go in the existing handoff:\n\n```text\ntests:       \u003Cfile::name> -> \u003Cbehavior and exact values it asserts>\nproof:       \u003Ceach important new test> -> how it was shown to fail on its defect:\n             pre-fix RED | reverted-fix run | negative control | not shown\ncommands:    \u003Cexact command> -> \u003Cresult>\nharness:     \u003Crunner completed; how many ran; skips or exclusions>\ncoverage:    \u003Cbefore -> after, command> (coverage mode only)\ndefects:     \u003Cdiscovered defect and reproducer, or none>\nrewrite:     \u003Cexisting test a behavior-preserving change would break>\nnot_checked: \u003Cmaterial behavior no test covers>\n```\n\nPersist coverage or other reports only when requested or required by a declared\nconsumer, at its selected destination; no automatic `.agents\u002F` output.\n\nExample: for a duplicate Job delivery, assert that the completed result is\nreturned and the external side effect is called only once. A coverage increase\nwithout those assertions would not prove the behavior.\n\nThis guidance uses original examples informed by\n[Matt Pocock's engineering skills](https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills),\nwith AgentOps' existing acceptance and evidence boundaries.\n","# Test\n\nThis skill makes a test assert the effect the behavior promises, with exact\nvalues, and shows that the test fails without the fix before it counts as\nproof. A user sees it worked when the handoff names each test's asserted\nvalues and how it was shown failing, or says \"not shown\".\n\nA green test is evidence for the caller's decision, never the test author's\nmerge approval; the binding verdict belongs to [Validate](..\u002Fvalidate\u002FSKILL.md).\nTo only run a known suite, run it directly.\n\n## Critical Constraints\n\n- **Assert the promised effect.** Check the state change, outbound call or count\n  the behavior promises at its boundary, reading a stored record back through\n  the product's own read path unless the stored shape is the contract. Take\n  exact expected values from a literal, worked example or the specification,\n  never the implementation's own formula or a mock's answer: for a 20% discount\n  on 50, assert 40. A status code, a returned object or the absence of an\n  exception alone does not prove the behavior; would the test stay green if the\n  code returned an empty or default result? A rejection test asserts the error\n  its name claims, since another guard can reject the same input.\n- **A regression test proves nothing until it fails on the defect.** Show that\n  it fails on the pre-fix code (see Mutation-kill proof) through the callers,\n  sequence or state that produced the report, not only at the changed line.\n  Until then, report its proof as \"not shown\"; green alone is not yet proof.\n- Derive cases from accepted observable behavior; reuse examples from the\n  conversation, bead, specification or existing contract before inventing\n  new ones. Keep established domain names; do not unify bounded-context terms\n  by renaming tests.\n- Use the repository's framework and real check recipe; keep tests free of\n  accidental timing, ordering and shared-state dependencies.\n- A test that starts green on existing correct behavior is legitimate; use such\n  tests to pin untested code before changing it, marking an odd result as a\n  suspected defect. Never manufacture a RED claim or alter acceptance to excuse\n  a product defect.\n- Repair a discovered defect when already authorized; otherwise report the reproducer and finding, never masking it by deleting or weakening a test ([fix the cause, not the oracle](..\u002Fimplement\u002FSKILL.md#rules-that-decide-the-result)).\n- Never refresh a golden or snapshot file to turn a test green. Find the source\n  change behind the diff; update the artifact only for intended behavior or\n  fixture drift and say why in the handoff; for a bug, fix the generator.\n\n## Oracle-strength hierarchy\n\nPrefer exact observable values or errors when known. Use properties or\ninvariants when they express the contract more faithfully than one example.\nDifferential agreement needs an independently credible reference. A smoke\ncheck proves only what it observes; it cannot establish an exact behavior by\nitself. When correctness is a matter of meaning, as for a summary or ranking, a\ncount is only a proxy; judge it as in [proof fidelity](references\u002Fproof-fidelity.md#output-judged-for-meaning).\nExplain a material oracle limit in the native handoff, without creating a\nworksheet or mandatory report.\n\n## Mutation-kill proof\n\nEstablish that an important new behavioral check can catch the defect it claims\nto guard. An authentic pre-fix RED or reproduction is usually sufficient. If a\nregression test was written after the fix, run it against the pre-fix version\n(revert the fix in an isolated copy) or use a safe, targeted negative control.\nMutate only when that would resolve real doubt about the oracle, then restore\nand verify the candidate. Do not demand one mutation experiment per table row\nor new test. Trust a revert or mutation result only from a copy confirmed to\nhold this candidate's commit and uncommitted changes plus that one edit; a\nworktree cut from HEAD can lack the fix or test. Never mutate a shared checkout.\n\n## Harness health floors\n\nConfirm the runner completed, the intended tests actually ran, and assertions\nobserve the promised behavior. Take the result from the runner's exit status,\nnot its printed output, and keep that status through pipes (`pipefail`):\n`make test | tail` reports `tail`. A check that edits tracked files has changed\nthe subject; report the edit. Report crashes, truncation, unexpected skips or\nexclusions as gaps. When runner discovery or failure reporting changed, use a\nnegative control through that same path before trusting green. When the change\nis itself a check standing in for a real run, also match its context to what it\nprotects ([proof fidelity](references\u002Fproof-fidelity.md#a-check-that-stands-in-for-a-real-run)).\nNo need to re-prove an unchanged healthy runner on each edit.\n\n## Modes\n\n| Mode | Use when | Result |\n|---|---|---|\n| `generate` | Existing behavior needs tests | Useful tests and focused\u002Fsuite results |\n| `coverage` | The caller asks to find or fill gaps | Before\u002Fafter coverage, valuable tests and remaining risks |\n| `tdd` | The caller asks for TDD on new behavior | A test shown failing without the change, the change, green, then refactor |\n| `strategy` | The caller wants test design only | Prioritized risks and proposed checks in the existing discussion |\n\nDefault to `generate`; mode and scope are skill prompt choices, not invented\nCLI flags. Coverage thresholds come from the caller or repository.\n\n## Workflow\n\n1. Read the accepted examples and the relevant public interface. One\n   discriminating example may suffice for a small change; add the error and\n   boundary cases that could falsify acceptance. A `.feature` file is optional;\n   if the repository already uses scenario-to-test annotations, maintain them\n   and use its scenario coverage checker. When several record kinds support\n   different actions, read\n   [kind and action pairs](references\u002Fproof-fidelity.md#several-record-kinds-and-actions).\n   Done when each accepted example and each falsifying case has a named test\n   or a `not_checked` line.\n2. Find the owning suite and a narrow baseline. For a defect, choose which test\n   carries its proof before changing code; with no seam that reaches the\n   reported chain, write no shallower stand-in\n   ([proof fidelity](references\u002Fproof-fidelity.md#place-the-proof-of-a-defect)).\n   Measure broad coverage only in `coverage` mode or under an existing\n   repository requirement.\n3. Write the smallest test that observes the promised result through a stable\n   interface: the entry point callers use. Add no export, flag or hook only\n   tests call (a time, randomness or external-boundary seam excepted), mock no\n   collaborator inside the unit, and move to the interface any test you write\n   here that a behavior-preserving rewrite would break; list existing ones under\n   `rewrite` ([suite audit](references\u002Fsuite-audit.md)).\n   In `tdd` mode the proof is a test that fails without the change for the\n   expected missing-behavior reason. Running it before implementation or\n   against the pre-change code (Mutation-kill proof) both show that; do not\n   require one order. Then refactor under green\n   ([Refactor](..\u002Frefactor\u002FSKILL.md) when the cleanup reaches beyond the\n   change). Take one behavior at a time, each next case chosen from what the\n   last cycle showed.\n4. Run focused checks while editing and the relevant integration recipe before\n   handoff; broaden only for changed risk, a failure or repository policy.\n5. Compare against the original accepted examples. New tests added after\n   implementation may supplement but never replace them.\n\n## Specialized references\n\nLoad only the guidance needed by the subject:\n\n- Service integration: [real-service E2E](references\u002Freal-service-e2e.md)\n- Selected user journeys: [exploratory QA](references\u002Fexploratory-qa.md)\n- Authorized suite maintenance: [suite audit](references\u002Fsuite-audit.md)\n- Defect proof placement, stand-in checks and judged output: [proof fidelity](references\u002Fproof-fidelity.md)\n- CLI\u002FAPI failure signals and uncertain write outcomes: [error recovery](references\u002Ferror-recovery.md)\n- Timing, shared-state or concurrency failures: [difficult-failure experiments](..\u002Fimplement\u002Freferences\u002Fdifficult-failures.md)\n- Workload baseline and candidate comparison: [subject performance](references\u002Fsubject-performance.md)\n\n## Output Specification\n\nTests belong in the repository's language-native locations. Check facts and\nlimits go in the existing handoff:\n\n```text\ntests:       \u003Cfile::name> -> \u003Cbehavior and exact values it asserts>\nproof:       \u003Ceach important new test> -> how it was shown to fail on its defect:\n             pre-fix RED | reverted-fix run | negative control | not shown\ncommands:    \u003Cexact command> -> \u003Cresult>\nharness:     \u003Crunner completed; how many ran; skips or exclusions>\ncoverage:    \u003Cbefore -> after, command> (coverage mode only)\ndefects:     \u003Cdiscovered defect and reproducer, or none>\nrewrite:     \u003Cexisting test a behavior-preserving change would break>\nnot_checked: \u003Cmaterial behavior no test covers>\n```\n\nPersist coverage or other reports only when requested or required by a declared\nconsumer, at its selected destination; no automatic `.agents\u002F` output.\n\nExample: for a duplicate Job delivery, assert that the completed result is\nreturned and the external side effect is called only once. A coverage increase\nwithout those assertions would not prove the behavior.\n\nThis guidance uses original examples informed by\n[Matt Pocock's engineering skills](https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills),\nwith AgentOps' existing acceptance and evidence boundaries.\n",{"name":5,"consumes":49,"metadata":51,"produces":59,"practices":61,"context_rel":65,"description":7,"hexagonal_role":66,"user-invocable":67,"output_contract":68,"skill_api_version":69},[33,50],"repo-context",{"tier":26,"effects":52,"disposition":56,"capabilities":57,"dependencies":58,"canonical_status":36},[53,54,55],"write_test_files","write_test_evidence","modify_source_files","keep_specialist",[5],[],[60],"test-evidence",[62,63,64],"tdd","property-based-testing","bdd-gherkin",[],"supporting",true,"behavioral tests and reproducible check facts; coverage results when requested",1,"main","347aedf8480cd92b21f761e97b7343a45898f5fa","plugins\u002Fboshu2\u002Fagentops\u002Fskills\u002Ftest",491,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 14:06:13",{"source":8,"skillName":5,"commands":81,"prompt":91,"zipAvailable":67},[82,85,88],{"tool":83,"command":84},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill test",{"tool":86,"command":87},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill test",{"tool":89,"command":90},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill test","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fboshu2\u002Fagentops\u002Fskills\u002Ftest\u002FSKILL.md",[93,99,103,107,111,115,119],{"path":94,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Ferror-recovery.md","REFERENCE","参考文档",3115,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fboshu2\u002Fagentops\u002Fskills\u002Ftest\u002Freferences\u002Ferror-recovery.md",{"path":100,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fexploratory-qa.md",6169,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fboshu2\u002Fagentops\u002Fskills\u002Ftest\u002Freferences\u002Fexploratory-qa.md",{"path":104,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fproof-fidelity.md",4895,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fboshu2\u002Fagentops\u002Fskills\u002Ftest\u002Freferences\u002Fproof-fidelity.md",{"path":108,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Freal-service-e2e.md",1816,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fboshu2\u002Fagentops\u002Fskills\u002Ftest\u002Freferences\u002Freal-service-e2e.md",{"path":112,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Fsubject-performance.md",5939,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fboshu2\u002Fagentops\u002Fskills\u002Ftest\u002Freferences\u002Fsubject-performance.md",{"path":116,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":117,"sourceHtmlUrl":118},"references\u002Fsuite-audit.md",5194,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fboshu2\u002Fagentops\u002Fskills\u002Ftest\u002Freferences\u002Fsuite-audit.md",{"path":120,"resourceType":121,"resourceTypeDesc":122,"sizeBytes":123,"sourceHtmlUrl":124},"scripts\u002Fvalidate.sh","SCRIPT","脚本",2969,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fboshu2\u002Fagentops\u002Fskills\u002Ftest\u002Fscripts\u002Fvalidate.sh",[126,134,141,148,173,198],{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":133},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":133},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":133},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":44},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[155,156,157,158,159,160,161,162,40,163,164,25,165,166,167,168,169,170,171,172],"search","deja search","never","error","ready","memory","re","decide","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":44},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[180,181,182,168,183,184,185,186,187,188,189,190,191,192,160,193,194,195,196,197],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":213,"publishedAt":44},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[204,207,210],{"categoryNo":205,"categoryName":206,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":211,"categoryName":212,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[200,214,215,216,217,218,219,194,220,161,221,222,223,224,25,225,226,227,228,229],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]