[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-uniswap-backtest-change":3,"mdc--uyekj2-key":39,"related-repo-uniswap-backtest-change":529,"related-org-uniswap-backtest-change":604},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":28,"repoUrl":29,"updatedAt":30,"license":31,"forks":32,"topics":33,"repo":34,"sourceUrl":37,"mdContent":38},"backtest-change","backtest data-driven changes against historical data","Validate a data-driven change against LIVE historical data before it ships — replay old-vs-new over a real window, report whether it achieves its goal, and refuse to ship when the data disproves the premise. Fires whenever someone proposes a measurable change and names a number: \"add a monitor at 700MB\", \"set the threshold to N\", \"warn at X \u002F critical at Y\", \"alert when it exceeds N\", \"raise the timeout to 5s\", \"change the sampling rate\", \"bump the cache TTL\", \"tighten this alert\", \"loosen the threshold\", \"this should reduce the noise\", \"that will fix the p95\" — and before opening any PR for a monitor threshold, alert routing or renotify cadence, metric\u002Flog\u002Ftrace query, sampling rate, rate limit, autoscaling parameter, or a perf change with a latency or throughput target. A proposed number is a hypothesis, not a decision: backtest it and let the data override it. Always report old N vs new M with the window and data source. The \u002Fbacktest-change command loads this same skill.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},"uniswap","Uniswap","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Funiswap.png",[12,16,19,22,25],{"name":13,"slug":14,"type":15},"Performance","performance","tag",{"name":17,"slug":18,"type":15},"Finance","finance",{"name":20,"slug":21,"type":15},"Data Analysis","data-analysis",{"name":23,"slug":24,"type":15},"Engineering","engineering",{"name":26,"slug":27,"type":15},"Testing","testing",39,"https:\u002F\u002Fgithub.com\u002FUniswap\u002Fai-toolkit","2026-08-04T05:59:09.77515",null,10,[],{"repoUrl":29,"stars":28,"forks":32,"topics":35,"description":36},[],"🤖 AI Toolkit - Standardized setup for Claude Code AI workflows. Nx monorepo with reusable agents, commands, and generators for enhanced AI-assisted development.","https:\u002F\u002Fgithub.com\u002FUniswap\u002Fai-toolkit\u002Ftree\u002FHEAD\u002Fpackages\u002Fplugins\u002Fdevelopment-pr-workflow\u002Fskills\u002Fbacktest-change","---\nname: backtest-change\ndescription: >\n  Validate a data-driven change against LIVE historical data before it ships —\n  replay old-vs-new over a real window, report whether it achieves its goal, and\n  refuse to ship when the data disproves the premise. Fires whenever someone\n  proposes a measurable change and names a number: \"add a monitor at 700MB\",\n  \"set the threshold to N\", \"warn at X \u002F critical at Y\", \"alert when it exceeds\n  N\", \"raise the timeout to 5s\", \"change the sampling rate\", \"bump the cache\n  TTL\", \"tighten this alert\", \"loosen the threshold\", \"this should reduce the\n  noise\", \"that will fix the p95\" — and before opening any PR for a monitor\n  threshold, alert routing or renotify cadence, metric\u002Flog\u002Ftrace query, sampling\n  rate, rate limit, autoscaling parameter, or a perf change with a latency or\n  throughput target. A proposed number is a hypothesis, not a decision: backtest\n  it and let the data override it. Always report old N vs new M with the window\n  and data source. The \u002Fbacktest-change command loads this same skill.\nallowed-tools: Bash, Read, Grep, Glob, AskUserQuestion\nmodel: opus\n---\n\n# Backtest a change before you ship it\n\nValidate a **data-driven change against real historical data before opening the\nPR** — and be willing to abandon or redirect the approach when the data says it\nwon't work. This is the gate that stops a plausible-but-ineffective change from\nshipping.\n\nUse it for any change whose success is measurable: monitor thresholds, alert\nrouting \u002F re-notify cadence, metric\u002Flog\u002Ftrace queries, sampling rates, cache\nTTLs, rate limits, autoscaling params, or a perf optimization with a\nlatency\u002Fthroughput target.\n\n## When this fires without being asked\n\nThe most valuable case is the one nobody invokes deliberately: **someone hands\nyou a number.** \"Add a monitor at 700 MB warn \u002F 1.2 GB critical.\" \"Set the\ntimeout to 5s.\" A named threshold arrives with an implicit claim attached — that\nit separates the bad cases from the good ones. That claim is testable, and it is\noften wrong, because the person proposing it has seen the incident population and\nnot the healthy population.\n\nTreat a user-supplied number as a **hypothesis to test**, never as a\nspecification to implement. Then say plainly what the data did to it.\n\nWorked example. A request arrived for a per-host memory monitor at \"700 MB warn \u002F\n1.2 GB critical\", motivated by two hosts that had OOM-wedged at a 2 GiB limit. A\n30-day replay found a third host that had held **1.34–1.37 GB flat for ~21\nconsecutive hours with no incident** — so the proposed critical would have paged\ncontinuously for most of a day. Shipped 1.6 GB instead. The warning was kept\nexactly as proposed, because a *non-paging* tier is allowed to sit inside normal\nrange when its job is lead time. Both halves of that outcome came from the\nbacktest, not from the proposal.\n\n## Inputs\n\nYou need: the change intended (and the file(s) if known), and the **goal** it\nshould achieve — which metric\u002Fsignal should move, in which direction, by how\nmuch. If the goal isn't stated, ask. A backtest is meaningless without a target.\n\nWhen invoked as `\u002Fbacktest-change`, parse `$ARGUMENTS` for the same two things.\n\n## The discipline (why this exists)\n\nA change that *looks* right is not the same as a change the data supports. The\ncommon failure is shipping a fix whose premise is wrong — the real driver was\nsomething else, so the metric never moves. Catch that **before** the PR, not in a\npost-merge validation.\n\n## Workflow\n\n1. **State the hypothesis precisely.** \"Changing X will move metric M from ~A to\n   ~B because C.\" Write it down. If you can't name the metric and the expected\n   direction, stop and clarify.\n\n2. **Find the authoritative data source** and respect sampling:\n   - **Metrics** (standard Datadog metrics, `trace.*`, CloudWatch) are ~100% —\n     use these to count rates\u002Fvolumes\u002Fpercentiles.\n   - Spans and logs are often heavily sampled on the success path; don't count\n     volume from them.\n   - For alert\u002Fpage\u002Fincident questions, pull the alert system's own event history\n     (e.g. incident.io alerts), not a proxy.\n   - Beware aggregation defaults that hide the shape you're testing — e.g. a\n     scalar query that silently averages a `max:` series returns avg-of-max and\n     will understate peaks. Set the aggregator explicitly.\n\n3. **Pull a representative window** (typically 7–30 days; long enough to include\n   the conditions the change targets).\n\n4. **Replay old logic vs new logic over that same window.** Compute concrete\n   deltas: old **N** vs new **M** — alerts fired, pages, error rate, p95, cost,\n   rows, whatever the goal metric is. For threshold\u002Fmonitor changes, evaluate\n   both the old and the new condition against the historical series and count\n   transitions. Identify *which groups\u002Fseries* change, not just the aggregate.\n   For a brand-new monitor, \"old\" is 0 — say so explicitly rather than omitting it.\n\n5. **Separate the two populations.** The threshold's whole job is to divide\n   incident from healthy. Report the highest *legitimate* value observed and the\n   lowest *incident* value. If they overlap, the threshold cannot work at any\n   setting and the signal itself needs to change — say that instead of picking a\n   number in the overlap.\n\n6. **Classify the result:**\n   - **EFFECTIVE** — data shows the change achieves the goal. Capture the\n     old-vs-new numbers for the PR body.\n   - **PARTIAL** — moves the metric but not enough \u002F not for the cases that\n     matter. Note the gap.\n   - **INEFFECTIVE \u002F PREMISE DISPROVED** — the data shows the real driver is\n     elsewhere, or the change barely moves M. **Stop. Do not open the PR.**\n     Report what the data actually shows and propose the lever that *would* work.\n   - **REVISED** — the goal is sound but the proposed number isn't. Ship the\n     corrected value and state prominently what you changed and why.\n\n7. **Only if it holds up**, proceed to the change + PR, and put the backtest in\n   the PR body: the hypothesis, the window, old-vs-new numbers, and a link to the\n   live dashboard\u002Fquery (prefer a link over stale typed numbers).\n\n## Output\n\nA short backtest report:\n\n- **Hypothesis** and goal metric.\n- **Window + data source** (and any sampling caveat applied).\n- **Old vs new** with hard numbers and which groups changed.\n- **Population separation** — highest healthy value vs lowest incident value.\n- **Verdict** (EFFECTIVE \u002F PARTIAL \u002F INEFFECTIVE \u002F REVISED) + recommendation. If\n  INEFFECTIVE, the alternative lever.\n\n## Principles\n\n- Backtest **before** acting; never claim a change works without replaying data.\n- A user-supplied number is a hypothesis. Testing it is the job, not overriding\n  the request — but when the data rejects it, say so and ship the corrected value.\n- Be willing to **reverse** — a disproved premise is a successful backtest, not a\n  failure.\n- Prefer **dashboard\u002Fquery links** over typed numbers that go stale.\n- Distinguish tiers by consequence: a chatty non-paging warning can be\n  acceptable; a chatty page destroys trust in the monitor.\n- When the change spans owners (e.g. an external-config change + a repo change),\n  say which half the data supports and which is out of scope.\n",{"data":40,"body":43},{"name":4,"description":6,"allowed-tools":41,"model":42},"Bash, Read, Grep, Glob, AskUserQuestion","opus",{"type":44,"children":45},"root",[46,55,69,74,81,93,105,125,131,143,165,171,190,196,406,412,417,470,476],{"type":47,"tag":48,"props":49,"children":51},"element","h1",{"id":50},"backtest-a-change-before-you-ship-it",[52],{"type":53,"value":54},"text","Backtest a change before you ship it",{"type":47,"tag":56,"props":57,"children":58},"p",{},[59,61,67],{"type":53,"value":60},"Validate a ",{"type":47,"tag":62,"props":63,"children":64},"strong",{},[65],{"type":53,"value":66},"data-driven change against real historical data before opening the\nPR",{"type":53,"value":68}," — and be willing to abandon or redirect the approach when the data says it\nwon't work. This is the gate that stops a plausible-but-ineffective change from\nshipping.",{"type":47,"tag":56,"props":70,"children":71},{},[72],{"type":53,"value":73},"Use it for any change whose success is measurable: monitor thresholds, alert\nrouting \u002F re-notify cadence, metric\u002Flog\u002Ftrace queries, sampling rates, cache\nTTLs, rate limits, autoscaling params, or a perf optimization with a\nlatency\u002Fthroughput target.",{"type":47,"tag":75,"props":76,"children":78},"h2",{"id":77},"when-this-fires-without-being-asked",[79],{"type":53,"value":80},"When this fires without being asked",{"type":47,"tag":56,"props":82,"children":83},{},[84,86,91],{"type":53,"value":85},"The most valuable case is the one nobody invokes deliberately: ",{"type":47,"tag":62,"props":87,"children":88},{},[89],{"type":53,"value":90},"someone hands\nyou a number.",{"type":53,"value":92}," \"Add a monitor at 700 MB warn \u002F 1.2 GB critical.\" \"Set the\ntimeout to 5s.\" A named threshold arrives with an implicit claim attached — that\nit separates the bad cases from the good ones. That claim is testable, and it is\noften wrong, because the person proposing it has seen the incident population and\nnot the healthy population.",{"type":47,"tag":56,"props":94,"children":95},{},[96,98,103],{"type":53,"value":97},"Treat a user-supplied number as a ",{"type":47,"tag":62,"props":99,"children":100},{},[101],{"type":53,"value":102},"hypothesis to test",{"type":53,"value":104},", never as a\nspecification to implement. Then say plainly what the data did to it.",{"type":47,"tag":56,"props":106,"children":107},{},[108,110,115,117,123],{"type":53,"value":109},"Worked example. A request arrived for a per-host memory monitor at \"700 MB warn \u002F\n1.2 GB critical\", motivated by two hosts that had OOM-wedged at a 2 GiB limit. A\n30-day replay found a third host that had held ",{"type":47,"tag":62,"props":111,"children":112},{},[113],{"type":53,"value":114},"1.34–1.37 GB flat for ~21\nconsecutive hours with no incident",{"type":53,"value":116}," — so the proposed critical would have paged\ncontinuously for most of a day. Shipped 1.6 GB instead. The warning was kept\nexactly as proposed, because a ",{"type":47,"tag":118,"props":119,"children":120},"em",{},[121],{"type":53,"value":122},"non-paging",{"type":53,"value":124}," tier is allowed to sit inside normal\nrange when its job is lead time. Both halves of that outcome came from the\nbacktest, not from the proposal.",{"type":47,"tag":75,"props":126,"children":128},{"id":127},"inputs",[129],{"type":53,"value":130},"Inputs",{"type":47,"tag":56,"props":132,"children":133},{},[134,136,141],{"type":53,"value":135},"You need: the change intended (and the file(s) if known), and the ",{"type":47,"tag":62,"props":137,"children":138},{},[139],{"type":53,"value":140},"goal",{"type":53,"value":142}," it\nshould achieve — which metric\u002Fsignal should move, in which direction, by how\nmuch. If the goal isn't stated, ask. A backtest is meaningless without a target.",{"type":47,"tag":56,"props":144,"children":145},{},[146,148,155,157,163],{"type":53,"value":147},"When invoked as ",{"type":47,"tag":149,"props":150,"children":152},"code",{"className":151},[],[153],{"type":53,"value":154},"\u002Fbacktest-change",{"type":53,"value":156},", parse ",{"type":47,"tag":149,"props":158,"children":160},{"className":159},[],[161],{"type":53,"value":162},"$ARGUMENTS",{"type":53,"value":164}," for the same two things.",{"type":47,"tag":75,"props":166,"children":168},{"id":167},"the-discipline-why-this-exists",[169],{"type":53,"value":170},"The discipline (why this exists)",{"type":47,"tag":56,"props":172,"children":173},{},[174,176,181,183,188],{"type":53,"value":175},"A change that ",{"type":47,"tag":118,"props":177,"children":178},{},[179],{"type":53,"value":180},"looks",{"type":53,"value":182}," right is not the same as a change the data supports. The\ncommon failure is shipping a fix whose premise is wrong — the real driver was\nsomething else, so the metric never moves. Catch that ",{"type":47,"tag":62,"props":184,"children":185},{},[186],{"type":53,"value":187},"before",{"type":53,"value":189}," the PR, not in a\npost-merge validation.",{"type":47,"tag":75,"props":191,"children":193},{"id":192},"workflow",[194],{"type":53,"value":195},"Workflow",{"type":47,"tag":197,"props":198,"children":199},"ol",{},[200,211,266,276,307,331,396],{"type":47,"tag":201,"props":202,"children":203},"li",{},[204,209],{"type":47,"tag":62,"props":205,"children":206},{},[207],{"type":53,"value":208},"State the hypothesis precisely.",{"type":53,"value":210}," \"Changing X will move metric M from ~A to\n~B because C.\" Write it down. If you can't name the metric and the expected\ndirection, stop and clarify.",{"type":47,"tag":201,"props":212,"children":213},{},[214,219,221],{"type":47,"tag":62,"props":215,"children":216},{},[217],{"type":53,"value":218},"Find the authoritative data source",{"type":53,"value":220}," and respect sampling:",{"type":47,"tag":222,"props":223,"children":224},"ul",{},[225,243,248,253],{"type":47,"tag":201,"props":226,"children":227},{},[228,233,235,241],{"type":47,"tag":62,"props":229,"children":230},{},[231],{"type":53,"value":232},"Metrics",{"type":53,"value":234}," (standard Datadog metrics, ",{"type":47,"tag":149,"props":236,"children":238},{"className":237},[],[239],{"type":53,"value":240},"trace.*",{"type":53,"value":242},", CloudWatch) are ~100% —\nuse these to count rates\u002Fvolumes\u002Fpercentiles.",{"type":47,"tag":201,"props":244,"children":245},{},[246],{"type":53,"value":247},"Spans and logs are often heavily sampled on the success path; don't count\nvolume from them.",{"type":47,"tag":201,"props":249,"children":250},{},[251],{"type":53,"value":252},"For alert\u002Fpage\u002Fincident questions, pull the alert system's own event history\n(e.g. incident.io alerts), not a proxy.",{"type":47,"tag":201,"props":254,"children":255},{},[256,258,264],{"type":53,"value":257},"Beware aggregation defaults that hide the shape you're testing — e.g. a\nscalar query that silently averages a ",{"type":47,"tag":149,"props":259,"children":261},{"className":260},[],[262],{"type":53,"value":263},"max:",{"type":53,"value":265}," series returns avg-of-max and\nwill understate peaks. Set the aggregator explicitly.",{"type":47,"tag":201,"props":267,"children":268},{},[269,274],{"type":47,"tag":62,"props":270,"children":271},{},[272],{"type":53,"value":273},"Pull a representative window",{"type":53,"value":275}," (typically 7–30 days; long enough to include\nthe conditions the change targets).",{"type":47,"tag":201,"props":277,"children":278},{},[279,284,286,291,293,298,300,305],{"type":47,"tag":62,"props":280,"children":281},{},[282],{"type":53,"value":283},"Replay old logic vs new logic over that same window.",{"type":53,"value":285}," Compute concrete\ndeltas: old ",{"type":47,"tag":62,"props":287,"children":288},{},[289],{"type":53,"value":290},"N",{"type":53,"value":292}," vs new ",{"type":47,"tag":62,"props":294,"children":295},{},[296],{"type":53,"value":297},"M",{"type":53,"value":299}," — alerts fired, pages, error rate, p95, cost,\nrows, whatever the goal metric is. For threshold\u002Fmonitor changes, evaluate\nboth the old and the new condition against the historical series and count\ntransitions. Identify ",{"type":47,"tag":118,"props":301,"children":302},{},[303],{"type":53,"value":304},"which groups\u002Fseries",{"type":53,"value":306}," change, not just the aggregate.\nFor a brand-new monitor, \"old\" is 0 — say so explicitly rather than omitting it.",{"type":47,"tag":201,"props":308,"children":309},{},[310,315,317,322,324,329],{"type":47,"tag":62,"props":311,"children":312},{},[313],{"type":53,"value":314},"Separate the two populations.",{"type":53,"value":316}," The threshold's whole job is to divide\nincident from healthy. Report the highest ",{"type":47,"tag":118,"props":318,"children":319},{},[320],{"type":53,"value":321},"legitimate",{"type":53,"value":323}," value observed and the\nlowest ",{"type":47,"tag":118,"props":325,"children":326},{},[327],{"type":53,"value":328},"incident",{"type":53,"value":330}," value. If they overlap, the threshold cannot work at any\nsetting and the signal itself needs to change — say that instead of picking a\nnumber in the overlap.",{"type":47,"tag":201,"props":332,"children":333},{},[334,339],{"type":47,"tag":62,"props":335,"children":336},{},[337],{"type":53,"value":338},"Classify the result:",{"type":47,"tag":222,"props":340,"children":341},{},[342,352,362,386],{"type":47,"tag":201,"props":343,"children":344},{},[345,350],{"type":47,"tag":62,"props":346,"children":347},{},[348],{"type":53,"value":349},"EFFECTIVE",{"type":53,"value":351}," — data shows the change achieves the goal. Capture the\nold-vs-new numbers for the PR body.",{"type":47,"tag":201,"props":353,"children":354},{},[355,360],{"type":47,"tag":62,"props":356,"children":357},{},[358],{"type":53,"value":359},"PARTIAL",{"type":53,"value":361}," — moves the metric but not enough \u002F not for the cases that\nmatter. Note the gap.",{"type":47,"tag":201,"props":363,"children":364},{},[365,370,372,377,379,384],{"type":47,"tag":62,"props":366,"children":367},{},[368],{"type":53,"value":369},"INEFFECTIVE \u002F PREMISE DISPROVED",{"type":53,"value":371}," — the data shows the real driver is\nelsewhere, or the change barely moves M. ",{"type":47,"tag":62,"props":373,"children":374},{},[375],{"type":53,"value":376},"Stop. Do not open the PR.",{"type":53,"value":378},"\nReport what the data actually shows and propose the lever that ",{"type":47,"tag":118,"props":380,"children":381},{},[382],{"type":53,"value":383},"would",{"type":53,"value":385}," work.",{"type":47,"tag":201,"props":387,"children":388},{},[389,394],{"type":47,"tag":62,"props":390,"children":391},{},[392],{"type":53,"value":393},"REVISED",{"type":53,"value":395}," — the goal is sound but the proposed number isn't. Ship the\ncorrected value and state prominently what you changed and why.",{"type":47,"tag":201,"props":397,"children":398},{},[399,404],{"type":47,"tag":62,"props":400,"children":401},{},[402],{"type":53,"value":403},"Only if it holds up",{"type":53,"value":405},", proceed to the change + PR, and put the backtest in\nthe PR body: the hypothesis, the window, old-vs-new numbers, and a link to the\nlive dashboard\u002Fquery (prefer a link over stale typed numbers).",{"type":47,"tag":75,"props":407,"children":409},{"id":408},"output",[410],{"type":53,"value":411},"Output",{"type":47,"tag":56,"props":413,"children":414},{},[415],{"type":53,"value":416},"A short backtest report:",{"type":47,"tag":222,"props":418,"children":419},{},[420,430,440,450,460],{"type":47,"tag":201,"props":421,"children":422},{},[423,428],{"type":47,"tag":62,"props":424,"children":425},{},[426],{"type":53,"value":427},"Hypothesis",{"type":53,"value":429}," and goal metric.",{"type":47,"tag":201,"props":431,"children":432},{},[433,438],{"type":47,"tag":62,"props":434,"children":435},{},[436],{"type":53,"value":437},"Window + data source",{"type":53,"value":439}," (and any sampling caveat applied).",{"type":47,"tag":201,"props":441,"children":442},{},[443,448],{"type":47,"tag":62,"props":444,"children":445},{},[446],{"type":53,"value":447},"Old vs new",{"type":53,"value":449}," with hard numbers and which groups changed.",{"type":47,"tag":201,"props":451,"children":452},{},[453,458],{"type":47,"tag":62,"props":454,"children":455},{},[456],{"type":53,"value":457},"Population separation",{"type":53,"value":459}," — highest healthy value vs lowest incident value.",{"type":47,"tag":201,"props":461,"children":462},{},[463,468],{"type":47,"tag":62,"props":464,"children":465},{},[466],{"type":53,"value":467},"Verdict",{"type":53,"value":469}," (EFFECTIVE \u002F PARTIAL \u002F INEFFECTIVE \u002F REVISED) + recommendation. If\nINEFFECTIVE, the alternative lever.",{"type":47,"tag":75,"props":471,"children":473},{"id":472},"principles",[474],{"type":53,"value":475},"Principles",{"type":47,"tag":222,"props":477,"children":478},{},[479,490,495,507,519,524],{"type":47,"tag":201,"props":480,"children":481},{},[482,484,488],{"type":53,"value":483},"Backtest ",{"type":47,"tag":62,"props":485,"children":486},{},[487],{"type":53,"value":187},{"type":53,"value":489}," acting; never claim a change works without replaying data.",{"type":47,"tag":201,"props":491,"children":492},{},[493],{"type":53,"value":494},"A user-supplied number is a hypothesis. Testing it is the job, not overriding\nthe request — but when the data rejects it, say so and ship the corrected value.",{"type":47,"tag":201,"props":496,"children":497},{},[498,500,505],{"type":53,"value":499},"Be willing to ",{"type":47,"tag":62,"props":501,"children":502},{},[503],{"type":53,"value":504},"reverse",{"type":53,"value":506}," — a disproved premise is a successful backtest, not a\nfailure.",{"type":47,"tag":201,"props":508,"children":509},{},[510,512,517],{"type":53,"value":511},"Prefer ",{"type":47,"tag":62,"props":513,"children":514},{},[515],{"type":53,"value":516},"dashboard\u002Fquery links",{"type":53,"value":518}," over typed numbers that go stale.",{"type":47,"tag":201,"props":520,"children":521},{},[522],{"type":53,"value":523},"Distinguish tiers by consequence: a chatty non-paging warning can be\nacceptable; a chatty page destroys trust in the monitor.",{"type":47,"tag":201,"props":525,"children":526},{},[527],{"type":53,"value":528},"When the change spans owners (e.g. an external-config change + a repo change),\nsay which half the data supports and which is out of scope.",{"items":530,"total":603},[531,539,552,571,590],{"slug":4,"name":4,"fn":5,"description":6,"org":532,"tags":533,"stars":28,"repoUrl":29,"updatedAt":30},{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[534,535,536,537,538],{"name":20,"slug":21,"type":15},{"name":23,"slug":24,"type":15},{"name":17,"slug":18,"type":15},{"name":13,"slug":14,"type":15},{"name":26,"slug":27,"type":15},{"slug":540,"name":540,"fn":541,"description":542,"org":543,"tags":544,"stars":28,"repoUrl":29,"updatedAt":551},"debug-issue","debug code errors and crashes","Systematic debugging workflow for any code error, crash, test failure, or unexpected behavior. Use this skill whenever a user mentions an error, bug, exception, crash, test failure, or says something \"isn't working\", \"is broken\", \"keeps failing\", or \"isn't behaving as expected\" — even if they haven't used the word \"debug\". Also trigger when the user pastes a stack trace, error message, or unexpected output and asks why. Don't wait for the user to say \"debug\"; if they're describing a problem with running code, this skill applies. Trigger phrases include: \"getting an error\", \"this crashes\", \"why is this failing\", \"help me fix this\", \"it broke\", \"not working\", \"exception thrown\", \"stack trace\", \"test is failing\", \"something is wrong with\".",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[545,548],{"name":546,"slug":547,"type":15},"Code Analysis","code-analysis",{"name":549,"slug":550,"type":15},"Debugging","debugging","2026-07-17T06:08:14.044038",{"slug":553,"name":553,"fn":554,"description":555,"org":556,"tags":557,"stars":28,"repoUrl":29,"updatedAt":570},"generate-document","generate professional documents in multiple formats","Generate professional documents in multiple formats (PDF, DOCX, HTML, ODT, EPUB, RTF). Use when the user says \"make a PDF\", \"generate a report\", \"create a document\", \"export to Word\", \"make a Word doc\", \"convert to PDF\", \"export findings\", \"create documentation\", or wants to save analysis results as a formatted document.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[558,561,564,567],{"name":559,"slug":560,"type":15},"Documents","documents",{"name":562,"slug":563,"type":15},"DOCX","docx",{"name":565,"slug":566,"type":15},"HTML","html",{"name":568,"slug":569,"type":15},"PDF","pdf","2026-07-17T06:07:16.218183",{"slug":572,"name":572,"fn":573,"description":574,"org":575,"tags":576,"stars":28,"repoUrl":29,"updatedAt":589},"mermaid-diagram","generate Mermaid.js diagrams for visualization","Generate syntactically valid Mermaid.js diagrams. Use when user says \"create a mermaid diagram\", \"generate a flowchart\", \"draw a sequence diagram\", \"visualize with mermaid\", \"mermaid architecture diagram\", \"create a class diagram\", \"make a state diagram\", \"ER diagram\", \"Gantt chart\", \"gitGraph\", or when generating any Mermaid code block in markdown. Also use when asked to fix or debug a broken Mermaid diagram.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[577,580,583,586],{"name":578,"slug":579,"type":15},"Design","design",{"name":581,"slug":582,"type":15},"Diagrams","diagrams",{"name":584,"slug":585,"type":15},"Documentation","documentation",{"name":587,"slug":588,"type":15},"Visualization","visualization","2026-07-17T06:05:36.621782",{"slug":591,"name":591,"fn":592,"description":593,"org":594,"tags":595,"stars":28,"repoUrl":29,"updatedAt":602},"skill-doctor","audit and optimize agent skills","Audit, map, and improve your Claude Code skills, agents, and slash commands — and mine the current session for new ones worth creating. Use this whenever the user says \"review my skills\", \"optimize my skills\", \"update my skills\", \"update all my skills\", \"maintain my skills\", \"audit my agents\", \"map my skills\", \"what skills do I have\", \"suggest skill improvements\", \"are any of my skills redundant\", \"clean up my skills\", \"turn this into a skill\", \"should this be a skill or an agent\", \"codify this workflow\", or invokes \u002Fskill-map, \u002Fskill-mine, or \u002Fskill-new. Also use PROACTIVELY after finishing a multi-step workflow that the user is likely to repeat (especially right after opening a PR) to ask whether it should become a skill or agent. It inventories every skill\u002Fagent\u002Fcommand across the user's own dirs AND all installed marketplaces, flags overlaps \u002F gaps \u002F weak triggering descriptions, and — when there's real prior work in the session — proposes new or edited skills\u002Fagents grounded in what actually happened.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[596,599],{"name":597,"slug":598,"type":15},"Agents","agents",{"name":600,"slug":601,"type":15},"Plugin Development","plugin-development","2026-07-17T06:08:14.373821",5,{"items":605,"total":764},[606,627,642,655,668,681,694,707,721,732,743,754],{"slug":607,"name":607,"fn":608,"description":609,"org":610,"tags":611,"stars":624,"repoUrl":625,"updatedAt":626},"configurator","configure auction smart contract parameters","Configure CCA (Continuous Clearing Auction) smart contract parameters through an interactive bulk form flow. Use when user says \"configure auction\", \"cca auction\", \"setup token auction\", \"auction configuration\", \"continuous auction\", or mentions CCA contracts.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[612,615,618,621],{"name":613,"slug":614,"type":15},"Configuration","configuration",{"name":616,"slug":617,"type":15},"Ethereum","ethereum",{"name":619,"slug":620,"type":15},"Smart Contracts","smart-contracts",{"name":622,"slug":623,"type":15},"Web3","web3",215,"https:\u002F\u002Fgithub.com\u002FUniswap\u002Funiswap-ai","2026-07-17T06:08:08.974641",{"slug":628,"name":628,"fn":629,"description":630,"org":631,"tags":632,"stars":624,"repoUrl":625,"updatedAt":641},"copy-trade","copy trades from crypto wallets","This skill should be used when the user asks to \"copy trades from\" a wallet, \"mirror a wallet\", \"follow this address\", set up \"copy trading\", \"track and replicate a trader\", or mirror another account's swaps bounded by guardrails. Watches a target wallet and mirrors its trades, filtered by chain, asset match, position size, and the follower's own portfolio state.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[633,636,637,640],{"name":634,"slug":635,"type":15},"Automation","automation",{"name":616,"slug":617,"type":15},{"name":638,"slug":639,"type":15},"Trading","trading",{"name":622,"slug":623,"type":15},"2026-07-17T06:04:21.974052",{"slug":643,"name":643,"fn":644,"description":645,"org":646,"tags":647,"stars":624,"repoUrl":625,"updatedAt":654},"dca-bot","automate dollar cost average token purchases","This skill should be used when the user wants to \"dca into\" a token, \"buy X every day\", set up a \"recurring buy\", \"dollar cost average\" into an asset, \"schedule a buy\", or \"auto-buy on a dip\". Buys a fixed amount into a token on a schedule, optionally only when a condition holds (for example only when ETH is below a price threshold). The host agent's scheduler wakes the skill on a cadence; each wake is one self-contained run.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[648,649,652,653],{"name":634,"slug":635,"type":15},{"name":650,"slug":651,"type":15},"DeFi","defi",{"name":638,"slug":639,"type":15},{"name":622,"slug":623,"type":15},"2026-07-17T06:05:37.160647",{"slug":656,"name":656,"fn":657,"description":658,"org":659,"tags":660,"stars":624,"repoUrl":625,"updatedAt":667},"deployer","deploy Uniswap CCA smart contracts","Deploy CCA (Continuous Clearing Auction) smart contracts using the Factory pattern. Use when user says \"deploy auction\", \"deploy cca\", \"factory deployment\", or wants to deploy a configured auction.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[661,664,665,666],{"name":662,"slug":663,"type":15},"Deployment","deployment",{"name":616,"slug":617,"type":15},{"name":619,"slug":620,"type":15},{"name":622,"slug":623,"type":15},"2026-07-17T06:08:09.661977",{"slug":669,"name":669,"fn":670,"description":671,"org":672,"tags":673,"stars":624,"repoUrl":625,"updatedAt":680},"index-bot","create and rebalance asset portfolios","This skill should be used when the user asks to \"create an index\", \"build a basket of top assets\", \"buy a weighted basket\", \"make a portfolio of assets\", \"equal-weight basket\", \"rebalance my portfolio\", \"track the top N tokens\", or wants an automated, weighted multi-asset basket that buys in one pass and rebalances on a cadence. Builds the basket spec, delegates each buy and rebalance swap to the swap-integration Trading API flow, and records target weights in state.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[674,675,678,679],{"name":616,"slug":617,"type":15},{"name":676,"slug":677,"type":15},"Portfolio Management","portfolio-management",{"name":638,"slug":639,"type":15},{"name":622,"slug":623,"type":15},"2026-07-17T06:04:22.328253",{"slug":682,"name":682,"fn":683,"description":684,"org":685,"tags":686,"stars":624,"repoUrl":625,"updatedAt":693},"liquidity-planner","plan and create liquidity positions","This skill should be used when the user asks to \"provide liquidity\", \"create LP position\", \"add liquidity to pool\", \"become a liquidity provider\", \"create v3 position\", \"create v4 position\", \"concentrated liquidity\", \"set price range\", or mentions providing liquidity, LP positions, or liquidity pools on Uniswap. Generates deep links to create positions in the Uniswap interface.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[687,688,689,692],{"name":650,"slug":651,"type":15},{"name":616,"slug":617,"type":15},{"name":690,"slug":691,"type":15},"Liquidity","liquidity",{"name":622,"slug":623,"type":15},"2026-07-17T06:08:09.315325",{"slug":695,"name":695,"fn":696,"description":697,"org":698,"tags":699,"stars":624,"repoUrl":625,"updatedAt":706},"lp-integration","integrate Uniswap liquidity provisioning","Integrate Uniswap liquidity provisioning (LP) into applications via the LP REST API. Use when the user says \"LP API\", \"liquidity provisioning API\", \"provide liquidity programmatically\", \"create LP position via API\", \"add liquidity via API\", \"increase liquidity\", \"decrease liquidity\", \"remove liquidity\", \"claim LP fees\", \"collect LP fees\", \"manage LP positions in code\", or mentions building a backend, bot, or frontend that creates or manages Uniswap v2\u002Fv3\u002Fv4 liquidity positions through an API. Also use when debugging LP API calls (e.g. \u002Flp\u002Fcreate, \u002Flp\u002Fcheck_approval, \u002Flp\u002Fincrease, \u002Flp\u002Fdecrease, \u002Flp\u002Fclaim_fees), unexpected response fields, the approval or EIP-712 permit flow, or transaction-building errors for liquidity positions. For generating deep links to the Uniswap web app instead of calling the API, use the liquidity-planner skill; for using the Uniswap v4 SDK directly rather than the REST API, use the v4-sdk-integration skill.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[700,703,704,705],{"name":701,"slug":702,"type":15},"API Development","api-development",{"name":650,"slug":651,"type":15},{"name":690,"slug":691,"type":15},{"name":622,"slug":623,"type":15},"2026-07-17T06:08:13.704465",{"slug":708,"name":708,"fn":709,"description":710,"org":711,"tags":712,"stars":624,"repoUrl":625,"updatedAt":720},"pay-with-any-token","pay HTTP 402 challenges with Uniswap","Pay HTTP 402 payment challenges using tokens via the Tempo CLI and Uniswap Trading API. Use when the user encounters a 402 Payment Required response, needs to fulfill a machine payment, mentions \"MPP\", \"Tempo payment\", \"pay for API access\", \"HTTP 402\", \"x402\", \"machine payment protocol\", \"pay-with-any-token\", \"use tempo\", \"tempo request\", or \"tempo wallet\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[713,714,717,718],{"name":650,"slug":651,"type":15},{"name":715,"slug":716,"type":15},"Payments","payments",{"name":638,"slug":639,"type":15},{"name":719,"slug":719,"type":15},"x402","2026-07-17T06:04:29.756086",{"slug":722,"name":722,"fn":723,"description":724,"org":725,"tags":726,"stars":624,"repoUrl":625,"updatedAt":731},"pay-with-app","pay 402 payment challenges","Pay HTTP 402 payment challenges issued by OKX's Agent Payments Protocol (APP) on X Layer using tokens from any chain via the Uniswap Trading API. Use this skill whenever the user encounters a 402 challenge whose network resolves to X Layer (chain 196), mentions \"APP\", \"Agent Payments Protocol\", \"OKX agent payment\", \"OKX Onchain OS\", \"OKX agentic wallet\", \"x402 on X Layer\", \"USDT0\", \"x42\", \"Instant Payment\", \"Batch Payment\", \"pay for X Layer API\", or wants to pay an OKX-backed merchant. Even when the user does not explicitly say APP, prefer this skill for any 402 challenge whose network resolves to X Layer (chain 196). For 402 challenges on other chains (Ethereum, Base, Arbitrum, Tempo) use pay-with-any-token instead.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[727,728,729,730],{"name":701,"slug":702,"type":15},{"name":715,"slug":716,"type":15},{"name":622,"slug":623,"type":15},{"name":719,"slug":719,"type":15},"2026-07-17T06:07:38.795043",{"slug":733,"name":733,"fn":734,"description":735,"org":736,"tags":737,"stars":624,"repoUrl":625,"updatedAt":742},"swap-integration","integrate Uniswap swap functionality","Integrate Uniswap swaps into applications. Use when user says \"integrate swaps\", \"uniswap\", \"trading api\", \"add swap functionality\", \"build a swap frontend\", \"create a swap script\", \"smart contract swap integration\", \"use Universal Router\", \"Trading API\", or mentions swapping tokens via Uniswap.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[738,739,740,741],{"name":701,"slug":702,"type":15},{"name":650,"slug":651,"type":15},{"name":638,"slug":639,"type":15},{"name":622,"slug":623,"type":15},"2026-07-17T06:08:10.354222",{"slug":744,"name":744,"fn":745,"description":746,"org":747,"tags":748,"stars":624,"repoUrl":625,"updatedAt":753},"swap-planner","plan and execute token swaps","This skill should be used when the user asks to \"swap tokens\", \"trade ETH for USDC\", \"exchange tokens on Uniswap\", \"buy tokens\", \"sell tokens\", \"convert ETH to stablecoins\", \"find memecoins\", \"discover tokens\", \"research tokens\", \"tokens to buy\", \"find tokens to swap\", \"what should I buy\", or mentions swapping, trading, researching, discovering, buying, or exchanging tokens on any Uniswap-supported chain. Supports both known token swaps and token discovery workflows (discovery uses keyword search and web search — there is no live \"trending\" feed). Generates deep links to execute swaps in the Uniswap interface.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[749,750,751,752],{"name":650,"slug":651,"type":15},{"name":690,"slug":691,"type":15},{"name":638,"slug":639,"type":15},{"name":622,"slug":623,"type":15},"2026-07-17T06:08:10.008152",{"slug":755,"name":755,"fn":756,"description":757,"org":758,"tags":759,"stars":624,"repoUrl":625,"updatedAt":763},"v4-hook-generator","generate Uniswap v4 hook contracts","Generate Uniswap v4 hook contracts via OpenZeppelin MCP. Use when building custom swap logic, async swaps, hook-owned liquidity, custom curves, dynamic fees, MEV protection, limit orders, or oracle hooks.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[760,761,762],{"name":616,"slug":617,"type":15},{"name":619,"slug":620,"type":15},{"name":622,"slug":623,"type":15},"2026-07-17T06:04:19.17669",20]