[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7C9SR6FSZ2H2HTGVDCP4G87":3,"skill-same:01M7C9SR6FSZ2H2HTGVDCP4G87":62},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":29,"ownerDescription":30,"updatedAt":31,"install":32,"resources":45},"01M7C9SR6FSZ2H2HTGVDCP4G87","blocking-io-guard",null,"Ensure async-path backend code that could block the asyncio event loop is protected by a teeth-verified runtime anchor in tests\u002Fblocking_io\u002F. Use when changing backend Python under app\u002F, packages\u002Fharness\u002Fdeerflow\u002F, or scripts\u002F, when running a blocking-IO triage round over the whole repo, or when a reviewer\u002FCI asks for blocking-IO coverage. Runs a deterministic scan (changed-lines or full-repo), routes each candidate, drafts\u002Fextends an anchor, and proves it fails when the blocking IO regresses.","girishlade111\u002Fdeer-flow","girishlade111","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F188465114?v=4","01M7C9S54VYSZDEQA3XF8M6B2N","Girish balaso Lade","01M7C9S55FR6ATDFHDXP318V75",0,"MIT","https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002F.agent\u002Fskills\u002Fblocking-io-guard\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: blocking-io-guard\ndescription: Ensure async-path backend code that could block the asyncio event loop is protected by a teeth-verified runtime anchor in tests\u002Fblocking_io\u002F. Use when changing backend Python under app\u002F, packages\u002Fharness\u002Fdeerflow\u002F, or scripts\u002F, when running a blocking-IO triage round over the whole repo, or when a reviewer\u002FCI asks for blocking-IO coverage. Runs a deterministic scan (changed-lines or full-repo), routes each candidate, drafts\u002Fextends an anchor, and proves it fails when the blocking IO regresses.\n---\n\n# Blocking-IO Guard Skill\n\nHelp a contributor ship backend async changes together with the runtime anchor\nthat lets DeerFlow's blocking-IO CI gate actually see the new code. The dynamic\ndetector only catches blocking IO on paths a test executes — this skill closes\nthat gap, either for your own diff or for a repo-wide triage round.\n\nRead `references\u002Fgood-anchor-rules.md` before writing any anchor.\nOnly read `references\u002Fsop-skeleton.md` when generalizing this SOP to another\ndetector domain — it is not needed to execute the steps below.\n\n## When to use\n\n- Your change touches Python under `backend\u002Fapp\u002F`,\n  `backend\u002Fpackages\u002Fharness\u002Fdeerflow\u002F`, or `backend\u002Fscripts\u002F` and may run on\n  the async event loop (Mode A). If unsure, run Step 0 — it answers\n  deterministically.\n- You are doing a maintenance triage round over the existing codebase\n  (Mode B).\n\n## SOP (router)\n\n### Step 0 — Scope (deterministic)\n\n**Mode A — your own diff** (default, pre-PR). From repo root:\n\n```bash\nuv run --project backend python scripts\u002Fscan_changed_blocking_io.py --base origin\u002Fmain\n```\n\nLists blocking-IO candidates your change introduces: findings on lines the\ndiff added, **plus** findings that are new versus the merge base — the latter\ncatches a new async caller exposing an old sync helper whose blocking line is\nnot in the diff. The diff is `\u003Cbase>...HEAD`, so **commit your work first** —\nuncommitted lines are not selected.\n\nIf the list is empty, this change introduces no blocking-IO surface *that the\nstatic detector can see in the changed files*. One residual blind spot\nremains: reachability is same-file only, so a new async caller of a sync\nhelper **defined in another file** is invisible to both selections. If your\ndiff adds an async call into a helper that lives elsewhere, check that helper\nmanually (codegraph or `git grep`) before stopping.\n\n**Mode B — full-repo triage round.** From repo root:\n\n```bash\nmake detect-blocking-io\n```\n\nPrints a summary and writes the complete structured finding list to\n`.deer-flow\u002Fblocking-io-findings.json`. Work HIGH priority first; do not start\nMEDIUM until every HIGH is dispositioned (fixed, guarded, or recorded\nNO-ACTION).\n\n**Batching policy (PR sizing).** One **fix unit** per PR while any HIGH\nremains: a fix unit is one root cause — usually a single HIGH, but two HIGHs\nresolved by the same one-place fix belong together. Once no HIGH remains,\nMEDIUM\u002FLOW may be batched (about five per round, grouped by module or by\ndisposition) so each PR stays reviewable. A new Blockbuster rule is never\nbatched with anything — it always ships alone (see Step 5).\n\nBoth modes emit the same JSON shape per finding: `priority`, `location`\n(path\u002Fline\u002Ffunction), `blocking_call` (category\u002Foperation\u002Fsymbol),\n`event_loop_exposure`, `reason`, `code`. Priority is a deterministic review\nordering, not proof of a bug — Step 1 makes the actual call.\n\n### Step 1 — Judge each candidate (router)\n\nRead the code around each candidate and route it:\n\n- **Already offloaded** (`asyncio.to_thread`, `run_in_executor`, async client) →\n  **GUARD**: add\u002Fextend an anchor that locks the offload so a future edit cannot\n  move it back onto the loop.\n- **On the loop, not offloaded** → **FIX+ANCHOR**: offload the production code\n  (your fix), then add an anchor that guards it.\n- **Not actually exposed \u002F acceptable** (rare: scanner false positive,\n  startup-only code) → **NO-ACTION**: record one line of why.\n- **Cross-file caveat**: the scanner's async reachability is same-file only\n  (`ASYNC_REACHABLE_SAME_FILE`). If the candidate is a *sync helper*, check for\n  async callers in other files (codegraph or `git grep`) before deciding\n  NO-ACTION.\n\n### Step 2 — Apply the fix, then re-scan (FIX+ANCHOR only)\n\nOffload the blocking call in production code, then re-run the Step 0 scan and\nconfirm the candidate no longer appears. If the offloaded call sits in a\n`finally` \u002F cleanup path, keep it best-effort and bounded (swallow-and-log,\n`asyncio.wait_for`) so a failing or hung cleanup cannot mask the primary\nexception. Match by the stable key\n**(path, function, symbol)** — line numbers shift after edits, so never\ncompare by line.\n\n- The finding must disappear. If it still shows, the fix did not remove the\n  blocking pattern (e.g. the call is still a direct call, not offloaded) —\n  go back before touching any test.\n- GUARD \u002F NO-ACTION routes skip this step: a residual finding there is\n  *expected* (the raw call still exists inside a sync helper with the offload\n  at the caller, or the exposure was judged acceptable).\n\nThis is pattern-level feedback in seconds; it complements but never replaces\nStep 5 — only the runtime gate proves the event loop is actually protected.\n\n### Step 3 — Check existing anchors\n\nLook in `backend\u002Ftests\u002Fblocking_io\u002F` for a test that drives the production async\nentry point reaching this candidate's branch.\n\n- Covers this branch already → go to Step 5 (re-verify teeth).\n- Covers the entry point but not this branch (e.g. happy path covered,\n  cleanup\u002F404\u002F409 not) → **extend** that anchor.\n- None → create one from `templates\u002Fanchor.template.py`.\n\n### Step 4 — Generate \u002F extend the anchor\n\nFollow `references\u002Fgood-anchor-rules.md`. Drive the *specific* branch (e.g. force\nthe create failure that hits the cleanup `shutil.rmtree`). Never bypass the\nblocking surface with a test-only `asyncio.to_thread` wrapper.\n\n### Step 5 — Verify teeth (mandatory; also the anchor-vs-rule discriminator)\n\n1. Reintroduce the block (GUARD: temporarily revert the offload; FIX+ANCHOR: run\n   against the pre-fix code).\n2. Run `cd backend && make test-blocking-io` (or target the one test). It **must\n   go RED**.\n3. Restore the fix. It **must go GREEN**.\n\nA real block that stays GREEN means Blockbuster has no rule for that\nprimitive — that is the **RULE** route; see `references\u002Fgood-anchor-rules.md`\nfor the admission criteria before adding one.\n\n### Step 6 — Deliver\n\nCommit the anchor(s) with your change; `make test-blocking-io` green. In the PR,\nnote: candidates found, each disposition, the re-scan result (Step 2), and\nthe teeth evidence (red→green). Include the reason for any NO-ACTION. A new\nBlockbuster rule, if any, goes in its own commit with the evidence from Step 5.\n","# Blocking-IO Guard Skill\n\nHelp a contributor ship backend async changes together with the runtime anchor\nthat lets DeerFlow's blocking-IO CI gate actually see the new code. The dynamic\ndetector only catches blocking IO on paths a test executes — this skill closes\nthat gap, either for your own diff or for a repo-wide triage round.\n\nRead `references\u002Fgood-anchor-rules.md` before writing any anchor.\nOnly read `references\u002Fsop-skeleton.md` when generalizing this SOP to another\ndetector domain — it is not needed to execute the steps below.\n\n## When to use\n\n- Your change touches Python under `backend\u002Fapp\u002F`,\n  `backend\u002Fpackages\u002Fharness\u002Fdeerflow\u002F`, or `backend\u002Fscripts\u002F` and may run on\n  the async event loop (Mode A). If unsure, run Step 0 — it answers\n  deterministically.\n- You are doing a maintenance triage round over the existing codebase\n  (Mode B).\n\n## SOP (router)\n\n### Step 0 — Scope (deterministic)\n\n**Mode A — your own diff** (default, pre-PR). From repo root:\n\n```bash\nuv run --project backend python scripts\u002Fscan_changed_blocking_io.py --base origin\u002Fmain\n```\n\nLists blocking-IO candidates your change introduces: findings on lines the\ndiff added, **plus** findings that are new versus the merge base — the latter\ncatches a new async caller exposing an old sync helper whose blocking line is\nnot in the diff. The diff is `\u003Cbase>...HEAD`, so **commit your work first** —\nuncommitted lines are not selected.\n\nIf the list is empty, this change introduces no blocking-IO surface *that the\nstatic detector can see in the changed files*. One residual blind spot\nremains: reachability is same-file only, so a new async caller of a sync\nhelper **defined in another file** is invisible to both selections. If your\ndiff adds an async call into a helper that lives elsewhere, check that helper\nmanually (codegraph or `git grep`) before stopping.\n\n**Mode B — full-repo triage round.** From repo root:\n\n```bash\nmake detect-blocking-io\n```\n\nPrints a summary and writes the complete structured finding list to\n`.deer-flow\u002Fblocking-io-findings.json`. Work HIGH priority first; do not start\nMEDIUM until every HIGH is dispositioned (fixed, guarded, or recorded\nNO-ACTION).\n\n**Batching policy (PR sizing).** One **fix unit** per PR while any HIGH\nremains: a fix unit is one root cause — usually a single HIGH, but two HIGHs\nresolved by the same one-place fix belong together. Once no HIGH remains,\nMEDIUM\u002FLOW may be batched (about five per round, grouped by module or by\ndisposition) so each PR stays reviewable. A new Blockbuster rule is never\nbatched with anything — it always ships alone (see Step 5).\n\nBoth modes emit the same JSON shape per finding: `priority`, `location`\n(path\u002Fline\u002Ffunction), `blocking_call` (category\u002Foperation\u002Fsymbol),\n`event_loop_exposure`, `reason`, `code`. Priority is a deterministic review\nordering, not proof of a bug — Step 1 makes the actual call.\n\n### Step 1 — Judge each candidate (router)\n\nRead the code around each candidate and route it:\n\n- **Already offloaded** (`asyncio.to_thread`, `run_in_executor`, async client) →\n  **GUARD**: add\u002Fextend an anchor that locks the offload so a future edit cannot\n  move it back onto the loop.\n- **On the loop, not offloaded** → **FIX+ANCHOR**: offload the production code\n  (your fix), then add an anchor that guards it.\n- **Not actually exposed \u002F acceptable** (rare: scanner false positive,\n  startup-only code) → **NO-ACTION**: record one line of why.\n- **Cross-file caveat**: the scanner's async reachability is same-file only\n  (`ASYNC_REACHABLE_SAME_FILE`). If the candidate is a *sync helper*, check for\n  async callers in other files (codegraph or `git grep`) before deciding\n  NO-ACTION.\n\n### Step 2 — Apply the fix, then re-scan (FIX+ANCHOR only)\n\nOffload the blocking call in production code, then re-run the Step 0 scan and\nconfirm the candidate no longer appears. If the offloaded call sits in a\n`finally` \u002F cleanup path, keep it best-effort and bounded (swallow-and-log,\n`asyncio.wait_for`) so a failing or hung cleanup cannot mask the primary\nexception. Match by the stable key\n**(path, function, symbol)** — line numbers shift after edits, so never\ncompare by line.\n\n- The finding must disappear. If it still shows, the fix did not remove the\n  blocking pattern (e.g. the call is still a direct call, not offloaded) —\n  go back before touching any test.\n- GUARD \u002F NO-ACTION routes skip this step: a residual finding there is\n  *expected* (the raw call still exists inside a sync helper with the offload\n  at the caller, or the exposure was judged acceptable).\n\nThis is pattern-level feedback in seconds; it complements but never replaces\nStep 5 — only the runtime gate proves the event loop is actually protected.\n\n### Step 3 — Check existing anchors\n\nLook in `backend\u002Ftests\u002Fblocking_io\u002F` for a test that drives the production async\nentry point reaching this candidate's branch.\n\n- Covers this branch already → go to Step 5 (re-verify teeth).\n- Covers the entry point but not this branch (e.g. happy path covered,\n  cleanup\u002F404\u002F409 not) → **extend** that anchor.\n- None → create one from `templates\u002Fanchor.template.py`.\n\n### Step 4 — Generate \u002F extend the anchor\n\nFollow `references\u002Fgood-anchor-rules.md`. Drive the *specific* branch (e.g. force\nthe create failure that hits the cleanup `shutil.rmtree`). Never bypass the\nblocking surface with a test-only `asyncio.to_thread` wrapper.\n\n### Step 5 — Verify teeth (mandatory; also the anchor-vs-rule discriminator)\n\n1. Reintroduce the block (GUARD: temporarily revert the offload; FIX+ANCHOR: run\n   against the pre-fix code).\n2. Run `cd backend && make test-blocking-io` (or target the one test). It **must\n   go RED**.\n3. Restore the fix. It **must go GREEN**.\n\nA real block that stays GREEN means Blockbuster has no rule for that\nprimitive — that is the **RULE** route; see `references\u002Fgood-anchor-rules.md`\nfor the admission criteria before adding one.\n\n### Step 6 — Deliver\n\nCommit the anchor(s) with your change; `make test-blocking-io` green. In the PR,\nnote: candidates found, each disposition, the re-scan result (Step 2), and\nthe teeth evidence (red→green). Include the reason for any NO-ACTION. A new\nBlockbuster rule, if any, goes in its own commit with the evidence from Step 5.\n",{"name":5,"description":7},"master","055c1e70d3f63833611e389aab5d67e45c5f299b",".agent\u002Fskills\u002Fblocking-io-guard","https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow","https:\u002F\u002Fgithub.com\u002Fgirishlade111","https:\u002F\u002Fladestack.in","Hey! I’m Girish, a UX\u002FUI developer who’s weirdly obsessed with building stuff people can actually use… for free. Seriously, why pay for tools when we can just m","2026-10-02 22:27:13",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add girishlade111\u002Fdeer-flow --skill blocking-io-guard",{"tool":38,"command":39},"bunx","bunx skills add girishlade111\u002Fdeer-flow --skill blocking-io-guard",{"tool":41,"command":42},"pnpm","pnpm dlx skills add girishlade111\u002Fdeer-flow --skill blocking-io-guard","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002F.agent\u002Fskills\u002Fblocking-io-guard\u002FSKILL.md",true,[46,52,56],{"path":47,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":50,"sourceHtmlUrl":51},"references\u002Fgood-anchor-rules.md","REFERENCE","参考文档",3188,"https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002F.agent\u002Fskills\u002Fblocking-io-guard\u002Freferences\u002Fgood-anchor-rules.md",{"path":53,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":54,"sourceHtmlUrl":55},"references\u002Fsop-skeleton.md",1787,"https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002F.agent\u002Fskills\u002Fblocking-io-guard\u002Freferences\u002Fsop-skeleton.md",{"path":57,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"templates\u002Fanchor.template.py","SCRIPT","脚本",1303,"https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002F.agent\u002Fskills\u002Fblocking-io-guard\u002Ftemplates\u002Fanchor.template.py",[63,70,77,84,91,98],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M7C9YZQ8328P2FCDFG2DY1B2","web-design-guidelines","Review UI code for Web Interface Guidelines compliance. Use when asked to \"review my UI\", \"check accessibility\", \"audit design\", \"review UX\", or \"check my site against best practices\".","https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002Fskills\u002Fpublic\u002Fweb-design-guidelines\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7C9YKZDP58A0QG404PJB7T7","video-generation","Use this skill when the user requests to generate, create, or imagine videos. Supports structured prompts and reference image for guided generation.","https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002Fskills\u002Fpublic\u002Fvideo-generation\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M7C9Y9EB3WMCGRK9PVJ798AA","vercel-deploy","Deploy applications and websites to Vercel. Use this skill when the user requests deployment actions such as \"Deploy my app\", \"Deploy this to production\", \"Create a preview deployment\", \"Deploy and give me the link\", or \"Push this live\". No authentication required - returns preview URL and claimable deployment link.","https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002Fskills\u002Fpublic\u002Fvercel-deploy-claimable\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M7C9Y5GYD8XXVDQZA8YFBTD4","systematic-literature-review","Use this skill when the user wants a systematic literature review, survey, or synthesis across multiple academic papers on a topic. Also covers annotated bibliographies and cross-paper comparisons. Searches arXiv and outputs reports in APA, IEEE, or BibTeX format. Not for single-paper tasks — use academic-paper-review for reviewing one paper.","https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002Fskills\u002Fpublic\u002Fsystematic-literature-review\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":19},"01M7C9Y0VCEG66ZVCXEHDCNZHB","surprise-me","Create a delightful, unexpected \"wow\" experience for the user by dynamically discovering and creatively combining other enabled skills. Triggers when the user says \"surprise me\" or any request expressing a desire for an unexpected creative showcase. Also triggers when the user is bored, wants inspiration, or asks for \"something interesting\".","https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002Fskills\u002Fpublic\u002Fsurprise-me\u002FSKILL.md",[],[],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":19},"01M7C9XXSA5H1YTHRN0KM7VW71","zh-output-example","Reviews Chinese skill documentation for publication readiness. Invoke when the user asks in Chinese to review a skill.","https:\u002F\u002Fgithub.com\u002Fgirishlade111\u002Fdeer-flow\u002Fblob\u002Fmaster\u002Fskills\u002Fpublic\u002Fskill-reviewer\u002Fevals\u002Ffixtures\u002Fzh-output\u002FSKILL.md",[],[]]