[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6RTXXWHNFG9832QB3GPP7JK":3,"skill-same:01M6RTXXWHNFG9832QB3GPP7JK":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":13,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6RTXXWHNFG9832QB3GPP7JK","data-throughput-accelerator",null,"Use when large data ingestion, backfill, export, ETL, warehouse loading, manifest catch-up, or table synchronization needs to become much faster while preserving data correctness.","sakamoto-family-smile\u002Fagent_monorepo","sakamoto-family-smile","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F132812403?v=4","01M6RTAT3H8PMWX5SJ65KP3VYF","01M6RTAV321WB5RAHCWTZMX5CV",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fdata-throughput-accelerator\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"data","data throughput accelerator","throughput","use","when","catch","warehouse","correctness","loading","up","ingestion","etl","edit","write","read","grep","synchronization","Bash","manifest","data ingestion","2026-11-10 10:12:30",false,"---\nname: rot-watch\ndescription: \"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).\"\nargument-hint: \"[subsystem or path]\"\neffort: xhigh\n---\n\n# Rot Watch Skill\n\n**Invoked with:** `\u003Csubsystem or path>` — or empty, to watch everything the baseline covers.\n\n## Purpose\n\nDetect decay in code that is being actively written. Not whether the code is good — that is Quality Review's question, asked once per delivered ticket against one diff. This skill asks a question no single review can: **is the codebase worse than it was?** Rot is a property of a trend, so it is invisible to any reviewer who only sees the change in front of them. The twelfth ticket can be individually reasonable and still be the one that finally inverts a dependency, and every review of every ticket up to it will have passed.\n\n## When to Use\n\nUse this skill when:\n- Several tickets have been delivered since the last watch — the interval is the point; a watch over one delivery measures nothing\n- A module has been touched by three or more consecutive deliveries\n- Before opening a new capability area, so the area is not built on drift\n- Before a release, over the subsystems the release exposes\n- On a schedule, over whatever is being written most\n\nDo **not** use this skill when:\n- No baseline exists and no code has been delivered — run it once after the first delivery to *record* the baseline, and it will report nothing\n- You want to know whether one delivery is well written — that is Quality Review\n- You want to know whether a subsystem has defects — that is Defect Sweep\n- You want to know whether the architecture was right — that is Architecture Review\n\n## Input\n\n**Source:** The repository, plus the previous baseline\n**Read from:**\n- `.gener8v\u002Frot\u002Fbaseline.md` — the recorded shape of the code at the last watch, if one exists\n- `.gener8v\u002Ftechnical-design\u002F*.md` — Component Design, for each module's *declared* responsibility and the dependency directions the architecture decisions permit\n- `.gener8v\u002Fspecifications\u002F*.md` — the `## Non-Functional Requirements`, whose verification methods are tests that must still exist and still assert what they claimed\n- `.gener8v\u002Fchanges\u002F*\u002Fdelivery\u002F*.md` — which tickets touched which files since the last watch\n- `.gener8v\u002FCONVENTIONS.md`\n- The source itself\n\n**Expects:** Delivered code. Without a baseline the first run records one and reports nothing — say so rather than inventing findings.\n\n**If input is missing:**\n- No technical design: dependency direction and module responsibility cannot be checked against anything declared. Note it, and fall back to comparing against the *previous baseline's* observed shape rather than an intended one\n- No delivery records: the watch still runs, but it cannot attribute drift to tickets\n\n## Output\n\n**Produces:** A dated rot report, and an updated baseline\n**Write to:**\n- `.gener8v\u002Frot\u002Frot-YYYY-MM-DD.md` — the report\n- `.gener8v\u002Frot\u002Fbaseline.md` — regenerated every run; **never hand-edited**\n**Creates directory:** `.gener8v\u002Frot\u002F` if it does not exist\n\n## Output Format\n\nWrite the report in the shape of `assets\u002Frot-report.md` — Read it before writing and follow it exactly, headings included. `gener8v-state.py` finds reports by their `rot-YYYY-MM-DD.md` filename and reads nothing inside them; the line it parses is the baseline's `**Deliveries:** N` (see Troubleshooting).\n\n## The Six Signals\n\nEach maps to a stated quality and, more importantly, to something observable *as movement*.\nA signal with no observable movement is an opinion, and belongs in Quality Review.\n\n### 1. Packaging — is each module still about one thing?\n\n**Watch:** a module's imports and exports growing outside the responsibility its Component Design\ndeclares; a file acquiring dependencies from a layer its module has no business touching; a\n\"utils\" or \"helpers\" module growing without a stated responsibility at all.\n**Movement, not state:** a module that has always been broad is a design choice; one that\n*became* broad over four deliveries is rot.\n\n### 2. Separation — do dependencies still point the way they were declared to?\n\n**Watch:** an import whose direction contradicts the layering the technical design records; a new\ncycle between modules; a lower layer reaching into a higher one.\n**This is the mechanism the project may already have.** Where the codebase builds a dependency\ngraph of its own corpora, the same traversal answers this question about the codebase itself —\nprefer reusing it over writing a second import analyser.\n\n### 3. Comment language — are comments still readable by someone who was not there?\n\n**Watch:** comments added since the baseline that explain *what* the line does rather than *why*\nit is that way; jargon or abbreviation introduced without expansion; a comment that no longer\nmatches the code beneath it.\n**Apply the `simple-english` rules** where that skill is available rather than inventing a second\nreadability standard.\n\n### 4. Extensibility and robustness — is the code getting harder to change?\n\n**Watch:** file length, function length, parameter counts and branching depth, each as a *slope*\nacross deliveries; error paths that newly swallow rather than propagate; a growing count of\ndeferred markers; a configuration value newly hard-coded where it was settable.\n**The honest caveat:** these are proxies. A long function is not automatically rot. A function\nthat grew 40% in three deliveries while gaining two parameters is the shape rot takes.\n\n### 5. Tests — did new code arrive with them, and do the old ones still assert what they claimed?\n\n**Watch:** source added without corresponding tests; the source-to-test ratio as a slope; **an\nexisting assertion weakened** — an equality assertion becoming a containment assertion, a count\nbecoming a non-zero check, a specific exception becoming a bare catch. And every non-functional\nrequirement whose specification names a verification method: does that test still exist, and does\nit still test that?\n**A weakened assertion is the most valuable finding this skill produces**, because it passes CI,\nsurvives review, and silently stops protecting the thing it was written for.\n\n### 6. SOLID — the parts that are detectable\n\nOnly the violations that can be *observed changing*, not judged in the abstract:\n- **Single responsibility:** a module or class accumulating unrelated reasons to change\n- **Open\u002Fclosed:** a conditional that gains a branch per feature, where an abstraction was intended\n- **Liskov:** an override that narrows a contract its base promised\n- **Interface segregation:** an interface growing methods that most implementers stub out\n- **Dependency inversion:** a concrete import appearing where the technical design declared an abstraction\n\n## Principles\n\n### Report Movement, Not State\nThe whole value is the derivative. A file that has been long since it was written is a fact about\nthe design; a file that doubled is a fact about decay. A report that lists absolute badness is\nQuality Review with worse timing, and it will be ignored for the same reason a linter with 400\nwarnings is ignored.\n\n### An Unchanged Metric Is Not a Finding\nNever list a signal that did not move. Every line in the report should be something a reader has\nto decide about. Padding the report with steady-state numbers is how a watch becomes noise.\n\n### Attribute to Tickets Where Possible\nDelivery records say which files each ticket touched. A movement attributed to two tickets is a\nconversation with whoever delivered them; an unattributed movement is a chore nobody owns.\n\n### Record Improvements\nA report that only ever reports decay trains its reader to skim it. When a ratio improved or a\ncycle was removed, say so — it is also the only way to tell whether a previous correction worked.\n\n### Severity Is About Direction and Distance\n**Breach** — a declared boundary is now violated: a dependency points the wrong way, or an NFR's\nverification no longer exists. **Drift** — movement in the wrong direction that is not yet a\nviolation. **Watch** — movement worth a second data point before acting. Do not inflate; a report\nof ten Breaches will be believed once.\n\n### The Baseline Is Derived, Never Edited\n`baseline.md` is regenerated on every run. Editing it by hand to make a report clean is the one\nway to make this skill actively harmful, because every future run compares against the lie.\n\n### Findings Become Tickets Only When They Earn It\nA Breach becomes a ticket in the owning area (`CONVENTIONS.md` §2, the same route Defect Sweep\nuses for `DS-XXX` findings). Drift and Watch stay in the report. A skill that files a ticket per\nobservation produces a backlog nobody reads.\n\n## Process\n\n1. **Locate the baseline.** If `.gener8v\u002Frot\u002Fbaseline.md` is absent, this is a recording run:\n   measure, write the baseline, write a report whose Verdict is **Holding** and whose Overview\n   says plainly that this run established the baseline and found nothing because it could not.\n\n2. **Establish the interval.** Read the delivery records written since the baseline date. List\n   the tickets and the files they touched. This is what makes attribution possible.\n\n3. **Read the declared shape.** From the technical design: each component's responsibility, and\n   the dependency directions the architecture decisions permit. From the specifications: every\n   NFR and the verification method it names. Without a technical design, note the gap and compare\n   against the previous baseline's observed shape instead.\n\n4. **Measure the six signals** over the watched paths. Prefer reusing analysis the repository\n   already has over writing a parallel one.\n\n5. **Diff against the baseline.** Discard everything that did not move. Discard everything that\n   moved in the right direction into Improvements.\n\n6. **Verify each remaining movement against the code.** A metric that moved is a hypothesis. Open\n   the file and confirm the movement is what the number implies before writing it as a finding —\n   a function split into two files reads as growth by one measure and as improvement by any\n   honest reading.\n\n7. **Attribute, explain the consequence, state the correction.** A movement with no stated\n   consequence is a number; one with no correction is a complaint.\n\n8. **Assign severity** by direction and distance from the declared boundary.\n\n9. **Write the report**, then **regenerate the baseline** from the current measurements — so the\n   next run measures from here, not from the last clean state. The baseline's header carries\n   `**Deliveries:** N`, where N is the number of delivered tickets across every change at the time\n   of this watch (the sum of `progress.delivered` over `changes:` in `pipeline-state.yaml`).\n   `gener8v-state.py` subtracts it from the current count to decide when the next watch is due; a\n   baseline without the line reads as 0 and recommends a watch after every delivery.\n\n10. **Route Breaches.** For each Breach, either open a ticket in the owning area or record in the\n    report why it was accepted. An accepted Breach becomes part of the declared shape at the next\n    baseline, which is how a deliberate exception stops being reported forever.\n\n## Example\n\nA worked report — a recording run followed by a watch three deliveries later that finds one\nBreach (a dependency inverted against a recorded architecture decision), two Drifts and one\nImprovement — is in `references\u002Fexample.md`.\n\n---\n\n## Troubleshooting\n\n- **Orchestrate recommends a watch straight after one ran.** The state script reads the delivery count at the last watch from a `**Deliveries:** N` line in `.gener8v\u002Frot\u002Fbaseline.md`, and recommends a watch once three more deliveries have landed. A baseline without that line reads as 0, so every run looks overdue. Regenerate the baseline with `**Deliveries:** N` near its top, where N is `totals.delivered` in `.gener8v\u002Fpipeline-state.yaml` at the time of the run.\n- **Everything outside the old scope reads as growth.** The watched paths changed: a watch over `core\u002F` against a baseline recorded over `core\u002Fkg\u002Fretrieve\u002F` compares two different populations. Watch the baseline's paths; to widen the scope, make this run a recording run for the new paths and say so under Not Watched and in the Overview.\n- **A Breach disappeared between watches with no ticket behind it.** Either the technical design moved the boundary or the violation was fixed. Check the design's history before calling it an Improvement; Revisions requires the report to say when the boundary moved, so a moved boundary is never mistaken for a repair.\n- **The same accepted Breach is reported again.** An accepted Breach folds into the declared shape at the next baseline only when the report that accepted it recorded the acceptance (step 10). Record it there — the exception and why — and let the next baseline absorb it; never edit `baseline.md` to make it go away.\n- **No delivery records exist for the interval.** The watch still runs and measures, but attribution is empty. Say so in Source Context rather than guessing tickets from filenames or commit messages.\n\n## Integration with Other Skills\n\n**Upstream:**\n- **Delivery**: produces the records that make the interval and its attribution knowable\n- **Technical Design**: supplies the declared responsibilities and permitted dependency directions that Breach is measured against\n- **Specification**: supplies the non-functional requirements whose verification methods must remain live\n\n**Downstream:**\n- **Ticket Breakdown**: receives Breaches as tickets in the owning area\n- **Quality Review**: reads a recent report for context on the module under review — a ticket delivered into a drifting module is judged differently from one delivered into a stable one\n- **Architecture Review**: a Breach that recurs across watches is evidence an architecture decision is not holding, which is that skill's question\n- **Orchestrate**: recommends a watch when a module has taken three or more consecutive deliveries since the last one\n\n**Distinct from:**\n- **Quality Review** — one delivery, one diff, \"is this good?\" This skill: many deliveries, \"is this worse?\"\n- **Defect Sweep** — hunts defect classes at a subsystem perimeter. This skill hunts decay, and a decayed module with no defects is still a finding\n- **Audit** — checks pipeline artifacts against each other. This skill checks code against its own past\n\n## Revisions\n\n- Re-run after any group of deliveries; the interval is the unit, not the run\n- A Breach accepted rather than fixed is folded into the declared shape at the next baseline, with the acceptance recorded in the report that accepted it\n- If the technical design changes, the next watch measures against the new declared shape — and should say that the boundary moved, so a Breach that disappears is not mistaken for a repair\n- The baseline is regenerated every run and is never edited by hand\n\n## Notes\n\n- The first run over any codebase finds nothing. That is correct behaviour, not a failure\n- A watch over a single delivery measures noise; wait for an interval\n- Proxies are proxies: length, depth and parameter counts indicate where to look, they do not\n  themselves constitute findings. Step 6 exists because of this\n- Where the repository already builds a dependency graph, reuse it for signal 2 rather than\n  writing a second import analyser that will disagree with the first\n","# Rot Watch Skill\n\n**Invoked with:** `\u003Csubsystem or path>` — or empty, to watch everything the baseline covers.\n\n## Purpose\n\nDetect decay in code that is being actively written. Not whether the code is good — that is Quality Review's question, asked once per delivered ticket against one diff. This skill asks a question no single review can: **is the codebase worse than it was?** Rot is a property of a trend, so it is invisible to any reviewer who only sees the change in front of them. The twelfth ticket can be individually reasonable and still be the one that finally inverts a dependency, and every review of every ticket up to it will have passed.\n\n## When to Use\n\nUse this skill when:\n- Several tickets have been delivered since the last watch — the interval is the point; a watch over one delivery measures nothing\n- A module has been touched by three or more consecutive deliveries\n- Before opening a new capability area, so the area is not built on drift\n- Before a release, over the subsystems the release exposes\n- On a schedule, over whatever is being written most\n\nDo **not** use this skill when:\n- No baseline exists and no code has been delivered — run it once after the first delivery to *record* the baseline, and it will report nothing\n- You want to know whether one delivery is well written — that is Quality Review\n- You want to know whether a subsystem has defects — that is Defect Sweep\n- You want to know whether the architecture was right — that is Architecture Review\n\n## Input\n\n**Source:** The repository, plus the previous baseline\n**Read from:**\n- `.gener8v\u002Frot\u002Fbaseline.md` — the recorded shape of the code at the last watch, if one exists\n- `.gener8v\u002Ftechnical-design\u002F*.md` — Component Design, for each module's *declared* responsibility and the dependency directions the architecture decisions permit\n- `.gener8v\u002Fspecifications\u002F*.md` — the `## Non-Functional Requirements`, whose verification methods are tests that must still exist and still assert what they claimed\n- `.gener8v\u002Fchanges\u002F*\u002Fdelivery\u002F*.md` — which tickets touched which files since the last watch\n- `.gener8v\u002FCONVENTIONS.md`\n- The source itself\n\n**Expects:** Delivered code. Without a baseline the first run records one and reports nothing — say so rather than inventing findings.\n\n**If input is missing:**\n- No technical design: dependency direction and module responsibility cannot be checked against anything declared. Note it, and fall back to comparing against the *previous baseline's* observed shape rather than an intended one\n- No delivery records: the watch still runs, but it cannot attribute drift to tickets\n\n## Output\n\n**Produces:** A dated rot report, and an updated baseline\n**Write to:**\n- `.gener8v\u002Frot\u002Frot-YYYY-MM-DD.md` — the report\n- `.gener8v\u002Frot\u002Fbaseline.md` — regenerated every run; **never hand-edited**\n**Creates directory:** `.gener8v\u002Frot\u002F` if it does not exist\n\n## Output Format\n\nWrite the report in the shape of `assets\u002Frot-report.md` — Read it before writing and follow it exactly, headings included. `gener8v-state.py` finds reports by their `rot-YYYY-MM-DD.md` filename and reads nothing inside them; the line it parses is the baseline's `**Deliveries:** N` (see Troubleshooting).\n\n## The Six Signals\n\nEach maps to a stated quality and, more importantly, to something observable *as movement*.\nA signal with no observable movement is an opinion, and belongs in Quality Review.\n\n### 1. Packaging — is each module still about one thing?\n\n**Watch:** a module's imports and exports growing outside the responsibility its Component Design\ndeclares; a file acquiring dependencies from a layer its module has no business touching; a\n\"utils\" or \"helpers\" module growing without a stated responsibility at all.\n**Movement, not state:** a module that has always been broad is a design choice; one that\n*became* broad over four deliveries is rot.\n\n### 2. Separation — do dependencies still point the way they were declared to?\n\n**Watch:** an import whose direction contradicts the layering the technical design records; a new\ncycle between modules; a lower layer reaching into a higher one.\n**This is the mechanism the project may already have.** Where the codebase builds a dependency\ngraph of its own corpora, the same traversal answers this question about the codebase itself —\nprefer reusing it over writing a second import analyser.\n\n### 3. Comment language — are comments still readable by someone who was not there?\n\n**Watch:** comments added since the baseline that explain *what* the line does rather than *why*\nit is that way; jargon or abbreviation introduced without expansion; a comment that no longer\nmatches the code beneath it.\n**Apply the `simple-english` rules** where that skill is available rather than inventing a second\nreadability standard.\n\n### 4. Extensibility and robustness — is the code getting harder to change?\n\n**Watch:** file length, function length, parameter counts and branching depth, each as a *slope*\nacross deliveries; error paths that newly swallow rather than propagate; a growing count of\ndeferred markers; a configuration value newly hard-coded where it was settable.\n**The honest caveat:** these are proxies. A long function is not automatically rot. A function\nthat grew 40% in three deliveries while gaining two parameters is the shape rot takes.\n\n### 5. Tests — did new code arrive with them, and do the old ones still assert what they claimed?\n\n**Watch:** source added without corresponding tests; the source-to-test ratio as a slope; **an\nexisting assertion weakened** — an equality assertion becoming a containment assertion, a count\nbecoming a non-zero check, a specific exception becoming a bare catch. And every non-functional\nrequirement whose specification names a verification method: does that test still exist, and does\nit still test that?\n**A weakened assertion is the most valuable finding this skill produces**, because it passes CI,\nsurvives review, and silently stops protecting the thing it was written for.\n\n### 6. SOLID — the parts that are detectable\n\nOnly the violations that can be *observed changing*, not judged in the abstract:\n- **Single responsibility:** a module or class accumulating unrelated reasons to change\n- **Open\u002Fclosed:** a conditional that gains a branch per feature, where an abstraction was intended\n- **Liskov:** an override that narrows a contract its base promised\n- **Interface segregation:** an interface growing methods that most implementers stub out\n- **Dependency inversion:** a concrete import appearing where the technical design declared an abstraction\n\n## Principles\n\n### Report Movement, Not State\nThe whole value is the derivative. A file that has been long since it was written is a fact about\nthe design; a file that doubled is a fact about decay. A report that lists absolute badness is\nQuality Review with worse timing, and it will be ignored for the same reason a linter with 400\nwarnings is ignored.\n\n### An Unchanged Metric Is Not a Finding\nNever list a signal that did not move. Every line in the report should be something a reader has\nto decide about. Padding the report with steady-state numbers is how a watch becomes noise.\n\n### Attribute to Tickets Where Possible\nDelivery records say which files each ticket touched. A movement attributed to two tickets is a\nconversation with whoever delivered them; an unattributed movement is a chore nobody owns.\n\n### Record Improvements\nA report that only ever reports decay trains its reader to skim it. When a ratio improved or a\ncycle was removed, say so — it is also the only way to tell whether a previous correction worked.\n\n### Severity Is About Direction and Distance\n**Breach** — a declared boundary is now violated: a dependency points the wrong way, or an NFR's\nverification no longer exists. **Drift** — movement in the wrong direction that is not yet a\nviolation. **Watch** — movement worth a second data point before acting. Do not inflate; a report\nof ten Breaches will be believed once.\n\n### The Baseline Is Derived, Never Edited\n`baseline.md` is regenerated on every run. Editing it by hand to make a report clean is the one\nway to make this skill actively harmful, because every future run compares against the lie.\n\n### Findings Become Tickets Only When They Earn It\nA Breach becomes a ticket in the owning area (`CONVENTIONS.md` §2, the same route Defect Sweep\nuses for `DS-XXX` findings). Drift and Watch stay in the report. A skill that files a ticket per\nobservation produces a backlog nobody reads.\n\n## Process\n\n1. **Locate the baseline.** If `.gener8v\u002Frot\u002Fbaseline.md` is absent, this is a recording run:\n   measure, write the baseline, write a report whose Verdict is **Holding** and whose Overview\n   says plainly that this run established the baseline and found nothing because it could not.\n\n2. **Establish the interval.** Read the delivery records written since the baseline date. List\n   the tickets and the files they touched. This is what makes attribution possible.\n\n3. **Read the declared shape.** From the technical design: each component's responsibility, and\n   the dependency directions the architecture decisions permit. From the specifications: every\n   NFR and the verification method it names. Without a technical design, note the gap and compare\n   against the previous baseline's observed shape instead.\n\n4. **Measure the six signals** over the watched paths. Prefer reusing analysis the repository\n   already has over writing a parallel one.\n\n5. **Diff against the baseline.** Discard everything that did not move. Discard everything that\n   moved in the right direction into Improvements.\n\n6. **Verify each remaining movement against the code.** A metric that moved is a hypothesis. Open\n   the file and confirm the movement is what the number implies before writing it as a finding —\n   a function split into two files reads as growth by one measure and as improvement by any\n   honest reading.\n\n7. **Attribute, explain the consequence, state the correction.** A movement with no stated\n   consequence is a number; one with no correction is a complaint.\n\n8. **Assign severity** by direction and distance from the declared boundary.\n\n9. **Write the report**, then **regenerate the baseline** from the current measurements — so the\n   next run measures from here, not from the last clean state. The baseline's header carries\n   `**Deliveries:** N`, where N is the number of delivered tickets across every change at the time\n   of this watch (the sum of `progress.delivered` over `changes:` in `pipeline-state.yaml`).\n   `gener8v-state.py` subtracts it from the current count to decide when the next watch is due; a\n   baseline without the line reads as 0 and recommends a watch after every delivery.\n\n10. **Route Breaches.** For each Breach, either open a ticket in the owning area or record in the\n    report why it was accepted. An accepted Breach becomes part of the declared shape at the next\n    baseline, which is how a deliberate exception stops being reported forever.\n\n## Example\n\nA worked report — a recording run followed by a watch three deliveries later that finds one\nBreach (a dependency inverted against a recorded architecture decision), two Drifts and one\nImprovement — is in `references\u002Fexample.md`.\n\n---\n\n## Troubleshooting\n\n- **Orchestrate recommends a watch straight after one ran.** The state script reads the delivery count at the last watch from a `**Deliveries:** N` line in `.gener8v\u002Frot\u002Fbaseline.md`, and recommends a watch once three more deliveries have landed. A baseline without that line reads as 0, so every run looks overdue. Regenerate the baseline with `**Deliveries:** N` near its top, where N is `totals.delivered` in `.gener8v\u002Fpipeline-state.yaml` at the time of the run.\n- **Everything outside the old scope reads as growth.** The watched paths changed: a watch over `core\u002F` against a baseline recorded over `core\u002Fkg\u002Fretrieve\u002F` compares two different populations. Watch the baseline's paths; to widen the scope, make this run a recording run for the new paths and say so under Not Watched and in the Overview.\n- **A Breach disappeared between watches with no ticket behind it.** Either the technical design moved the boundary or the violation was fixed. Check the design's history before calling it an Improvement; Revisions requires the report to say when the boundary moved, so a moved boundary is never mistaken for a repair.\n- **The same accepted Breach is reported again.** An accepted Breach folds into the declared shape at the next baseline only when the report that accepted it recorded the acceptance (step 10). Record it there — the exception and why — and let the next baseline absorb it; never edit `baseline.md` to make it go away.\n- **No delivery records exist for the interval.** The watch still runs and measures, but attribution is empty. Say so in Source Context rather than guessing tickets from filenames or commit messages.\n\n## Integration with Other Skills\n\n**Upstream:**\n- **Delivery**: produces the records that make the interval and its attribution knowable\n- **Technical Design**: supplies the declared responsibilities and permitted dependency directions that Breach is measured against\n- **Specification**: supplies the non-functional requirements whose verification methods must remain live\n\n**Downstream:**\n- **Ticket Breakdown**: receives Breaches as tickets in the owning area\n- **Quality Review**: reads a recent report for context on the module under review — a ticket delivered into a drifting module is judged differently from one delivered into a stable one\n- **Architecture Review**: a Breach that recurs across watches is evidence an architecture decision is not holding, which is that skill's question\n- **Orchestrate**: recommends a watch when a module has taken three or more consecutive deliveries since the last one\n\n**Distinct from:**\n- **Quality Review** — one delivery, one diff, \"is this good?\" This skill: many deliveries, \"is this worse?\"\n- **Defect Sweep** — hunts defect classes at a subsystem perimeter. This skill hunts decay, and a decayed module with no defects is still a finding\n- **Audit** — checks pipeline artifacts against each other. This skill checks code against its own past\n\n## Revisions\n\n- Re-run after any group of deliveries; the interval is the unit, not the run\n- A Breach accepted rather than fixed is folded into the declared shape at the next baseline, with the acceptance recorded in the report that accepted it\n- If the technical design changes, the next watch measures against the new declared shape — and should say that the boundary moved, so a Breach that disappears is not mistaken for a repair\n- The baseline is regenerated every run and is never edited by hand\n\n## Notes\n\n- The first run over any codebase finds nothing. That is correct behaviour, not a failure\n- A watch over a single delivery measures noise; wait for an interval\n- Proxies are proxies: length, depth and parameter counts indicate where to look, they do not\n  themselves constitute findings. Step 6 exists because of this\n- Where the repository already builds a dependency graph, reuse it for signal 2 rather than\n  writing a second import analyser that will disagree with the first\n",{"name":48,"effort":49,"description":50,"argument-hint":51},"rot-watch","xhigh","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).","[subsystem or path]","main","26f591c601503d32ccba54a6ddbcba75a00910c0",".claude\u002Fskills\u002Fecc\u002Fdata-throughput-accelerator","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile","2026-11-08 20:29:14",{"source":8,"skillName":48,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add sakamoto-family-smile\u002Fagent_monorepo --skill rot-watch",{"tool":64,"command":65},"bunx","bunx skills add sakamoto-family-smile\u002Fagent_monorepo --skill rot-watch",{"tool":67,"command":68},"pnpm","pnpm dlx skills add sakamoto-family-smile\u002Fagent_monorepo --skill rot-watch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fdata-throughput-accelerator\u002FSKILL.md",true,[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"assets\u002Frot-report.md","ASSET","资产文件",2070,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Frot-watch\u002Fassets\u002Frot-report.md",{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fexample.md","REFERENCE","参考文档",4882,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Frot-watch\u002Freferences\u002Fexample.md",[85,120,128,146,169,196],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":99,"publishedAt":43},"01M6RW50THEFSKK42YNR8XFZA1","remotion-video-creation","Best practices for Remotion - Video creation in React. 29 domain-specific rules covering 3D, animations, audio, captions, charts, transitions, and more.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fremotion-video-creation\u002FSKILL.md",[91,96],{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":97,"categoryName":98,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000016","图像与多媒体",[100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119],"Video","remotion video","remotion video creation","creation","Remotion","Charts","Captions","Audio","3D","Composition","Animation","best practices","more","animations","domain-specific","domain","three","Rules","Lottie","for",{"skillNo":121,"name":122,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":43},"01M6VCJ23NPECPSZJKGY691F75","hotcook-recipes","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fhotcook-agent\u002Fdata\u002Fskills\u002Fhotcook-recipes\u002FSKILL.md",[],[126,127],"hotcook recipes","recipes",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":140,"publishedAt":43},"01M6VCHHE00X5XHSDRD1KH1BW2","code-helper","Code review and assistance skill","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fagent-system-2\u002Fskills\u002Fcode-helper\u002Fskill.md",[134,137],{"categoryNo":135,"categoryName":136,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":138,"categoryName":139,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师",[141,142,143,144,145],"code helper","helper","code","code review","review",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":158,"publishedAt":43},"01M6VCH3Q31A20H6SQ1H0J7JB2","research-assistant","Web research assistant skill using Brave Search MCP","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fagent-system-1\u002Fskills\u002Fresearch-assistant\u002Fskill.md",[152,155],{"categoryNo":153,"categoryName":154,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":156,"categoryName":157,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000023","Skill与智能体开发",[159,160,161,162,163,164,165,166,167,168],"research assistant","research","assistant","MCP","web","search","brave search","web research","brave","web research assistant",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":179,"publishedAt":43},"01M6VCGZZGPNVJSCZ1JTMNZAHY","x-api","X\u002FTwitter API integration for posting tweets, threads, reading timelines, search, and analytics. Covers OAuth auth patterns, rate limits, and platform-native content posting. Use when the user wants to interact with X programmatically.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fx-api\u002FSKILL.md",[175,178],{"categoryNo":176,"categoryName":177,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":138,"categoryName":139,"taxonomyType":20,"taxonomyTypeDesc":21},[180,181,182,27,183,184,119,185,186,187,188,189,190,191,192,26,193,194,164,195],"x api","api","with","limits","rate","threads","reading","native","posting","platform","patterns","api integration","twitter","auth","analytics","OAuth",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":203,"publishedAt":43},"01M6VCGVX6DGB1FKTA53QBBCQB","workspace-surface-audit","Audit the active repo, MCP servers, plugins, connectors, env surfaces, and harness setup, then recommend the highest-value ECC-native skills, hooks, agents, and operator workflows. Use when the user wants help setting up Claude Code or understanding what capabilities are actually available in their environment.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fworkspace-surface-audit\u002FSKILL.md",[202],{"categoryNo":156,"categoryName":157,"taxonomyType":94,"taxonomyTypeDesc":95},[204,205,206,207,162,208,209,143,210,211,212,213,26,32,214,215,216,187,217,27],"workspace surface audit","workspace","audit","hooks","workflows","connectors","capabilities","harness","repo","environment","harness setup","active","env","value"]