[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M746ZJN784HVHMDP9MQGCSGG":3,"skill-same:01M746ZJN784HVHMDP9MQGCSGG":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":35,"repositoryHtmlUrl":36,"repositoryHomepageUrl":37,"ownerHtmlUrl":38,"ownerBlogUrl":39,"ownerDescription":40,"updatedAt":41,"install":42,"resources":53},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill",null,"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.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1559,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: create-verification-skill\ndescription: 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.\ndisable-model-invocation: true\nmetadata:\n  openclaw:\n    homepage: https:\u002F\u002Fe2e.com\n    requires:\n      bins:\n        - node\n        - npx\n---\n\n# Create a verification skill\n\nA coding agent that changes an app should be able to prove the change the\nway a user would see it. This skill writes that proof recipe for one\nproject as a skill, `.agents\u002Fskills\u002Fverify-\u003Capp>\u002F`, built on e2e. The\nconfig launches the app, `e2e mcp` drives it live, tests pin what must\nhold, `e2e explore` bug bashes it, and `.e2e\u002F` keeps the evidence. Write\nthe output for the next agent, not for a human. It will be read cold,\nmid-task, by an agent that has never seen the app.\n\nThe e2e skill is the reference for everything e2e does. Read it first and\nlink to it rather than restate it. It is the sibling\n[e2e skill](..\u002Fe2e\u002FSKILL.md), wherever this skill was installed from; when\nit is missing, `npx skills add e2e-inc\u002Fe2e` or `npx e2e init` installs\nit. `npx e2e guide \u003Ctopic>` prints a reference from the project's installed\npackage; prefer that version when the two differ. Topics\nnamed below (`setup`, `writing-tests`, `mcp`, `explore`, `bug-bash`,\n`running`, `debugging`) are its reference files.\n\n## 1. Interview the repo, not the user\n\nAnswer these from the codebase and ask the user only what you cannot\nobserve.\n\n| Question | Where the answer is | What it decides |\n| --- | --- | --- |\n| Surface | What a user touches. A web UI, an iOS or Android app, an API | One skill per primary surface; name the others for a later run. Web goes through `@e2e-dev\u002Fweb`, iOS and Android through `@e2e-dev\u002Fmobile`. An API with no UI still gets a `web()` target with `app.url` and `app.command` so the runner starts it, and its tests take only `app` and use `fetch` (topic `writing-tests`). A native desktop app has no e2e engine yet, say so and stop. So does a project where no engine has a surface to drive: a CLI, a library, or a batch job, and a desktop frontend whose only browser output is a native-runtime notice. An HTTP service with no UI is not one of those; this row drives it through `web()`. Stop on the observation, not after a write: name the entry point, the engine that cannot drive it, and that no skill was generated |\n| Run | The documented dev command, its ports, env vars, seed data, auth | The target's `app.command` (topic `setup`). A dev server that compiles a route on first visit reads as broken to an agent, so prefer a production build command when the repo has one |\n| e2e state | `e2e.config.ts`, the `tests` glob, `e2e` in `package.json`, `.agents\u002Fskills\u002Fe2e\u002F`, the MCP server in `.codex\u002Fconfig.toml`, `.mcp.json`, or `.cursor\u002Fmcp.json`, and any Playwright or Cypress suite | Nothing there, once the Surface row found something an engine can drive, means `npx e2e init` first (topic `setup`). Running this skill requests that setup. Init registers MCP for Claude Code, Cursor, and Codex. Codex loads its project entry after the project is trusted and a new session starts (topic `mcp`). Check that the session has the e2e tools before a live drive. An existing Playwright or Cypress suite is the best source of locators, seeds, and sign-in steps; read it. A config with no model runs the deterministic steps and the MCP tools, and nothing else |\n| Observe | The trace page, screenshots, video, the report, and what the app leaves behind in files, rows, sent messages, logs | The side-effect stores the Evidence section names. Find them now |\n| Isolate | Can two instances run side by side? | Port `0` in `app.url` gives each run its own app; `command.reuseExisting: true` attaches to one already running on the port. A shared instance that cannot be duplicated (one database, one simulator) becomes a rule in the generated skill. Refusing to double-drive it beats corrupting the user's session |\n| Name | The package name or the repo name | `\u003Capp>` in `verify-\u003Capp>`, lowercase, no scope |\n\nIf the checkout does not build or start as-is, fix that first or report it\nprecisely before generating. A skill written against a broken base teaches\nwrong steps. An irrelevant missing asset (a static dir the API never\nserves, a sample config) may be created by the generated skill, marked as\nverification scaffolding and removed in Cleanup.\n\nAn existing `verify-\u003Capp>\u002F` is read before anything is written. Keep its\nSKILL.md and feature files, add the features the map lacks, and change an\nexisting file only where the app contradicts it.\n\n## 2. Generate the skill\n\nWrite `.agents\u002Fskills\u002Fverify-\u003Capp>\u002FSKILL.md` with YAML frontmatter.\n`name: verify-\u003Capp>` and a `description` naming the app, the surface, and\nwhen to reach for it; without frontmatter the skill never registers. When\nthe project has `.claude\u002Fskills\u002F`, link it the way `e2e init` does, a\nrelative symlink `.claude\u002Fskills\u002Fverify-\u003Capp>` to\n`..\u002F..\u002F.agents\u002Fskills\u002Fverify-\u003Capp>`. Every section says what the interview\nfound, no placeholders.\n\n| Section | Holds |\n| --- | --- |\n| Read first | One line that sends the reader to the e2e skill and names the config file and `tests` glob this skill drives |\n| Launch | The exact command that starts the app for verification and how readiness shows. With a target `app.command`, launch is `npx e2e run \u003Csmoke file>` or an `open_session` over MCP; the runner starts the app, waits for the URL, and stops it. Without one, a target with `app.url` only, the dev command the user starts by hand, and the line that proves the port answers; or keep the command and set `reuseExisting: true`. Say which ports and env the command needs and what seeds the data |\n| Doctor | One read-only check that answers \"is this instance worth driving?\". `npx e2e list` loads the config and prints every test-target pair without starting anything, so a config error shows here first. Then the smoke test, a model-free test that opens the app and pins one landmark; exit `0` means the app starts, the engine runs, and the landmark renders. No smoke test in the project: write `tests\u002Fsmoke.e2e.ts` now. A signed-in app's auth doctor is an ordinary signed-in smoke test that consumes a named session: selecting that test runs its setup and checks the restored state, so one command proves the app starts, the session restores, and a signed-in landmark renders. Running the setup file alone selects no test and exits `NO_TESTS`, so it is not the doctor. An agent runs Doctor first whenever anything looks off |\n| Drive | Two lanes and when to use each. Live over MCP: `open_session`, `observe`, the verbs, and `locate` before any locator is written (topic `mcp`); list the project tools and credentials the session's catalog offers. Scripted: a test under the `tests` glob, `screen` where the name on screen is known, `agent.act` where the flow varies (topic `writing-tests`). Prefer stable handles, roles and accessible names, labels, test ids, routes. Name the credentials and sessions a signed-in drive starts from |\n| Evidence | What a proof keeps and where. Every run writes `.e2e\u002Freport.json`; a failed test gets `.e2e\u002Fresults\u002F\u003Ctest>\u002Ftrace.md`, `--trace on` gives one to passing tests too, `--video` records the attempt (topic `running`), `app.screenshot('\u003Cname>')` saves a named frame (topic `writing-tests`). The next run clears `.e2e\u002Fresults\u002F`, Doctor included, so a proof that must outlive it runs with `--output .e2e\u002Fproof\u002F\u003Cname>` or its attempt directory is copied out before anything else runs. State the proof standards (below) |\n| Bug bash | How this app is bashed (topic `bug-bash`): the bug-bash config to write (what the local app cannot do, the postures, the isolation choice from the interview), the accounts to seed, `.e2e\u002Fbugbash\u002F` added to `.gitignore`, and the rule that the charters come from the feature map (section 3). The verification bar: a finding is a bug only once `tests\u002Fbugbash\u002F\u003Cslug>.e2e.ts` fails on the reported defect, as topic `bug-bash` step 6 reads it |\n| Cleanup | What to tear down. The runner stops the app it started and `close_session` stops the one a session started; a server the user started stays theirs. Never kill by process name; stop what you started. Cleanup removes instances and scratch state (seeded accounts, scaffolding, charters whose findings were all rejected), never the evidence; name where the evidence is |\n| Helpers | Any script the skill ships is executable and its invocation is in the skill body. A helper the reader has to reverse-engineer is not a helper. Most projects need none; the e2e CLI is the helper |\n\nProof standards, for the Evidence section: exercise the real user path,\nnot internal setters or test-only endpoints; capture the action and the\nresulting state, not only the final screen; verify side effects (files\nwritten, rows inserted, messages sent) in the stores the interview found;\nmock only where a production boundary already isolates the external\nsystem. When the safe path is a dry run or a test mode, verify what it\nskips by watching files, network, and refs rather than trusting its name.\n\n## 3. Seed the feature map\n\nCreate `.agents\u002Fskills\u002Fverify-\u003Capp>\u002Ffeatures\u002FREADME.md` plus one file per\nuser-facing feature you can identify, the top three to five first, from\nroutes, navigation, commands, or docs. Follow the example skill this\ngenerator produced and ran for the e2e playground app. Its entry point is\n[SKILL.example.md](references\u002Fexample\u002Fverify-playground\u002FSKILL.example.md)\nso clients do not discover it as another installable skill, and its feature\nmap is [features\u002FREADME.md](references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002FREADME.md)\nwith [todos.md](references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Ftodos.md),\n[forms.md](references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Fforms.md), and\n[login.md](references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Flogin.md). The\nindex is a table of feature, route, test file, and status (`tested` or\n`untested`). Each feature file has these H2s, from the user's point of\nview.\n\n| H2 | Holds |\n| --- | --- |\n| `Sub-features` | What the feature is made of, one line each |\n| `How to get to it (user POV)` | Route, navigation, the account it needs |\n| `Driving it with e2e` | The test file that pins it, the locators that matter (checked with `locate`), the MCP steps for a live walk |\n| `Proof` | The observable end state that means it works, on screen and in the side-effect store |\n| `Charters` | One or two `e2e explore` goals for this feature, each one area, one posture, one sentence (topic `bug-bash`, step 2). Written as the fan-out line `slug\\|target\\|agent\\|charter`, so the bug bash pastes them; a charter that starts signed in names its `--session` and runs alone |\n| `Gotchas` | What reads as broken but is not; what the local app cannot do |\n\nThe map is the project's maintained verification source, and the bug bash\nreads its charters. A proof that drives one convenient entry point is\nincomplete when the map lists others, and a bug bash that skips a mapped\nfeature reports the gap. A feature without a test gets one in step 4 or is\nmarked `untested` in the index.\n\n## 4. Prove the generated skill before handing it over\n\nRun its own instructions end to end once, from a shell in the project.\n\n1. Doctor: the `npx e2e list` call the skill names, then the smoke test;\n   both exit `0`.\n2. Drive one mapped feature through its test file. One is enough; the map\n   exists so later runs cover the rest. A missing test: write it now from\n   the feature file, with locators checked over MCP.\n3. Bug bash one charter from the map: `npx e2e explore '\u003Ccharter>'\n   --config \u003Cbug-bash config> --agent \u003Cpersona> --max-steps 3 --output\n   .e2e\u002Fbugbash\u002F\u003Cslug>`, plus `--session \u003Cname>` when the charter names\n   one. Read its `Findings` and triage; do not verify every finding now.\n   Then read the run's `run.explore` in `report.json`: an ending of\n   `aborted`, or steps that ran a generic survey instead of the mapped\n   charter, leaves the bug bash unproven and the handover says so. The\n   steps prove the charter ran, not the exit code: `1` is also what a run\n   that executed no step exits with. A `--max-steps` ending states the\n   coverage the run reached. This\n   proves the model, the config, the charter, and the output directory, not\n   the app. Without a model, skip this step and say in the handover that\n   the bug bash is unproven.\n4. Cleanup, then confirm the evidence still exists at the named location.\n   A cleanup that eats the proof fails this step.\n\nFix what fails, and run Cleanup after every failed iteration too, so\nbroken attempts do not strand ports and processes. A generated skill that\nwas never executed is a draft, not a deliverable. Leave the project as the\nuser had it. The generated skill, its feature map, the gitignore line, and\nany test you added are the change; `.e2e\u002F` output and the bug-bash config\nstay untracked unless the user asks otherwise.\n\n## 5. Hand over\n\nTell the user what landed. The skill path, the features mapped and which\nhave tests, the charters, what the proof run showed, and the evidence\npaths. Running the map keeps it honest. When a route or label changes and\na test fails, the feature file changes in the same commit. Rerun this skill\nwhen the app grows a feature the map lacks; section 1 says how an existing\nmap is treated.\n\nA project with no supported surface stops in section 1 instead, and this\nhandover reports what you observed and that nothing was written.\n\n## Rules\n\n- Generate from what you observed. A section that could apply to any app\n  is not finished.\n- One sentence from the e2e skill beats a paragraph of your own. Link the\n  topic.\n- Never put a secret in the generated skill or the map. Name the\n  credential (topic `setup`).\n- Do not commit on the user's behalf. List what you created.\n","# Create a verification skill\n\nA coding agent that changes an app should be able to prove the change the\nway a user would see it. This skill writes that proof recipe for one\nproject as a skill, `.agents\u002Fskills\u002Fverify-\u003Capp>\u002F`, built on e2e. The\nconfig launches the app, `e2e mcp` drives it live, tests pin what must\nhold, `e2e explore` bug bashes it, and `.e2e\u002F` keeps the evidence. Write\nthe output for the next agent, not for a human. It will be read cold,\nmid-task, by an agent that has never seen the app.\n\nThe e2e skill is the reference for everything e2e does. Read it first and\nlink to it rather than restate it. It is the sibling\n[e2e skill](..\u002Fe2e\u002FSKILL.md), wherever this skill was installed from; when\nit is missing, `npx skills add e2e-inc\u002Fe2e` or `npx e2e init` installs\nit. `npx e2e guide \u003Ctopic>` prints a reference from the project's installed\npackage; prefer that version when the two differ. Topics\nnamed below (`setup`, `writing-tests`, `mcp`, `explore`, `bug-bash`,\n`running`, `debugging`) are its reference files.\n\n## 1. Interview the repo, not the user\n\nAnswer these from the codebase and ask the user only what you cannot\nobserve.\n\n| Question | Where the answer is | What it decides |\n| --- | --- | --- |\n| Surface | What a user touches. A web UI, an iOS or Android app, an API | One skill per primary surface; name the others for a later run. Web goes through `@e2e-dev\u002Fweb`, iOS and Android through `@e2e-dev\u002Fmobile`. An API with no UI still gets a `web()` target with `app.url` and `app.command` so the runner starts it, and its tests take only `app` and use `fetch` (topic `writing-tests`). A native desktop app has no e2e engine yet, say so and stop. So does a project where no engine has a surface to drive: a CLI, a library, or a batch job, and a desktop frontend whose only browser output is a native-runtime notice. An HTTP service with no UI is not one of those; this row drives it through `web()`. Stop on the observation, not after a write: name the entry point, the engine that cannot drive it, and that no skill was generated |\n| Run | The documented dev command, its ports, env vars, seed data, auth | The target's `app.command` (topic `setup`). A dev server that compiles a route on first visit reads as broken to an agent, so prefer a production build command when the repo has one |\n| e2e state | `e2e.config.ts`, the `tests` glob, `e2e` in `package.json`, `.agents\u002Fskills\u002Fe2e\u002F`, the MCP server in `.codex\u002Fconfig.toml`, `.mcp.json`, or `.cursor\u002Fmcp.json`, and any Playwright or Cypress suite | Nothing there, once the Surface row found something an engine can drive, means `npx e2e init` first (topic `setup`). Running this skill requests that setup. Init registers MCP for Claude Code, Cursor, and Codex. Codex loads its project entry after the project is trusted and a new session starts (topic `mcp`). Check that the session has the e2e tools before a live drive. An existing Playwright or Cypress suite is the best source of locators, seeds, and sign-in steps; read it. A config with no model runs the deterministic steps and the MCP tools, and nothing else |\n| Observe | The trace page, screenshots, video, the report, and what the app leaves behind in files, rows, sent messages, logs | The side-effect stores the Evidence section names. Find them now |\n| Isolate | Can two instances run side by side? | Port `0` in `app.url` gives each run its own app; `command.reuseExisting: true` attaches to one already running on the port. A shared instance that cannot be duplicated (one database, one simulator) becomes a rule in the generated skill. Refusing to double-drive it beats corrupting the user's session |\n| Name | The package name or the repo name | `\u003Capp>` in `verify-\u003Capp>`, lowercase, no scope |\n\nIf the checkout does not build or start as-is, fix that first or report it\nprecisely before generating. A skill written against a broken base teaches\nwrong steps. An irrelevant missing asset (a static dir the API never\nserves, a sample config) may be created by the generated skill, marked as\nverification scaffolding and removed in Cleanup.\n\nAn existing `verify-\u003Capp>\u002F` is read before anything is written. Keep its\nSKILL.md and feature files, add the features the map lacks, and change an\nexisting file only where the app contradicts it.\n\n## 2. Generate the skill\n\nWrite `.agents\u002Fskills\u002Fverify-\u003Capp>\u002FSKILL.md` with YAML frontmatter.\n`name: verify-\u003Capp>` and a `description` naming the app, the surface, and\nwhen to reach for it; without frontmatter the skill never registers. When\nthe project has `.claude\u002Fskills\u002F`, link it the way `e2e init` does, a\nrelative symlink `.claude\u002Fskills\u002Fverify-\u003Capp>` to\n`..\u002F..\u002F.agents\u002Fskills\u002Fverify-\u003Capp>`. Every section says what the interview\nfound, no placeholders.\n\n| Section | Holds |\n| --- | --- |\n| Read first | One line that sends the reader to the e2e skill and names the config file and `tests` glob this skill drives |\n| Launch | The exact command that starts the app for verification and how readiness shows. With a target `app.command`, launch is `npx e2e run \u003Csmoke file>` or an `open_session` over MCP; the runner starts the app, waits for the URL, and stops it. Without one, a target with `app.url` only, the dev command the user starts by hand, and the line that proves the port answers; or keep the command and set `reuseExisting: true`. Say which ports and env the command needs and what seeds the data |\n| Doctor | One read-only check that answers \"is this instance worth driving?\". `npx e2e list` loads the config and prints every test-target pair without starting anything, so a config error shows here first. Then the smoke test, a model-free test that opens the app and pins one landmark; exit `0` means the app starts, the engine runs, and the landmark renders. No smoke test in the project: write `tests\u002Fsmoke.e2e.ts` now. A signed-in app's auth doctor is an ordinary signed-in smoke test that consumes a named session: selecting that test runs its setup and checks the restored state, so one command proves the app starts, the session restores, and a signed-in landmark renders. Running the setup file alone selects no test and exits `NO_TESTS`, so it is not the doctor. An agent runs Doctor first whenever anything looks off |\n| Drive | Two lanes and when to use each. Live over MCP: `open_session`, `observe`, the verbs, and `locate` before any locator is written (topic `mcp`); list the project tools and credentials the session's catalog offers. Scripted: a test under the `tests` glob, `screen` where the name on screen is known, `agent.act` where the flow varies (topic `writing-tests`). Prefer stable handles, roles and accessible names, labels, test ids, routes. Name the credentials and sessions a signed-in drive starts from |\n| Evidence | What a proof keeps and where. Every run writes `.e2e\u002Freport.json`; a failed test gets `.e2e\u002Fresults\u002F\u003Ctest>\u002Ftrace.md`, `--trace on` gives one to passing tests too, `--video` records the attempt (topic `running`), `app.screenshot('\u003Cname>')` saves a named frame (topic `writing-tests`). The next run clears `.e2e\u002Fresults\u002F`, Doctor included, so a proof that must outlive it runs with `--output .e2e\u002Fproof\u002F\u003Cname>` or its attempt directory is copied out before anything else runs. State the proof standards (below) |\n| Bug bash | How this app is bashed (topic `bug-bash`): the bug-bash config to write (what the local app cannot do, the postures, the isolation choice from the interview), the accounts to seed, `.e2e\u002Fbugbash\u002F` added to `.gitignore`, and the rule that the charters come from the feature map (section 3). The verification bar: a finding is a bug only once `tests\u002Fbugbash\u002F\u003Cslug>.e2e.ts` fails on the reported defect, as topic `bug-bash` step 6 reads it |\n| Cleanup | What to tear down. The runner stops the app it started and `close_session` stops the one a session started; a server the user started stays theirs. Never kill by process name; stop what you started. Cleanup removes instances and scratch state (seeded accounts, scaffolding, charters whose findings were all rejected), never the evidence; name where the evidence is |\n| Helpers | Any script the skill ships is executable and its invocation is in the skill body. A helper the reader has to reverse-engineer is not a helper. Most projects need none; the e2e CLI is the helper |\n\nProof standards, for the Evidence section: exercise the real user path,\nnot internal setters or test-only endpoints; capture the action and the\nresulting state, not only the final screen; verify side effects (files\nwritten, rows inserted, messages sent) in the stores the interview found;\nmock only where a production boundary already isolates the external\nsystem. When the safe path is a dry run or a test mode, verify what it\nskips by watching files, network, and refs rather than trusting its name.\n\n## 3. Seed the feature map\n\nCreate `.agents\u002Fskills\u002Fverify-\u003Capp>\u002Ffeatures\u002FREADME.md` plus one file per\nuser-facing feature you can identify, the top three to five first, from\nroutes, navigation, commands, or docs. Follow the example skill this\ngenerator produced and ran for the e2e playground app. Its entry point is\n[SKILL.example.md](references\u002Fexample\u002Fverify-playground\u002FSKILL.example.md)\nso clients do not discover it as another installable skill, and its feature\nmap is [features\u002FREADME.md](references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002FREADME.md)\nwith [todos.md](references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Ftodos.md),\n[forms.md](references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Fforms.md), and\n[login.md](references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Flogin.md). The\nindex is a table of feature, route, test file, and status (`tested` or\n`untested`). Each feature file has these H2s, from the user's point of\nview.\n\n| H2 | Holds |\n| --- | --- |\n| `Sub-features` | What the feature is made of, one line each |\n| `How to get to it (user POV)` | Route, navigation, the account it needs |\n| `Driving it with e2e` | The test file that pins it, the locators that matter (checked with `locate`), the MCP steps for a live walk |\n| `Proof` | The observable end state that means it works, on screen and in the side-effect store |\n| `Charters` | One or two `e2e explore` goals for this feature, each one area, one posture, one sentence (topic `bug-bash`, step 2). Written as the fan-out line `slug\\|target\\|agent\\|charter`, so the bug bash pastes them; a charter that starts signed in names its `--session` and runs alone |\n| `Gotchas` | What reads as broken but is not; what the local app cannot do |\n\nThe map is the project's maintained verification source, and the bug bash\nreads its charters. A proof that drives one convenient entry point is\nincomplete when the map lists others, and a bug bash that skips a mapped\nfeature reports the gap. A feature without a test gets one in step 4 or is\nmarked `untested` in the index.\n\n## 4. Prove the generated skill before handing it over\n\nRun its own instructions end to end once, from a shell in the project.\n\n1. Doctor: the `npx e2e list` call the skill names, then the smoke test;\n   both exit `0`.\n2. Drive one mapped feature through its test file. One is enough; the map\n   exists so later runs cover the rest. A missing test: write it now from\n   the feature file, with locators checked over MCP.\n3. Bug bash one charter from the map: `npx e2e explore '\u003Ccharter>'\n   --config \u003Cbug-bash config> --agent \u003Cpersona> --max-steps 3 --output\n   .e2e\u002Fbugbash\u002F\u003Cslug>`, plus `--session \u003Cname>` when the charter names\n   one. Read its `Findings` and triage; do not verify every finding now.\n   Then read the run's `run.explore` in `report.json`: an ending of\n   `aborted`, or steps that ran a generic survey instead of the mapped\n   charter, leaves the bug bash unproven and the handover says so. The\n   steps prove the charter ran, not the exit code: `1` is also what a run\n   that executed no step exits with. A `--max-steps` ending states the\n   coverage the run reached. This\n   proves the model, the config, the charter, and the output directory, not\n   the app. Without a model, skip this step and say in the handover that\n   the bug bash is unproven.\n4. Cleanup, then confirm the evidence still exists at the named location.\n   A cleanup that eats the proof fails this step.\n\nFix what fails, and run Cleanup after every failed iteration too, so\nbroken attempts do not strand ports and processes. A generated skill that\nwas never executed is a draft, not a deliverable. Leave the project as the\nuser had it. The generated skill, its feature map, the gitignore line, and\nany test you added are the change; `.e2e\u002F` output and the bug-bash config\nstay untracked unless the user asks otherwise.\n\n## 5. Hand over\n\nTell the user what landed. The skill path, the features mapped and which\nhave tests, the charters, what the proof run showed, and the evidence\npaths. Running the map keeps it honest. When a route or label changes and\na test fails, the feature file changes in the same commit. Rerun this skill\nwhen the app grows a feature the map lacks; section 1 says how an existing\nmap is treated.\n\nA project with no supported surface stops in section 1 instead, and this\nhandover reports what you observed and that nothing was written.\n\n## Rules\n\n- Generate from what you observed. A section that could apply to any app\n  is not finished.\n- One sentence from the e2e skill beats a paragraph of your own. Link the\n  topic.\n- Never put a secret in the generated skill or the map. Name the\n  credential (topic `setup`).\n- Do not commit on the user's behalf. List what you created.\n",{"name":5,"metadata":24,"description":7,"disable-model-invocation":31},{"openclaw":25},{"homepage":26,"requires":27},"https:\u002F\u002Fe2e.com",{"bins":28},[29,30],"node","npx",true,"main","40706766fd37c03ca624f5206741fef55dd2a684","plugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill",474,"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-11 14:40:14",{"source":8,"skillName":5,"commands":43,"prompt":52,"zipAvailable":31},[44,46,49],{"tool":30,"command":45},"npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill create-verification-skill",{"tool":47,"command":48},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill create-verification-skill",{"tool":50,"command":51},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill create-verification-skill","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[54,60,64,68,72,76],{"path":55,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":58,"sourceHtmlUrl":59},"agents\u002Fopenai.yaml","REFERENCE","参考文档",419,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002Fagents\u002Fopenai.yaml",{"path":61,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":62,"sourceHtmlUrl":63},"references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Fforms.md",1738,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Fforms.md",{"path":65,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":66,"sourceHtmlUrl":67},"references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Flogin.md",1852,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Flogin.md",{"path":69,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":70,"sourceHtmlUrl":71},"references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002FREADME.md",759,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Fexample\u002Fverify-playground\u002Ffeatures\u002FREADME.md",{"path":73,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Ftodos.md",1832,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Fexample\u002Fverify-playground\u002Ffeatures\u002Ftodos.md",{"path":77,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fexample\u002Fverify-playground\u002FSKILL.example.md",4236,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Fexample\u002Fverify-playground\u002FSKILL.example.md",[81,88,95,123,147,181],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"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",[],[],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":19},"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":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":122},"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",[],[102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121],"deja search","search","past","debugging","merge","cli","change","io","reviewer","done","you","when","error","design","fix","decide","re","memory","never","ready","2026-11-10 10:12:30",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":122},"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",[],[130,131,132,133,29,134,135,136,137,138,109,139,140,141,142,143,119,144,145,146],"reflect","deja reflect","with","project","https","next","github","record","end","review","decisions","Rules","reflection","session","remember","brew","project rules",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":164,"publishedAt":122},"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",[153,158,161],{"categoryNo":154,"categoryName":155,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":159,"categoryName":160,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":162,"categoryName":163,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000010","后端与接口",[149,165,166,167,168,169,133,170,171,172,173,174,175,113,176,177,178,179,118,180],"viral","PDF","standalone","short-form","Video","URL","publish","api","schedule","mcp server","image","song","MCP","social","short","tiktok",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":122},"01M71569ZM2X3H5RBFK8PVKMK2","review-study","Review a QuestionPunk survey before launch for wording, answer choices, branching, and missing settings. Use for check my survey or review this draft before publishing.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fquestionpunk\u002Fcodex-plugin\u002Fskills\u002Freview-study\u002FSKILL.md",[],[188,139,189,190,191,192,193,194,195,196,197,198,199,200,201],"review study","study","settings","branching","my","launch","draft","check","use","publishing","survey","missing","answer","for"]