[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CQTVFQRV3P1T2XCWWF7WHX":3,"skill-same:01M6CQTVFQRV3P1T2XCWWF7WHX":84},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M6CQTVFQRV3P1T2XCWWF7WHX","defect-sweep",null,"Fresh-context sweep of an existing subsystem's perimeter for defect classes nobody is looking for (inherited defaults, sibling writers, incomplete gates, fail-open error paths, silent truncation, stale assertions, identity confusion, time-based inference, unasked authorization), with proof per finding, at .gener8v\u002Fsweeps\u002F. Use after a burst of changes, before a launch, or when a found defect may have siblings, such as 'are there more bugs like this one' or 'sweep the billing module'. Not for one delivery (code-review), decay over time (rot-watch) or pipeline documents (audit).","gener8v\u002Fgener8v.claude-skills","gener8v","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F262388633?v=4","01M6CQT9VAG2MX3NN1CBMGR2T8","GENER8V","01M6CQT9YZXXYFF41ZYFW774DQ",3,"MIT","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdefect-sweep\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"defect sweep","sweep","audit","stale","use","context","open","authorization","pipeline","directory","code-review","code","sweeper","documents","identity","launch","inference","review","2026-11-10 10:12:30",false,"---\nname: defect-sweep\ndescription: \"Fresh-context sweep of an existing subsystem's perimeter for defect classes nobody is looking for (inherited defaults, sibling writers, incomplete gates, fail-open error paths, silent truncation, stale assertions, identity confusion, time-based inference, unasked authorization), with proof per finding, at .gener8v\u002Fsweeps\u002F. Use after a burst of changes, before a launch, or when a found defect may have siblings, such as 'are there more bugs like this one' or 'sweep the billing module'. Not for one delivery (code-review), decay over time (rot-watch) or pipeline documents (audit).\"\nargument-hint: \"[subsystem, directory or entry point]\"\ncontext: fork\nagent: defect-sweeper\neffort: xhigh\n---\n\n# Defect Sweep Skill\n\n**Invoked with:** `$ARGUMENTS`\n\nIf that is empty, ask the user which subsystem to sweep and where its edges are before doing anything else. Never guess the target.\n\n## Purpose\n\nSearch existing code for defects that nobody is looking for. This skill is not anchored to\na delivery, a ticket, or a spec — it takes a subsystem and sweeps it for known defect\nclasses, reporting what it finds and proving each finding is real.\n\nIt is the complement to the three review skills. Code Review asks *did you build the right\nthing*, Quality Review asks *did you build it well*, Security Review asks *is it safe* —\nand all three review **what was just built**. None of them looks at the code around it.\nThat perimeter is where a large share of real defects live, because it is the code nobody\nhas a reason to open: a callee whose defaults you inherited, a sibling route that writes\nthe same table, a control that claims coverage it does not have.\n\nBuilding and sweeping are different modes. A builder verifies the thing they made and is\nincurious about its neighbours — which is exactly the blind spot this skill exists to\ncover, and why it runs as a fresh pass rather than folded into Delivery: this skill's\nfrontmatter forks it into the `defect-sweeper` agent, so the sweep never inherits the\nbuilder's context. It runs on that agent's model (opus · high, the `review-security` default); to follow a\ndifferent route set in Tower, start the `defect-sweeper` agent yourself on the route for `review-security`\n(CONVENTIONS §13). The agent writes the sweep and returns; the user reads it in the main\nsession.\n\n## When to Use\n\nUse this skill when:\n- A subsystem has taken several changes in a short window and nobody has looked at it whole\n- A control, gate, or guard was recently added and its coverage has not been enumerated\n- Code was delivered fast under deadline and the perimeter was not swept\n- A defect was found and you want to know whether it has siblings\n- Before a launch, over the surface that a launch will expose\n- Periodically, over the subsystems that carry the most consequence\n\nDo **not** use this skill to review a specific delivery — that is Code Review. Do not use\nit to check pipeline documents — that is Audit.\n\n## Input\n\n**Source:** A subsystem, named by directory, feature, or entry point\n**Read from:**\n- The named code and everything it calls\n- Everything that calls the named code\n- Tests covering it\n- `CLAUDE.md` \u002F `CONTRIBUTING.md` for repo-specific rules a sweep should enforce\n- `.gener8v\u002Fsweeps\u002F\u003Csubsystem-slug>-sweep.md` from the previous sweep of the same subsystem, if any —\n  to say which earlier findings were fixed, which are still open, and which are new\n\n**Nothing from `.gener8v\u002F` is required.** This skill works on repositories that have never\nrun the pipeline, which is the common case for the code most worth sweeping. It creates\n`.gener8v\u002Fsweeps\u002F` if needed; that does not make the project \"on the pipeline\" (that is\n`.gener8v\u002Fprd.md`), and Setup\u002FBrownfield still run normally afterwards.\n\n## Output\n\n**Write to:** `.gener8v\u002Fsweeps\u002F\u003Csubsystem-slug>-sweep.md` (or a path the user names)\n\nA findings document, ordered by consequence. Each finding states what breaks, in what\ncircumstance, and carries the evidence that makes it checkable rather than plausible.\n\n## Output Format\n\nWrite the sweep in the shape of `assets\u002Fsweep-report.md` — Read it before writing and follow it exactly, section order included. `gener8v-state.py metrics` counts its `### DS-NNN` headings as sweep findings, so keep that heading form; `Swept and clean` and `Scope` are what make the sweep's boundary legible, so neither is optional.\n\n## Defect Classes\n\nEach class is a question to ask of the subsystem, not a rule to check. The full description of\neach — what it looks like, the question, and the smell that gives it away — is in\n`references\u002Fdefect-classes.md` (relative to this skill's directory). **Read it before sweeping.**\n\n- **Inherited defaults** — for every function this code calls, what does it do when an argument is absent?\n- **Sibling writers** — what else reads or writes this table, this file, this key?\n- **Incomplete gates** — enumerate every entry point into the guarded capability; is each one checked?\n- **Fail-open on the error path** — for every guard, what happens when its input cannot be read?\n- **Silent truncation** — can this return fewer things than exist, and does the caller learn that it did?\n- **Stale assertions** — for each comment describing what the system does, is it true of the system?\n- **Identity confusion** — what is this row keyed by, and does that key survive the operations applied to its subject?\n- **Time-based inference** — does this clock keep running during states where the expected actor could not act?\n- **Unasked authorization** — for every route returning person-level data, what permission does it require, and does the middleware actually supply what it is assumed to?\n- **Over-serving the client** — what does the renderer actually read, and what is it handed?\n\n## Principles\n\n### A finding is a failure, not a smell\n\nEvery finding names a circumstance in which something breaks. \"This is fragile\" is not a\nfinding. If the circumstance cannot be stated, it belongs in Quality Review.\n\n### Prove it or drop it\n\nA finding that has not been checked against the running system or a test is a hypothesis.\nSay which it is. A sweep whose findings are half-real teaches the reader to discount all\nof them — and the next real one goes unfixed.\n\n### State the proof as a falsifiable claim\n\nNot \"tests pass\". *\"Remove the gate and four targeted tests fail.\"* The reader can run it.\nThis is also the only honest way to show a test would have caught the defect.\n\n### Consequence first, mechanism second\n\nLead with what breaks and for whom. A reader triaging twelve findings needs the impact in\nthe first sentence; the code path is what they read once they care.\n\n### Say where you stopped\n\nA sweep is bounded. Name the classes checked, the classes skipped, and the code left\nunopened. Coverage silently omitted reads as coverage achieved.\n\n### Bundling needs a stated reason\n\nSeveral defects in one subsystem may share a change, but the reader must be told why.\nState the rationale at the top: *\"five defects in one subsystem; each needs its own\nsentence to be reviewable, and splitting them would put five one-line changes through the\nsame two files.\"* Absent that, one defect per change.\n\n### Sweep the code, not the author\n\nFindings describe code. A sweep that reads as a verdict on whoever wrote it gets argued\nwith instead of fixed — and the person best placed to confirm a finding is usually its\nauthor.\n\n## Process\n\n1. **Bound the sweep.** Name the subsystem and its edges. Write down what is out of scope\n   before starting, so the boundary is a decision rather than wherever attention ran out.\n\n2. **Map the perimeter.** Before reading the subsystem's own logic, enumerate:\n   - every function it calls, and what each does with absent arguments\n   - every caller of its entry points\n   - every other writer to the resources it owns\n   - every entry point into any capability it guards\n\n   This step is the skill. The subsystem's own code is usually the part that has been read\n   the most; the perimeter is the part nobody has opened.\n\n3. **Run each class.** Take the defect classes in turn, as described in\n   `references\u002Fdefect-classes.md`. Most will find nothing — record that they were run.\n\n4. **Check every assertion.** Grep the subsystem's comments for claims about behaviour and\n   verify each against the code. Counts, names, and capabilities especially.\n\n5. **Prove each finding.** Reproduce it, write a failing test, or run the query. Downgrade\n   anything that will not reproduce to a hypothesis and say so.\n\n6. **Order by consequence**, not by discovery order or severity label. What hurts most,\n   soonest, to the most people.\n\n7. **Report what was clean**, and where the sweep stopped.\n\n## Example\n\nA sweep of a subsystem's stop controls (pause, cancel, a recent delete) on a project that is not on\nthe pipeline: two proven findings — a time-based inference that dead-letters paused work, and an\nincomplete gate found through a stale assertion — the classes swept clean, and a Verdict that\nopens a `fix-\u003Csubsystem-slug>` change for the tickets. It lives at `references\u002Fexample.md`\n(relative to this skill's directory). Read it before producing your first artifact of this kind.\n\n## Troubleshooting\n\n- **The sweep covered the wrong code, or all of it.** The `defect-sweeper` agent sees this skill and\n  its arguments, not the conversation that led here. \"Sweep billing\" after an hour on the webhook\n  handler sweeps all of billing. Put the boundary in the argument — the entry point or directory, and\n  what is out of scope: `\u002Fgener8v:defect-sweep api\u002Fbilling\u002Fwebhooks — not the invoice renderer`.\n- **The agent came back asking which subsystem to sweep.** The argument was empty, and a fork cannot\n  recover the target from the conversation. Re-invoke with the subsystem named; do not answer the\n  question in the main session and expect the agent to hear it.\n- **A finding cannot be proven here** — no test runner, no database, no way to reproduce. Keep it only\n  as a hypothesis, labelled as one, with the proof written as the falsifiable claim someone with the\n  environment can run. Step 5 already downgrades it; the report must not let it read as proven.\n- **Since the last sweep came out empty although the subsystem was swept before.** The carry-forward\n  reads `.gener8v\u002Fsweeps\u002F\u003Csubsystem-slug>-sweep.md`; a sweep under a different slug starts a second\n  file and loses the history. Reuse the slug already in `.gener8v\u002Fsweeps\u002F`; if the subsystem was\n  renamed, read the old file for the carry-forward and say so under Scope.\n- **Orchestrate's metrics show fewer sweep findings than the sweep has.** `gener8v-state.py metrics`\n  counts headings that match `### DS-` plus at least three digits. `### DS-1`, `## DS-001` or a\n  finding without its own heading is not counted — keep the heading form in `assets\u002Fsweep-report.md`.\n\n## Integration with Other Skills\n\n**Upstream:** none required. Reads the code, its tests, `CLAUDE.md`, and the previous sweep of the same\nsubsystem.\n\n**Downstream:**\n- **Ticket Breakdown**: findings the Verdict says to fix now become tickets (cite `DS-XXX`), each a new\n  `TICKET-NNN.md` appended to `changes\u002F\u003Cchange-slug>\u002Ftickets\u002F\u003Carea-slug>\u002F` of the active change — IDs\n  above the current maximum in that directory — the owning capability area's breakdown, or a breakdown\n  for the subsystem when the project has no capability areas. When several changes are active, the user\n  names one. A fix is then a normal Delivery with its three reviews.\n- **Planning**: when no change is active, open a new change `fix-\u003Csubsystem-slug>` via Planning first\n  (Why: the sweep; Outcome: the findings closed; Priority Cut from the Verdict), then break the findings\n  down under it.\n- **Orchestrate**: lists sweeps under `cross_cutting.sweeps` and recommends a sweep when three or more\n  deliveries have landed in one capability area since the last one, or before a launch.\n- **Audit**: checks that every finding names a circumstance and carries proof, and that the sweep says\n  where it stopped.\n- **Quality Review** is the home for smells that are not failures; a sweep finding that cannot state a\n  breaking circumstance is handed there, not dropped.\n\n## Revisions\n\n- A sweep is point-in-time. Re-run after a burst of changes to the same subsystem, before a launch that\n  exposes it, or when a defect found elsewhere may have siblings here.\n- Re-running writes a new sweep file (`\u003Csubsystem-slug>-sweep.md` is replaced; the previous verdict is\n  summarised in **Since the last sweep**) so a reader sees what was fixed and what is still open.\n- Periodic sweeps over the subsystems that carry the most consequence are a good use of a scheduled\n  routine (`\u002Fschedule`) or a cron-driven session; the plugin ships no schedule because the cadence is\n  the project's decision.\n","# Defect Sweep Skill\n\n**Invoked with:** `$ARGUMENTS`\n\nIf that is empty, ask the user which subsystem to sweep and where its edges are before doing anything else. Never guess the target.\n\n## Purpose\n\nSearch existing code for defects that nobody is looking for. This skill is not anchored to\na delivery, a ticket, or a spec — it takes a subsystem and sweeps it for known defect\nclasses, reporting what it finds and proving each finding is real.\n\nIt is the complement to the three review skills. Code Review asks *did you build the right\nthing*, Quality Review asks *did you build it well*, Security Review asks *is it safe* —\nand all three review **what was just built**. None of them looks at the code around it.\nThat perimeter is where a large share of real defects live, because it is the code nobody\nhas a reason to open: a callee whose defaults you inherited, a sibling route that writes\nthe same table, a control that claims coverage it does not have.\n\nBuilding and sweeping are different modes. A builder verifies the thing they made and is\nincurious about its neighbours — which is exactly the blind spot this skill exists to\ncover, and why it runs as a fresh pass rather than folded into Delivery: this skill's\nfrontmatter forks it into the `defect-sweeper` agent, so the sweep never inherits the\nbuilder's context. It runs on that agent's model (opus · high, the `review-security` default); to follow a\ndifferent route set in Tower, start the `defect-sweeper` agent yourself on the route for `review-security`\n(CONVENTIONS §13). The agent writes the sweep and returns; the user reads it in the main\nsession.\n\n## When to Use\n\nUse this skill when:\n- A subsystem has taken several changes in a short window and nobody has looked at it whole\n- A control, gate, or guard was recently added and its coverage has not been enumerated\n- Code was delivered fast under deadline and the perimeter was not swept\n- A defect was found and you want to know whether it has siblings\n- Before a launch, over the surface that a launch will expose\n- Periodically, over the subsystems that carry the most consequence\n\nDo **not** use this skill to review a specific delivery — that is Code Review. Do not use\nit to check pipeline documents — that is Audit.\n\n## Input\n\n**Source:** A subsystem, named by directory, feature, or entry point\n**Read from:**\n- The named code and everything it calls\n- Everything that calls the named code\n- Tests covering it\n- `CLAUDE.md` \u002F `CONTRIBUTING.md` for repo-specific rules a sweep should enforce\n- `.gener8v\u002Fsweeps\u002F\u003Csubsystem-slug>-sweep.md` from the previous sweep of the same subsystem, if any —\n  to say which earlier findings were fixed, which are still open, and which are new\n\n**Nothing from `.gener8v\u002F` is required.** This skill works on repositories that have never\nrun the pipeline, which is the common case for the code most worth sweeping. It creates\n`.gener8v\u002Fsweeps\u002F` if needed; that does not make the project \"on the pipeline\" (that is\n`.gener8v\u002Fprd.md`), and Setup\u002FBrownfield still run normally afterwards.\n\n## Output\n\n**Write to:** `.gener8v\u002Fsweeps\u002F\u003Csubsystem-slug>-sweep.md` (or a path the user names)\n\nA findings document, ordered by consequence. Each finding states what breaks, in what\ncircumstance, and carries the evidence that makes it checkable rather than plausible.\n\n## Output Format\n\nWrite the sweep in the shape of `assets\u002Fsweep-report.md` — Read it before writing and follow it exactly, section order included. `gener8v-state.py metrics` counts its `### DS-NNN` headings as sweep findings, so keep that heading form; `Swept and clean` and `Scope` are what make the sweep's boundary legible, so neither is optional.\n\n## Defect Classes\n\nEach class is a question to ask of the subsystem, not a rule to check. The full description of\neach — what it looks like, the question, and the smell that gives it away — is in\n`references\u002Fdefect-classes.md` (relative to this skill's directory). **Read it before sweeping.**\n\n- **Inherited defaults** — for every function this code calls, what does it do when an argument is absent?\n- **Sibling writers** — what else reads or writes this table, this file, this key?\n- **Incomplete gates** — enumerate every entry point into the guarded capability; is each one checked?\n- **Fail-open on the error path** — for every guard, what happens when its input cannot be read?\n- **Silent truncation** — can this return fewer things than exist, and does the caller learn that it did?\n- **Stale assertions** — for each comment describing what the system does, is it true of the system?\n- **Identity confusion** — what is this row keyed by, and does that key survive the operations applied to its subject?\n- **Time-based inference** — does this clock keep running during states where the expected actor could not act?\n- **Unasked authorization** — for every route returning person-level data, what permission does it require, and does the middleware actually supply what it is assumed to?\n- **Over-serving the client** — what does the renderer actually read, and what is it handed?\n\n## Principles\n\n### A finding is a failure, not a smell\n\nEvery finding names a circumstance in which something breaks. \"This is fragile\" is not a\nfinding. If the circumstance cannot be stated, it belongs in Quality Review.\n\n### Prove it or drop it\n\nA finding that has not been checked against the running system or a test is a hypothesis.\nSay which it is. A sweep whose findings are half-real teaches the reader to discount all\nof them — and the next real one goes unfixed.\n\n### State the proof as a falsifiable claim\n\nNot \"tests pass\". *\"Remove the gate and four targeted tests fail.\"* The reader can run it.\nThis is also the only honest way to show a test would have caught the defect.\n\n### Consequence first, mechanism second\n\nLead with what breaks and for whom. A reader triaging twelve findings needs the impact in\nthe first sentence; the code path is what they read once they care.\n\n### Say where you stopped\n\nA sweep is bounded. Name the classes checked, the classes skipped, and the code left\nunopened. Coverage silently omitted reads as coverage achieved.\n\n### Bundling needs a stated reason\n\nSeveral defects in one subsystem may share a change, but the reader must be told why.\nState the rationale at the top: *\"five defects in one subsystem; each needs its own\nsentence to be reviewable, and splitting them would put five one-line changes through the\nsame two files.\"* Absent that, one defect per change.\n\n### Sweep the code, not the author\n\nFindings describe code. A sweep that reads as a verdict on whoever wrote it gets argued\nwith instead of fixed — and the person best placed to confirm a finding is usually its\nauthor.\n\n## Process\n\n1. **Bound the sweep.** Name the subsystem and its edges. Write down what is out of scope\n   before starting, so the boundary is a decision rather than wherever attention ran out.\n\n2. **Map the perimeter.** Before reading the subsystem's own logic, enumerate:\n   - every function it calls, and what each does with absent arguments\n   - every caller of its entry points\n   - every other writer to the resources it owns\n   - every entry point into any capability it guards\n\n   This step is the skill. The subsystem's own code is usually the part that has been read\n   the most; the perimeter is the part nobody has opened.\n\n3. **Run each class.** Take the defect classes in turn, as described in\n   `references\u002Fdefect-classes.md`. Most will find nothing — record that they were run.\n\n4. **Check every assertion.** Grep the subsystem's comments for claims about behaviour and\n   verify each against the code. Counts, names, and capabilities especially.\n\n5. **Prove each finding.** Reproduce it, write a failing test, or run the query. Downgrade\n   anything that will not reproduce to a hypothesis and say so.\n\n6. **Order by consequence**, not by discovery order or severity label. What hurts most,\n   soonest, to the most people.\n\n7. **Report what was clean**, and where the sweep stopped.\n\n## Example\n\nA sweep of a subsystem's stop controls (pause, cancel, a recent delete) on a project that is not on\nthe pipeline: two proven findings — a time-based inference that dead-letters paused work, and an\nincomplete gate found through a stale assertion — the classes swept clean, and a Verdict that\nopens a `fix-\u003Csubsystem-slug>` change for the tickets. It lives at `references\u002Fexample.md`\n(relative to this skill's directory). Read it before producing your first artifact of this kind.\n\n## Troubleshooting\n\n- **The sweep covered the wrong code, or all of it.** The `defect-sweeper` agent sees this skill and\n  its arguments, not the conversation that led here. \"Sweep billing\" after an hour on the webhook\n  handler sweeps all of billing. Put the boundary in the argument — the entry point or directory, and\n  what is out of scope: `\u002Fgener8v:defect-sweep api\u002Fbilling\u002Fwebhooks — not the invoice renderer`.\n- **The agent came back asking which subsystem to sweep.** The argument was empty, and a fork cannot\n  recover the target from the conversation. Re-invoke with the subsystem named; do not answer the\n  question in the main session and expect the agent to hear it.\n- **A finding cannot be proven here** — no test runner, no database, no way to reproduce. Keep it only\n  as a hypothesis, labelled as one, with the proof written as the falsifiable claim someone with the\n  environment can run. Step 5 already downgrades it; the report must not let it read as proven.\n- **Since the last sweep came out empty although the subsystem was swept before.** The carry-forward\n  reads `.gener8v\u002Fsweeps\u002F\u003Csubsystem-slug>-sweep.md`; a sweep under a different slug starts a second\n  file and loses the history. Reuse the slug already in `.gener8v\u002Fsweeps\u002F`; if the subsystem was\n  renamed, read the old file for the carry-forward and say so under Scope.\n- **Orchestrate's metrics show fewer sweep findings than the sweep has.** `gener8v-state.py metrics`\n  counts headings that match `### DS-` plus at least three digits. `### DS-1`, `## DS-001` or a\n  finding without its own heading is not counted — keep the heading form in `assets\u002Fsweep-report.md`.\n\n## Integration with Other Skills\n\n**Upstream:** none required. Reads the code, its tests, `CLAUDE.md`, and the previous sweep of the same\nsubsystem.\n\n**Downstream:**\n- **Ticket Breakdown**: findings the Verdict says to fix now become tickets (cite `DS-XXX`), each a new\n  `TICKET-NNN.md` appended to `changes\u002F\u003Cchange-slug>\u002Ftickets\u002F\u003Carea-slug>\u002F` of the active change — IDs\n  above the current maximum in that directory — the owning capability area's breakdown, or a breakdown\n  for the subsystem when the project has no capability areas. When several changes are active, the user\n  names one. A fix is then a normal Delivery with its three reviews.\n- **Planning**: when no change is active, open a new change `fix-\u003Csubsystem-slug>` via Planning first\n  (Why: the sweep; Outcome: the findings closed; Priority Cut from the Verdict), then break the findings\n  down under it.\n- **Orchestrate**: lists sweeps under `cross_cutting.sweeps` and recommends a sweep when three or more\n  deliveries have landed in one capability area since the last one, or before a launch.\n- **Audit**: checks that every finding names a circumstance and carries proof, and that the sweep says\n  where it stopped.\n- **Quality Review** is the home for smells that are not failures; a sweep finding that cannot state a\n  breaking circumstance is handed there, not dropped.\n\n## Revisions\n\n- A sweep is point-in-time. Re-run after a burst of changes to the same subsystem, before a launch that\n  exposes it, or when a defect found elsewhere may have siblings here.\n- Re-running writes a new sweep file (`\u003Csubsystem-slug>-sweep.md` is replaced; the previous verdict is\n  summarised in **Since the last sweep**) so a reader sees what was fixed and what is still open.\n- Periodic sweeps over the subsystems that carry the most consequence are a good use of a scheduled\n  routine (`\u002Fschedule`) or a cron-driven session; the plugin ships no schedule because the cadence is\n  the project's decision.\n",{"name":5,"agent":42,"effort":43,"context":44,"description":7,"argument-hint":45},"defect-sweeper","xhigh","fork","[subsystem, directory or entry point]","main","26f591c601503d32ccba54a6ddbcba75a00910c0","skills\u002Fdefect-sweep",0,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills","https:\u002F\u002Fgithub.com\u002Fgener8v","gener8v.com","2026-10-22 20:18:28",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add gener8v\u002Fgener8v.claude-skills --skill defect-sweep",{"tool":60,"command":61},"bunx","bunx skills add gener8v\u002Fgener8v.claude-skills --skill defect-sweep",{"tool":63,"command":64},"pnpm","pnpm dlx skills add gener8v\u002Fgener8v.claude-skills --skill defect-sweep","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdefect-sweep\u002FSKILL.md",true,[68,74,80],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"assets\u002Fsweep-report.md","ASSET","资产文件",1263,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdefect-sweep\u002Fassets\u002Fsweep-report.md",{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fdefect-classes.md","REFERENCE","参考文档",3879,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdefect-sweep\u002Freferences\u002Fdefect-classes.md",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fexample.md",2381,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdefect-sweep\u002Freferences\u002Fexample.md",[85,109,138,153,175,201],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":37},"01M6CQW5KKZVDJTN9VREPRFT06","ticket-breakdown","Decompose one capability area's requirements for one change into implementable tickets with Priority, Value, acceptance criteria, Prior Art, Output contracts, Known Hazards, dependency ordering and relative sizing: one TICKET-NNN.md per ticket plus backlog.md, in the change's tickets directory. Use when a specification is approved and the team needs work items, such as 'break this spec into tickets' or 'create the backlog for search'. Not for implementing a ticket (delivery) or ordering whole capability areas (dependencies).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fticket-breakdown\u002FSKILL.md",[],[92,28,93,94,95,96,97,98,99,23,100,101,102,103,104,105,106,107,108],"ticket breakdown","spec","change","create","acceptance","search","team","work","dependency","decompose","Art","specification","contracts","acceptance criteria","backlog","dependencies","delivery",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":125,"publishedAt":37},"01M6CQW2XD2Q1JD7KFX944EH4W","technical-design","Translate specifications, constraints and dependencies into architecture decisions (AD-XXX), component boundaries, data model and interface contracts under .gener8v\u002Ftechnical-design\u002F. Use when technology or architecture choices must be settled before tickets are written, such as 'which datastore should we use' or 'design the components for search'. Skip it when the approach is obvious and uncontested. Not for judging an architecture that has already shipped (architecture-review).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftechnical-design\u002FSKILL.md",[115,120],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[126,127,128,36,129,130,131,132,97,133,134,135,136,137,23,104,107],"design","technical","technical design","translate","components","component","architecture","data","constraints","system","model","decisions",{"skillNo":139,"name":103,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":146,"publishedAt":37},"01M6CQVZY5JC08BEMTSSST1464","Expand one capability area from .gener8v\u002Fprd.md into a functional specification with atomic, testable [PREFIX]-REQ-XXX requirements, behaviors, edge cases and open questions under .gener8v\u002Fspecifications\u002F. Use when a PRD capability area needs elaboration before constraints, technical design or tickets, or a change brief still marks an area as pending specification, such as 'spec out the search area' or 'write the requirements for billing'. Not for the whole product (planning) or work items (ticket-breakdown).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fspecification\u002FSKILL.md",[143],{"categoryNo":144,"categoryName":145,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000031","产品经理",[103,126,93,94,147,148,97,149,150,151,134,25,99,127,152,23],"planning","product","edge","brief","prd","write",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":37},"01M6CQVX5MJQWPEEWDMRC21ZEJ","setup","Bootstrap the gener8v pipeline in a project: create .gener8v\u002F, copy the conventions, generate pipeline-state.yaml, and add the pipeline directives to CLAUDE.md. Use when the user says 'set up gener8v' or 'initialize the pipeline', when a project has no .gener8v\u002Fprd.md, or after a plugin upgrade to refresh the conventions. Not for deciding what to do next on a project already on the pipeline (orchestrate).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsetup\u002FSKILL.md",[],[155,160,161,95,162,163,164,165,151,27,166,167,168,169,170,23,171,172,173,174],"plugin","bootstrap","generate","state","orchestrate","yaml","SET","Bash","python3","initialize","refresh","up","do","next","upgrade",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":184,"publishedAt":37},"01M6CQVT9PZZ64TC456Y1FWF55","security-review","OWASP-informed, code-level security review of delivered code: injection, authentication and authorization, data exposure, configuration, dependencies, cryptography and logging, with attack scenarios for Medium+ findings and compliance constraints (CC-XXX) treated as Critical. Use after a delivery, especially one touching input handling, auth, sensitive data or external integrations, such as 'security review TICKET-007' or 'check what this delivery shipped for injection or auth bypass before we merge'. Not for a whole-codebase OWASP posture assessment (owasp-top10-review) or prompt-injection risk in LLM features (owasp-llm-top10-review).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecurity-review\u002FSKILL.md",[181],{"categoryNo":182,"categoryName":183,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000037","律师与法务",[36,185,186,94,187,188,189,30,190,191,192,193,194,195,196,197,198,23,199,200],"security","security review","auth","merge","assessment","authentication","compliance","owasp-llm-top10","prompt-injection","owasp-llm","risk","integrations","prompt","check","files","007",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":207,"publishedAt":37},"01M6CQVPP78PF4SB9H5WAD3837","rot-watch","Detect decay in code that is being actively written: measure six signals (packaging drift, dependency direction, comment language, growth slopes, tests, the detectable subset of SOLID) against a recorded baseline and report only what moved, at .gener8v\u002Frot\u002F. Use once code has been delivered and again every few deliveries, before a release, or when asked 'is the codebase getting worse' or 'has this module drifted'. The first run records the baseline and reports nothing. Not for one delivery's quality (quality-review), defects (defect-sweep) or whether the architecture was right (architecture-review).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Frot-watch\u002FSKILL.md",[],[208,36,209,132,210,30,211,212,213,214,20,215,216,217,23,218,100,219,220,108],"rot watch","solid","run","report","release","first","baseline","quality","growth","packaging","only","reports","drift"]