[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79WGYNFQGGJ4Q889NJJ2K9H":3,"skill-same:01M79WGYNFQGGJ4Q889NJJ2K9H":57},{"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":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":30,"ownerDescription":31,"updatedAt":32,"install":33,"resources":46},"01M79WGYNFQGGJ4Q889NJJ2K9H","verified-waves",null,"Run one task as verified multi-agent waves. Plans the fan-out, sends findings to fresh skeptics, keeps a ledger, and reports N of M done; small tasks stay solo.","Blind-Striker\u002Fagent-skills-and-plugins","Blind-Striker","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1965259?v=4","01M79WFXTE5PH0C1VB7B54ANMN","Deniz İrgin","01M79WFXV5KZ5GST1K8G035DM5",1,"MIT","https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins\u002Fblob\u002Fmaster\u002Fcodex\u002Fdeniz-coordination\u002Fskills\u002Fverified-waves\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: verified-waves\ndescription: Run one task as verified multi-agent waves. Plans the fan-out,\n  sends findings to fresh skeptics, keeps a ledger, and reports N of M done;\n  small tasks stay solo.\n---\n\n# Verified Waves\n\nYou run one task as waves of sub-agents. You plan, dispatch, record, and verify; the children do\nthe per-item work. One ledger records the run, every child gets a self-contained brief and returns a\nfixed report, and every finding that matters goes to a fresh skeptic before you report it.\n\n## What invoking this means\n\n- The user invoked this skill, so this is their explicit request for parallel sub-agents on this\n  task.\n- If the invocation carries no task, ask for the task and stop there: start no child and create no\n  ledger until the user answers.\n- Read `references\u002Fharness-tools.md` first. It names this harness's tools for starting, waiting on,\n  continuing, and closing children, says where the ledger lives, and says which permission prompts\n  to expect.\n- Then apply the small-task test. The task is **small** when it is one item: one edit or one\n  question, in one place. For a small task, say that it is small and why, and do it directly: no\n  plan, no ledger, no child.\n- A task whose every step needs the previous step's result is **sequential**, not small: it cannot\n  fan out, but it can still use verification. Decide by judgment between doing it directly and\n  doing it directly with a final gate and skeptic wave on its result, and say which in one line.\n- Otherwise, list the independent items and fan out.\n- Only when you are genuinely torn — a borderline small task the user explicitly sent here, or a\n  sequential task where verification may or may not pay — ask once, with your recommendation.\n\n## Plan before any dispatch\n\nWrite the plan in chat before the first child starts:\n\n0. **Request**: the user's words, verbatim, in their language.\n1. **Goal**: one sentence, your reading of the request, labelled as yours.\n2. **Done when**: binary checks, each one PASS or FAIL when it is run.\n3. **Stop when**: the conditions that end the run early, such as a failed gate.\n4. **Shape**: one from the next section.\n5. **Items**: each with an id, a kind (read | write | verify | gate | critic), and its write set\n   (`none` for a read). An id is a lowercase letter, then lowercase letters, digits, or `_`, at most\n   32 characters, such as `audit_04`.\n6. **Waves**: which items run in which wave, the estimated agent total with skeptics, gates, and\n   critics counted, and the ceiling on live children: 6 unless the user names another number for this\n   run, and never above the harness limit that `references\u002Fharness-tools.md` gives. The ceiling is\n   a limit, not a target, and the agent total is not the ceiling: count it from the plan, every\n   item plus its skeptics, gates, and critics.\n7. **Verification plan**: which findings get skeptics, and which checks each gate runs.\n\nThe agent total you announce is an estimate; the final report compares it with the actual count.\nThe only budget is a limit the user sets. Set no other budget and no deadline. A retry of a FAILED\nitem and a fix pass toward the same done-when check are not new scope.\n\nEvery item names the words of the request it serves; cut an item that names none. Verification and\none-off checks use the tools the repository already has: the plan adds no new project, script,\nrunner, or evidence document in the repository unless the request asks for one. An item that would\nchange what the request says done means, a public API, or what existing users of a public surface\nmust write is held as an open decision, with their code before and after; the rest of the run goes on.\n\nAfter you write the plan, start the first wave in the same turn; the plan's questions do not hold\nit up.\n\nThese actions need the user's yes, unless the request already names them: deleting files the\nrequest does not name, discarding uncommitted changes this run did not make, a force-push, a\npublish, anything that touches credentials, and any other action the repository's rules reserve.\nAsk about the ones you can foresee with the plan.\nFinish every item that does not depend on such an action, never take it before an explicit yes,\nand ask about the rest once, at the end, with everything else done.\n\n## Pick the shape\n\nPick the one dominant shape before you write briefs:\n\n- **Sweep**: read-only children cover disjoint areas, and their findings are the output.\n- **Fan-out then synthesis**: children gather, and one agent merges what they found.\n- **Review, verify, fix**: reviewers find, skeptics test each finding, writers fix what survives.\n- **Build waves with gates**: writer waves on disjoint write sets, with a gate child after each.\n- **Draft and critic**: one child drafts, a fresh child critiques, and the drafter revises.\n- **Judge panel**: several children answer one question independently, and one judge compares.\n\nWhen the raw results are the deliverable, the run ends at the fan-out, with no synthesizer. Ranking\nor merging needs one agent that sees every candidate. Verify each item as soon as its producer\nreports, not after the whole wave.\n\n## The ledger\n\nThe ledger is one Markdown file, `\u003Cledger-dir>\u002Fledger.md`. `\u003Cledger-dir>` is\n`verified-waves\u002F\u003Crun-id>\u002F` under the location that `references\u002Fharness-tools.md` names, outside the\nworking tree; `\u003Crun-id>` is short and unique, such as the date, the time, and a slug. Before you\ncreate `\u003Cledger-dir>`, check that it does not exist. If it does, pick another run-id, for example by\nadding a counter: a new run never writes into an existing ledger directory, and only a restart of\nthe same run continues in its own. Tell the user the path. The ledger is never committed.\n\nCreate the ledger and its `results\u002F` directory before the first dispatch, so any permission prompt\nfor that location comes up once, before children run.\n\nThe ledger holds:\n\n- A header: the request verbatim, your goal reading, done-when checks, stop-when conditions, waves,\n  the estimated agent total, and the ceiling.\n- One row per item, under this header:\n\n  ```\n  | id | kind | write set | status | handle | result path |\n  ```\n\n  `handle` is the harness's identifier for the child. The status is one of `PENDING`, `RUNNING`,\n  `DONE`, `PARTIAL`, `BLOCKED`, `FAILED`, or `UNVERIFIED`.\n- An append-only log: one line for each dispatch, result, retry, verdict, and cap, with its item id.\n\nUpdate the ledger at each event, not at the end.\n\n## Briefs and reports\n\nA child starts without your context. Give each child one brief in this form, every field filled:\n\n```\nITEM \u003Cid> — read | write | verify | gate | critic\nGOAL: \u003Cone action>. The parent will use your result to \u003Cdecision>.\nCONTEXT: \u003Cexact paths, prior findings; shared contract pasted unchanged>\nSCOPE: read-only | write only: \u003Cpaths>   (either way, also your results file)\nDO: \u003Cmusts>   DO NOT: commit, push, edit outside scope, weaken\u002Fdelete tests, write long-term memory, ask the user a task or scope question\n[writers] Other agents edit other files now; do not revert or reformat changes you did not make.\nDONE WHEN: \u003Cbinary observable check>\nLAST STEP: write \u003Cledger-dir>\u002Fresults\u002F\u003Cid>.md: first the REPORT block you return, unchanged, then any detail past 40 lines; if you cannot write files, return the report only\nRETURN: the report below, ≤40 lines\nCannot proceed on the task or its scope → send that question back as STATUS: BLOCKED. Do not ask the user that question.\nSandbox refuses a command (such as EPERM, \"operation not permitted\") → not a FAIL: request the harness escalation prompt once, if it has one; that prompt is allowed. Still refused, or no prompt → STATUS: BLOCKED with the exact command and the denial.\n```\n\nA DO NOT list holds only these items and bans the request or the repository states; it never bans a\ntechnique the request did not ban.\n\nA skeptic's brief replaces GOAL and CONTEXT with `CLAIM: \u003Cfinding + evidence>` and\n`LENS: reproduce | contract | request`. The `request` lens gets the verbatim request and judges the\nresult against it, not against your goal reading. The skeptic's report adds\n`VERDICT: CONFIRMED | REFUTED` with its evidence, and its results file is written the same way.\n\nEvery child returns this report:\n\n```\nREPORT \u003Cid>\nSTATUS: DONE | PARTIAL | BLOCKED | FAILED\nSUMMARY: ≤5 lines\nFINDINGS: - [high|med|low] \u003Cclaim> — \u003Cfile:line | command → output> — confidence \u003Ch|m|l>\nFILES CHANGED: \u003Cpaths|none>   CHECKS: \u003Ccmd> → PASS | FAIL | NOT RUN (\u003Creason>)\nOPEN: \u003Cquestions|none>        RESULTS: \u003Cledger-dir>\u002Fresults\u002F\u003Cid>.md\n```\n\n**The results file.** As its last step, every child that can write files writes\n`\u003Cledger-dir>\u002Fresults\u002F\u003Cid>.md`: first the same `REPORT \u003Cid>` block it returns, unchanged, then any\ndetail past 40 lines. For a child that cannot write files, you write it from the report it returns.\nA file of detail alone is not a results file. That file is the only one a child writes outside its\nwrite set, so \"read-only\" in a brief means read-only except that file. The results files are what\nlet you rebuild the ledger from disk.\n\n## Running waves\n\n- Scout only until you can list the items, then delegate the per-item work.\n- Never do an item's work yourself: every edit, finding, and check of an item comes from a child.\n  The only exceptions are the labeled sequential run and a sandbox-blocked check that the user lets\n  you run, both under Failures and fallback.\n- While children run, do only work that does not overlap theirs. A search you delegated stays\n  delegated.\n- Keep the live children at or under the plan's ceiling, and count every pending child: skeptics,\n  gates, and critics too. Size each wave to the independent items you have, not to the ceiling.\n- Every writer works in the one working tree, the tree the gate checks. Writers run in parallel\n  only on disjoint write sets; overlapping writers run in sequence. Children that build or run the\n  test suite in that tree run one at a time.\n- After each write wave, one gate child runs the project's checks and reports each as PASS or FAIL.\n- A frozen shared contract, pasted unchanged into every brief, decides which side of a seam is\n  wrong.\n- Every test keeps its strength: no child weakens or deletes a test, and no child commits.\n- \"Read-only\" is a rule the brief carries. An agent type does not enforce it in every harness.\n\n## Collecting results\n\n- Key each result by its item id, never by its position.\n- A result with no well-formed `REPORT \u003Cid>` block is FAILED under its id: an empty result, an\n  error, a cancellation, and a missing value alike. Record it before you filter or count anything.\n  A child the user stopped is FAILED with the reason \"stopped by the user\" and is not retried\n  unless the user asks; the rest of the run goes on.\n- A results file that does not start with `REPORT \u003Cid>` is incomplete. Log it, then put the\n  well-formed report the child returned at the top of that file, above the child's detail.\n- Deduplicate each new finding against everything seen so far, refuted findings included, not only\n  against what survived.\n- Report coverage as N of M items DONE, and name every item that is not DONE with its status.\n- An item whose child failed gets a retry, unless the user stopped it, or a report of the failure;\n  never a result you wrote.\n- State every cap you applied: a top-N cut, sampling, a skipped area, a shortened wave.\n\n## Verifying\n\n- Send each material finding to a fresh skeptic: a new child, never a continuation of the producer.\n  The skeptic tries to refute the finding.\n- A high-severity finding, or one an edit will act on, gets two skeptics: one with the lens\n  *reproduce* and one with the lens *contract*.\n- A refutation needs evidence; doubt alone refutes nothing. A finding is CONFIRMED only when no\n  skeptic refutes it.\n- When a skeptic fails, the finding is UNVERIFIED: report it so, neither confirmed nor dropped.\n- Refuted findings stay in the final report, with their reasons.\n- Verifiers and gates run the checks themselves. A worker's account of a check is input, not proof.\n- Once per run, on the synthesized result or after the last write wave, one skeptic takes the\n  `request` lens.\n- An audit, or a task to find every instance, ends with one fresh completeness critic. It gets the\n  verbatim request, the scope, and the ledger, and names missed areas, unverified claims, and unread\n  files. Its gaps get at most one more wave.\n\n## Loops and stop conditions\n\n- A discovery loop stops after 2 rounds in a row that find nothing new, or after 3 rounds in all.\n- A fix-and-review cycle allows at most 2 re-reviews, each by a fresh reviewer given only the change\n  and the open blockers. Only a concern tied to a failing done-when check holds up the work. What\n  is still open after the second re-review goes on the list you give the user at the end.\n- An item that fails twice is BLOCKED.\n- Zero findings skip the downstream waves.\n- A stop-when condition from the plan ends the run: go to the final report.\n\n## Failures and fallback\n\n- Retry a failed item once, unless the user stopped its child, as a new child with a corrected\n  brief. Continue the same child instead\n  only when the failure was a misunderstanding.\n- On a permission denial, a refused launch included, stop that path and report it. A refusal is\n  never a reason to start children another way.\n- A check that the harness sandbox refused (for example `EPERM`, or \"operation not permitted\"),\n  with no approved escalation, did not run. It is never FAIL, and it never counts as a code\n  failure: the child's STATUS is BLOCKED, with the exact command and the denial. Put the\n  escalation on the list you give the user at the end, unless the rest of the run depends on it;\n  with the user's approval you may run the check yourself, as\n  `references\u002Fharness-tools.md` describes, and record the result it then gives. If the user\n  declines, the check stays NOT RUN, with the denial as the reason.\n- If children cannot start at all, or the depth limit stops them, say so. Then run the briefs one by\n  one yourself, label each output with its item id, write each results file, and state in the final\n  report that the verification was not independent.\n\n## Restart\n\nAfter a crash, a lost context, or a new session, rebuild the run from the ledger; never start it\nagain from scratch silently.\n\n1. Re-read the ledger.\n2. Keep the DONE items.\n3. For an item that is not DONE but whose results file holds a complete report, take that report\n   and record its status.\n4. For a RUNNING item without one, continue its child only while the session that started it is\n   still live, as `references\u002Fharness-tools.md` describes. After a session restart, do not continue\n   the old child, even where the harness could reopen it: inspect the item's write set (step 5),\n   then dispatch it again as a new child.\n5. For a write item, inspect `git status` and `git diff` on its write set before you dispatch it\n   again: its work may already be on disk.\n6. Dispatch the rest again.\n7. Tell the user what you reused and what is running again.\n\nA restart is at-least-once, not exactly-once: an item can run twice.\n\n## Final report\n\nClose or finish every child first. Then report:\n\n- the outcome, against the request and each done-when check;\n- the count and the names for each status: DONE, PARTIAL, BLOCKED, FAILED, and UNVERIFIED;\n- the files changed;\n- each check as PASS, FAIL, or NOT RUN, with the reason for every FAIL and NOT RUN;\n- the refuted findings, with their reasons;\n- every cap you applied, and the estimated agent total beside the actual count;\n- every decision held open for the user;\n- the remaining risk;\n- the ledger path.\n","# Verified Waves\n\nYou run one task as waves of sub-agents. You plan, dispatch, record, and verify; the children do\nthe per-item work. One ledger records the run, every child gets a self-contained brief and returns a\nfixed report, and every finding that matters goes to a fresh skeptic before you report it.\n\n## What invoking this means\n\n- The user invoked this skill, so this is their explicit request for parallel sub-agents on this\n  task.\n- If the invocation carries no task, ask for the task and stop there: start no child and create no\n  ledger until the user answers.\n- Read `references\u002Fharness-tools.md` first. It names this harness's tools for starting, waiting on,\n  continuing, and closing children, says where the ledger lives, and says which permission prompts\n  to expect.\n- Then apply the small-task test. The task is **small** when it is one item: one edit or one\n  question, in one place. For a small task, say that it is small and why, and do it directly: no\n  plan, no ledger, no child.\n- A task whose every step needs the previous step's result is **sequential**, not small: it cannot\n  fan out, but it can still use verification. Decide by judgment between doing it directly and\n  doing it directly with a final gate and skeptic wave on its result, and say which in one line.\n- Otherwise, list the independent items and fan out.\n- Only when you are genuinely torn — a borderline small task the user explicitly sent here, or a\n  sequential task where verification may or may not pay — ask once, with your recommendation.\n\n## Plan before any dispatch\n\nWrite the plan in chat before the first child starts:\n\n0. **Request**: the user's words, verbatim, in their language.\n1. **Goal**: one sentence, your reading of the request, labelled as yours.\n2. **Done when**: binary checks, each one PASS or FAIL when it is run.\n3. **Stop when**: the conditions that end the run early, such as a failed gate.\n4. **Shape**: one from the next section.\n5. **Items**: each with an id, a kind (read | write | verify | gate | critic), and its write set\n   (`none` for a read). An id is a lowercase letter, then lowercase letters, digits, or `_`, at most\n   32 characters, such as `audit_04`.\n6. **Waves**: which items run in which wave, the estimated agent total with skeptics, gates, and\n   critics counted, and the ceiling on live children: 6 unless the user names another number for this\n   run, and never above the harness limit that `references\u002Fharness-tools.md` gives. The ceiling is\n   a limit, not a target, and the agent total is not the ceiling: count it from the plan, every\n   item plus its skeptics, gates, and critics.\n7. **Verification plan**: which findings get skeptics, and which checks each gate runs.\n\nThe agent total you announce is an estimate; the final report compares it with the actual count.\nThe only budget is a limit the user sets. Set no other budget and no deadline. A retry of a FAILED\nitem and a fix pass toward the same done-when check are not new scope.\n\nEvery item names the words of the request it serves; cut an item that names none. Verification and\none-off checks use the tools the repository already has: the plan adds no new project, script,\nrunner, or evidence document in the repository unless the request asks for one. An item that would\nchange what the request says done means, a public API, or what existing users of a public surface\nmust write is held as an open decision, with their code before and after; the rest of the run goes on.\n\nAfter you write the plan, start the first wave in the same turn; the plan's questions do not hold\nit up.\n\nThese actions need the user's yes, unless the request already names them: deleting files the\nrequest does not name, discarding uncommitted changes this run did not make, a force-push, a\npublish, anything that touches credentials, and any other action the repository's rules reserve.\nAsk about the ones you can foresee with the plan.\nFinish every item that does not depend on such an action, never take it before an explicit yes,\nand ask about the rest once, at the end, with everything else done.\n\n## Pick the shape\n\nPick the one dominant shape before you write briefs:\n\n- **Sweep**: read-only children cover disjoint areas, and their findings are the output.\n- **Fan-out then synthesis**: children gather, and one agent merges what they found.\n- **Review, verify, fix**: reviewers find, skeptics test each finding, writers fix what survives.\n- **Build waves with gates**: writer waves on disjoint write sets, with a gate child after each.\n- **Draft and critic**: one child drafts, a fresh child critiques, and the drafter revises.\n- **Judge panel**: several children answer one question independently, and one judge compares.\n\nWhen the raw results are the deliverable, the run ends at the fan-out, with no synthesizer. Ranking\nor merging needs one agent that sees every candidate. Verify each item as soon as its producer\nreports, not after the whole wave.\n\n## The ledger\n\nThe ledger is one Markdown file, `\u003Cledger-dir>\u002Fledger.md`. `\u003Cledger-dir>` is\n`verified-waves\u002F\u003Crun-id>\u002F` under the location that `references\u002Fharness-tools.md` names, outside the\nworking tree; `\u003Crun-id>` is short and unique, such as the date, the time, and a slug. Before you\ncreate `\u003Cledger-dir>`, check that it does not exist. If it does, pick another run-id, for example by\nadding a counter: a new run never writes into an existing ledger directory, and only a restart of\nthe same run continues in its own. Tell the user the path. The ledger is never committed.\n\nCreate the ledger and its `results\u002F` directory before the first dispatch, so any permission prompt\nfor that location comes up once, before children run.\n\nThe ledger holds:\n\n- A header: the request verbatim, your goal reading, done-when checks, stop-when conditions, waves,\n  the estimated agent total, and the ceiling.\n- One row per item, under this header:\n\n  ```\n  | id | kind | write set | status | handle | result path |\n  ```\n\n  `handle` is the harness's identifier for the child. The status is one of `PENDING`, `RUNNING`,\n  `DONE`, `PARTIAL`, `BLOCKED`, `FAILED`, or `UNVERIFIED`.\n- An append-only log: one line for each dispatch, result, retry, verdict, and cap, with its item id.\n\nUpdate the ledger at each event, not at the end.\n\n## Briefs and reports\n\nA child starts without your context. Give each child one brief in this form, every field filled:\n\n```\nITEM \u003Cid> — read | write | verify | gate | critic\nGOAL: \u003Cone action>. The parent will use your result to \u003Cdecision>.\nCONTEXT: \u003Cexact paths, prior findings; shared contract pasted unchanged>\nSCOPE: read-only | write only: \u003Cpaths>   (either way, also your results file)\nDO: \u003Cmusts>   DO NOT: commit, push, edit outside scope, weaken\u002Fdelete tests, write long-term memory, ask the user a task or scope question\n[writers] Other agents edit other files now; do not revert or reformat changes you did not make.\nDONE WHEN: \u003Cbinary observable check>\nLAST STEP: write \u003Cledger-dir>\u002Fresults\u002F\u003Cid>.md: first the REPORT block you return, unchanged, then any detail past 40 lines; if you cannot write files, return the report only\nRETURN: the report below, ≤40 lines\nCannot proceed on the task or its scope → send that question back as STATUS: BLOCKED. Do not ask the user that question.\nSandbox refuses a command (such as EPERM, \"operation not permitted\") → not a FAIL: request the harness escalation prompt once, if it has one; that prompt is allowed. Still refused, or no prompt → STATUS: BLOCKED with the exact command and the denial.\n```\n\nA DO NOT list holds only these items and bans the request or the repository states; it never bans a\ntechnique the request did not ban.\n\nA skeptic's brief replaces GOAL and CONTEXT with `CLAIM: \u003Cfinding + evidence>` and\n`LENS: reproduce | contract | request`. The `request` lens gets the verbatim request and judges the\nresult against it, not against your goal reading. The skeptic's report adds\n`VERDICT: CONFIRMED | REFUTED` with its evidence, and its results file is written the same way.\n\nEvery child returns this report:\n\n```\nREPORT \u003Cid>\nSTATUS: DONE | PARTIAL | BLOCKED | FAILED\nSUMMARY: ≤5 lines\nFINDINGS: - [high|med|low] \u003Cclaim> — \u003Cfile:line | command → output> — confidence \u003Ch|m|l>\nFILES CHANGED: \u003Cpaths|none>   CHECKS: \u003Ccmd> → PASS | FAIL | NOT RUN (\u003Creason>)\nOPEN: \u003Cquestions|none>        RESULTS: \u003Cledger-dir>\u002Fresults\u002F\u003Cid>.md\n```\n\n**The results file.** As its last step, every child that can write files writes\n`\u003Cledger-dir>\u002Fresults\u002F\u003Cid>.md`: first the same `REPORT \u003Cid>` block it returns, unchanged, then any\ndetail past 40 lines. For a child that cannot write files, you write it from the report it returns.\nA file of detail alone is not a results file. That file is the only one a child writes outside its\nwrite set, so \"read-only\" in a brief means read-only except that file. The results files are what\nlet you rebuild the ledger from disk.\n\n## Running waves\n\n- Scout only until you can list the items, then delegate the per-item work.\n- Never do an item's work yourself: every edit, finding, and check of an item comes from a child.\n  The only exceptions are the labeled sequential run and a sandbox-blocked check that the user lets\n  you run, both under Failures and fallback.\n- While children run, do only work that does not overlap theirs. A search you delegated stays\n  delegated.\n- Keep the live children at or under the plan's ceiling, and count every pending child: skeptics,\n  gates, and critics too. Size each wave to the independent items you have, not to the ceiling.\n- Every writer works in the one working tree, the tree the gate checks. Writers run in parallel\n  only on disjoint write sets; overlapping writers run in sequence. Children that build or run the\n  test suite in that tree run one at a time.\n- After each write wave, one gate child runs the project's checks and reports each as PASS or FAIL.\n- A frozen shared contract, pasted unchanged into every brief, decides which side of a seam is\n  wrong.\n- Every test keeps its strength: no child weakens or deletes a test, and no child commits.\n- \"Read-only\" is a rule the brief carries. An agent type does not enforce it in every harness.\n\n## Collecting results\n\n- Key each result by its item id, never by its position.\n- A result with no well-formed `REPORT \u003Cid>` block is FAILED under its id: an empty result, an\n  error, a cancellation, and a missing value alike. Record it before you filter or count anything.\n  A child the user stopped is FAILED with the reason \"stopped by the user\" and is not retried\n  unless the user asks; the rest of the run goes on.\n- A results file that does not start with `REPORT \u003Cid>` is incomplete. Log it, then put the\n  well-formed report the child returned at the top of that file, above the child's detail.\n- Deduplicate each new finding against everything seen so far, refuted findings included, not only\n  against what survived.\n- Report coverage as N of M items DONE, and name every item that is not DONE with its status.\n- An item whose child failed gets a retry, unless the user stopped it, or a report of the failure;\n  never a result you wrote.\n- State every cap you applied: a top-N cut, sampling, a skipped area, a shortened wave.\n\n## Verifying\n\n- Send each material finding to a fresh skeptic: a new child, never a continuation of the producer.\n  The skeptic tries to refute the finding.\n- A high-severity finding, or one an edit will act on, gets two skeptics: one with the lens\n  *reproduce* and one with the lens *contract*.\n- A refutation needs evidence; doubt alone refutes nothing. A finding is CONFIRMED only when no\n  skeptic refutes it.\n- When a skeptic fails, the finding is UNVERIFIED: report it so, neither confirmed nor dropped.\n- Refuted findings stay in the final report, with their reasons.\n- Verifiers and gates run the checks themselves. A worker's account of a check is input, not proof.\n- Once per run, on the synthesized result or after the last write wave, one skeptic takes the\n  `request` lens.\n- An audit, or a task to find every instance, ends with one fresh completeness critic. It gets the\n  verbatim request, the scope, and the ledger, and names missed areas, unverified claims, and unread\n  files. Its gaps get at most one more wave.\n\n## Loops and stop conditions\n\n- A discovery loop stops after 2 rounds in a row that find nothing new, or after 3 rounds in all.\n- A fix-and-review cycle allows at most 2 re-reviews, each by a fresh reviewer given only the change\n  and the open blockers. Only a concern tied to a failing done-when check holds up the work. What\n  is still open after the second re-review goes on the list you give the user at the end.\n- An item that fails twice is BLOCKED.\n- Zero findings skip the downstream waves.\n- A stop-when condition from the plan ends the run: go to the final report.\n\n## Failures and fallback\n\n- Retry a failed item once, unless the user stopped its child, as a new child with a corrected\n  brief. Continue the same child instead\n  only when the failure was a misunderstanding.\n- On a permission denial, a refused launch included, stop that path and report it. A refusal is\n  never a reason to start children another way.\n- A check that the harness sandbox refused (for example `EPERM`, or \"operation not permitted\"),\n  with no approved escalation, did not run. It is never FAIL, and it never counts as a code\n  failure: the child's STATUS is BLOCKED, with the exact command and the denial. Put the\n  escalation on the list you give the user at the end, unless the rest of the run depends on it;\n  with the user's approval you may run the check yourself, as\n  `references\u002Fharness-tools.md` describes, and record the result it then gives. If the user\n  declines, the check stays NOT RUN, with the denial as the reason.\n- If children cannot start at all, or the depth limit stops them, say so. Then run the briefs one by\n  one yourself, label each output with its item id, write each results file, and state in the final\n  report that the verification was not independent.\n\n## Restart\n\nAfter a crash, a lost context, or a new session, rebuild the run from the ledger; never start it\nagain from scratch silently.\n\n1. Re-read the ledger.\n2. Keep the DONE items.\n3. For an item that is not DONE but whose results file holds a complete report, take that report\n   and record its status.\n4. For a RUNNING item without one, continue its child only while the session that started it is\n   still live, as `references\u002Fharness-tools.md` describes. After a session restart, do not continue\n   the old child, even where the harness could reopen it: inspect the item's write set (step 5),\n   then dispatch it again as a new child.\n5. For a write item, inspect `git status` and `git diff` on its write set before you dispatch it\n   again: its work may already be on disk.\n6. Dispatch the rest again.\n7. Tell the user what you reused and what is running again.\n\nA restart is at-least-once, not exactly-once: an item can run twice.\n\n## Final report\n\nClose or finish every child first. Then report:\n\n- the outcome, against the request and each done-when check;\n- the count and the names for each status: DONE, PARTIAL, BLOCKED, FAILED, and UNVERIFIED;\n- the files changed;\n- each check as PASS, FAIL, or NOT RUN, with the reason for every FAIL and NOT RUN;\n- the refuted findings, with their reasons;\n- every cap you applied, and the estimated agent total beside the actual count;\n- every decision held open for the user;\n- the remaining risk;\n- the ledger path.\n",{"name":5,"description":7},"master","b30b1c1908dbc56a8184128f18803053d762ccb5","codex\u002Fdeniz-coordination\u002Fskills\u002Fverified-waves",0,"https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins","https:\u002F\u002Fgithub.com\u002FBlind-Striker","denizirgin.com","VP of Engineering - \r\n@armutcom @homeruntech @prontopro\r\n |  Speaker \r\n@CodeFiction\r\n, http:\u002F\u002Fcodefiction.tech | Developer, gamer, blogger, maiden iron fan","2026-11-13 00:23:18",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add Blind-Striker\u002Fagent-skills-and-plugins --skill verified-waves",{"tool":39,"command":40},"bunx","bunx skills add Blind-Striker\u002Fagent-skills-and-plugins --skill verified-waves",{"tool":42,"command":43},"pnpm","pnpm dlx skills add Blind-Striker\u002Fagent-skills-and-plugins --skill verified-waves","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins\u002Fblob\u002Fmaster\u002Fcodex\u002Fdeniz-coordination\u002Fskills\u002Fverified-waves\u002FSKILL.md",true,[47,53],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"agents\u002Fopenai.yaml","REFERENCE","参考文档",228,"https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins\u002Fblob\u002Fmaster\u002Fcodex\u002Fdeniz-coordination\u002Fskills\u002Fverified-waves\u002Fagents\u002Fopenai.yaml",{"path":54,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":55,"sourceHtmlUrl":56},"references\u002Fharness-tools.md",5391,"https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins\u002Fblob\u002Fmaster\u002Fcodex\u002Fdeniz-coordination\u002Fskills\u002Fverified-waves\u002Freferences\u002Fharness-tools.md",[58,65,72,79,84,91],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M79YGWBJ52PHMSTKJ3RJ3AWR","writing-tunit-tests","Write tests in TUnit — the attributes, the async assertion model, data-driven cases, lifecycle hooks, and the parallelism rules. USE FOR writing or fixing a test in a TUnit project, translating a test idea into TUnit syntax, or reviewing TUnit test code for API mistakes. DO NOT USE FOR deciding what to test, judging whether a test is any good, or running tests.","https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins\u002Fblob\u002Fmaster\u002Fskills\u002Fdeniz-dotnet-general\u002Fwriting-tunit-tests\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M79YGR3Y9RCRS6TD71D0KKP8","dotnet-walls","Walls for a .NET change in a repository without its own quality gates — pinned, ephemeral analyzer, format, clone and scanner commands for the verify step, their identity ratchet, and the build traps. Use during a walls preflight, or when a worker's verify step needs .NET quality gates.","https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins\u002Fblob\u002Fmaster\u002Fskills\u002Fdeniz-dotnet-general\u002Fdotnet-walls\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M79YGFNJBST7D803NQW3SBYM","csharp-15","Write, review and modernize C# 15 (.NET 11) code correctly. Covers every C# 15 feature - collection expression arguments (`[with(...), ...]`), union types (`union`, `[Union]`, `IUnion`, custom unions), closed class hierarchies (`closed`), extension indexers, labeled `break`\u002F`continue`, non-virtual static interface members on runtimes without default interface methods, and the preview memory-safety model (`unsafe(expr)`, `safe`, requires-unsafe members). Use when code targets net11.0 or LangVersion 15\u002Fpreview, when the user mentions any of these features, when replacing marker interfaces, OneOf-style results, `goto`\u002Fflag loop exits or capacity\u002Fcomparer boilerplate, or when the build reports CS8121, CS8509, CS8655, CS8510, CS0121\u002FCS0411 on a `with(...)` element, CS9370, CS9380 or CS9363.","https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins\u002Fblob\u002Fmaster\u002Fskills\u002Fdeniz-dotnet-general\u002Fcsharp-15\u002FSKILL.md",[],[],{"skillNo":80,"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":81,"categories":82,"keywords":83,"publishedAt":19},"01M79YGAV031473HSX6FN87ENH","https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins\u002Fblob\u002Fmaster\u002Fskills\u002Fdeniz-coordination\u002Fverified-waves\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M79YG6QXNND4WRPP3GATSY8J","harness","The bundled dispatch harness, which runs a task file on worker models through OpenCode or Codex, fences their writes, escalates their asks to the operator, settles each result from git and its verify commands, and records every step in a ledger. Its commands, task file, modes and write fence, configuration, runs and their recovery, ledger and exit codes.","https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins\u002Fblob\u002Fmaster\u002Fskills\u002Fdeniz-coordination\u002Fharness\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":19},"01M79YG2P5S91SDTA5912XJ4FV","delegating-to-worker-models","Use when you hand off implementation, a plan, research a decision will rely on, or a review, and you brief the worker and check what comes back. A subagent that searches, reads in parallel, or keeps your context small is ordinary tool use. Covers what stays with you, the mechanism, assigning work by strength, the walls preflight, prompts without contradictions, the worker contract and model profiles, evidence from your own run, review, and the fix-up loop.","https:\u002F\u002Fgithub.com\u002FBlind-Striker\u002Fagent-skills-and-plugins\u002Fblob\u002Fmaster\u002Fskills\u002Fdeniz-coordination\u002Fdelegating-to-worker-models\u002FSKILL.md",[],[]]