[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FNFWKAQQJH5FT3E6Y3EVT0":3,"skill-same:01M6FNFWKAQQJH5FT3E6Y3EVT0":85},{"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":28,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":78},"01M6FNFWKAQQJH5FT3E6Y3EVT0","loop",null,"Clade goal-driven autonomous improvement loop (Blueprint architecture — deterministic pre\u002Fpost phases + LLM supervisor\u002Fworker nodes, converges on goal met or max-iter). NOT the Claude Code built-in \u002Floop (interval polling like `\u002Floop 5m \u002Ffoo`) — route those to the built-in.","shenxingy\u002FClade","shenxingy","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F89829751?v=4","01M6CQXHTV3WQZJMG0JXD93MEK","Xingyu (Alex) Shen","01M6CQXHYCTGPJ5HD8Z7MD4Q5P",10,"MIT","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fmcp-package\u002Fskills\u002Floop\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[5,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"goal","llm supervisor","dry","decomposition","worker","iteration","iloop","route","todo","Blueprint","architecture","autonomous","haiku","model","orchestrate","batch","code","run","tasks","2026-11-10 10:12:30",false,"---\nname: loop\ndescription: Clade goal-driven autonomous improvement loop (Blueprint architecture — deterministic pre\u002Fpost phases + LLM supervisor\u002Fworker nodes, converges on goal met or max-iter). NOT the Claude Code built-in \u002Floop (interval polling like `\u002Floop 5m \u002Ffoo`) — route those to the built-in.\nwhen_to_use: \"run loop with goal file, autonomous supervisor+worker loop, keep fixing until tests pass in background workers, iterate until converged, goal.md, Blueprint loop, 自动循环, run until converged — NOT for TODO.md tasks (\u002Fbatch-tasks), task decomposition (\u002Forchestrate), in-session iteration (\u002Filoop), or interval polling (CC built-in \u002Floop)\"\nargument-hint: 'GOAL_FILE [--model haiku|sonnet|opus] [--worker-model MODEL] [--max-iter N] [--max-workers N] [--supervisor-timeout N] [--holdout DIR] [--dry-run] [--status] [--stop] [--resume]'\nuser_invocable: true\n---\n\n# Loop Skill\n\nRuns an autonomous improvement loop driven by a **goal file** (ideal end state description).\n\n## Architecture\n\n```\nYou write: goal.md  (what the system should do — NOT a task list)\n                ↓\nPRE (deterministic):\n  pre_flight       — goal exists, no blockers\n  hydrate_context  — git log + status + prior attempts that did not land (and why)\n  parse_todo       — extract unchecked items from goal file\n                ↓\nLLM CORE:\n  Supervisor       — plans 1–4 tasks (output: JSON task array)\n  drop_parked      — [DET] drop tasks bound to a goal item that used its 3 attempts\n  Workers          — execute ALL tasks IN PARALLEL\n                ↓\nPOST (deterministic + conditional LLM):\n  syntax_check     — validate all changed files\n  fix_syntax       — [LLM] one attempt to fix failures\n  test_sample      — run verify_cmd from CLAUDE.md\n  mid-iter fix     — [LLM] if test fails → fix → re-test (Stripe pattern)\n  verify           — require an explicit final-state pass\n  holdout          — run --holdout scenarios kept outside the repository\n  reconcile_goal   — coordinator marks exact task-bound goal items whose task changed the tree\n  record_attempts  — ledger: per task, did it land, and if not why (worker's own last message)\n  commit_changes   — sweep leftovers and count every iteration commit\n                ↓\nDeterministic convergence check:\n  - remaining unchecked items = 0 → CONVERGED (and every --holdout scenario passes)\n  - max iterations hit        → exit\n  - stuck (N× no-commits)    → exit\n                ↓\nRepeat until CONVERGED or max iterations\n```\n\n## What you write (goal.md)\n\n```markdown\n# Goal: Improve orchestrator loop mode\n\n## Requirements\n- [ ] Oracle rejection re-queues task with rejection reason as context\n- [ ] Worker context budget warning auto-injected at 80%\n- [ ] Workers get AGENTS.md prepended automatically\n\n## Success criteria (enforced by the verify command or --holdout, never ticked)\n- python -m py_compile server.py passes\n- Existing features unaffected\n```\n\nEach `- [ ]` line is a goal item: the loop counts them and converges when none is\nleft unchecked, ticking one only when a task bound to it changed the tree and\npassed the gates. A pass\u002Ffail property belongs in the repository's verify command\nor a `--holdout` scenario, which the loop actually runs; written as a checkbox it\nwould be ticked by an edit, not by the property. Full template:\n`~\u002F.claude\u002Ftemplates\u002Floop-goal.md`.\n\nThe **supervisor** does the task breakdown — not you.\n\n## Usage\n\n```\n\u002Floop goal.md                                # Start loop (sonnet, max 10 iter, 4 parallel workers)\n\u002Floop goal.md --model haiku                  # Cheaper\u002Ffaster supervisor+workers\n\u002Floop goal.md --max-iter 3                  # Short run to test\n\u002Floop goal.md --max-workers 2                # Limit parallel workers\n\u002Floop goal.md --max-consecutive-failures 5  # Stop after 5 consecutive worker failures (default: 3)\n\u002Floop --status                               # Check current loop progress\n\u002Floop --stop                                 # Stop loop after current iteration\n\u002Floop --dry-run goal.md                      # Preview without running (goal may precede or follow flags)\n\u002Floop goal.md --supervisor-timeout 600      # Bigger planning budget (default 300s)\n\u002Floop --resume goal.md                       # Resume an exact matching interrupted loop\n\u002Floop goal.md --holdout ~\u002Fholdout\u002Fmyproj     # Acceptance scenarios the workers' commits cannot reach\n```\n\n## Holdout scenarios (`--holdout DIR`)\n\nEvery gate above lives in the tree the workers commit into: `verify_cmd` is\nre-read from the repository's CLAUDE.md each iteration, and the whole goal file\nis pasted into the supervisor prompt. StrongDM's software-factory write-up names\nthe risk: \"A test, stored in the codebase, can be lazily rewritten to match the\ncode.\" `--holdout DIR` adds a gate kept outside it:\n\n- DIR must resolve outside the repository (`cd DIR && pwd -P` against\n  `git rev-parse --show-toplevel`, and outside every other worktree of the same\n  repository). An in-repo DIR, a scenario symlinked into the repository or\n  into another worktree of it, an empty DIR and an empty `--holdout` value are\n  refused before anything runs.\n- Each top-level executable file in DIR is a scenario. It runs after the verify\n  node with cwd = the checkout root and stdin closed; exit 0 = satisfied. A\n  scenario still running after 120 s is cut off and fails\n  (`CLADE_LOOP_HOLDOUT_TIMEOUT=N` changes the bound): the loop's own watchdog\n  (python3, so no `timeout`\u002F`gtimeout` is needed, stock macOS included) sends\n  SIGTERM to its whole process group, then SIGKILL 5 s later. Other files —\n  fixtures, expected outputs, helpers, notes — do not run.\n- A scenario must not write into the checkout. Whatever the scenarios create,\n  change or delete there (tracked or untracked, ignored files aside) is put\n  back after they run, so the iteration's commit cannot carry it. The git\n  index is put back byte for byte, so skip-worktree (sparse checkout) and\n  intent-to-add entries survive. The loop's own `.claude\u002F`, log directory and\n  state file are left alone.\n- A failing scenario keeps the iteration out of goal reconciliation and keeps\n  the run from converging, even when the checklist is ticked. So does a set\n  that can no longer run (deleted, or no longer executable).\n- Scenario names, paths, contents and output never enter a prompt or any file\n  inside the checkout: the supervisor sees only \"F of T held-out scenarios\n  failed\", and `logs\u002Floop\u002Floop.log` and `last-progress` get counts (a failing\n  scenario is \"scenario 2 of 3\"). Names, exit codes, output and what was put\n  back go to `~\u002F.claude\u002Floop-holdout\u002F\u003Ccheckout>-\u003Chash>\u002Fiter-N-holdout.log`,\n  outside the repository; the terminal is told the path at start and after\n  each check. `CLADE_LOOP_HOLDOUT_LOG_DIR` moves it, and is refused inside the\n  checkout, another worktree of it, or DIR.\n- A red holdout under a green `verify_cmd` logs `HOLDOUT FAILED — visible\n  verify_cmd passed`. Any file under DIR added, removed, edited or chmod'ed\n  mid-run — a fixture or an expected output as much as a scenario, at any\n  depth — logs `HOLDOUT CHANGED`; that iteration's pass does not count until\n  the set passes again unchanged, and the end-of-run report and `--status`\n  say \"scenario set CHANGED mid-run at iteration N\". A `verify_cmd` that\n  changes after pre-flight (including one deleted) is warned about once per\n  change.\n\nHonest scope: the workers run as your user, so they can still read or write\nDIR, and the holdout log, by absolute path. This makes the scenarios harder to\nrewrite, not impossible to rewrite. Never write the holdout path or a scenario\ninto the goal file or a `--context` file: both are pasted into the supervisor\nprompt. The runner warns, and does not refuse, when either names DIR as given,\nits physical path or its `~\u002F` form; a scenario name is not searched for, since\na short one would match prose.\n\nResume is explicit and fail-closed: the checkpoint must match the current\ncheckout, goal path, branch, HEAD and `--holdout` directory. Resume with the\nsame `--holdout DIR` the interrupted run had; a resume without it, or with\nanother one, is refused rather than run with the held-out gate off. A normal\nlaunch starts fresh and never silently consumes an older checkpoint.\n\nWorkers never mutate the shared goal file. The supervisor binds each task to\nexact goal line\u002Ftext evidence, and the coordinator marks those items only\nafter the worker, syntax, test, and final verification gates all pass, and only\nfor tasks whose worker actually changed the tree. Both worker runners record a\nper-task outcome (`changed` \u002F `unchanged` \u002F `failed`); a worker that exits 0\nhaving changed nothing (the Tier-2 \"skip, log, continue\" path) leaves its item\nunchecked and the coordinator logs it as withheld.\n\nFailures are remembered. After the gates, every task is recorded in an attempt\nledger beside the state file (`\u003Cstate>-attempts.jsonl`): whether it landed and,\nif not, why, including the worker's own final message. The next supervisor\nprompt shows the misses for every still-open goal item, so it can change the\napproach instead of re-planning the same task. A goal item gets 3 attempts that\ndo not land (one attempt plus two refinements, ScientistTwo's budget before it\nprunes an idea). Then the loop parks it in `.claude\u002Fskipped.md` and drops any\ntask bound to it. A fresh run starts an empty ledger; `--resume` keeps it. Commit\nprogress counts commits created directly by workers as well as the final sweep.\nIf the supervisor runtime is unavailable, Loop preserves its raw response,\nreports `supervisor_failed`, and leaves the checkpoint resumable instead of\nmisclassifying repeated provider failures as empty plans or max-iteration work;\nterminal execution failures also propagate a non-zero process exit.\n\n## After convergence\n\nRun `\u002Freview` to verify all behavior anchors still pass after autonomous changes.\n","# Loop Skill\n\nRuns an autonomous improvement loop driven by a **goal file** (ideal end state description).\n\n## Architecture\n\n```\nYou write: goal.md  (what the system should do — NOT a task list)\n                ↓\nPRE (deterministic):\n  pre_flight       — goal exists, no blockers\n  hydrate_context  — git log + status + prior attempts that did not land (and why)\n  parse_todo       — extract unchecked items from goal file\n                ↓\nLLM CORE:\n  Supervisor       — plans 1–4 tasks (output: JSON task array)\n  drop_parked      — [DET] drop tasks bound to a goal item that used its 3 attempts\n  Workers          — execute ALL tasks IN PARALLEL\n                ↓\nPOST (deterministic + conditional LLM):\n  syntax_check     — validate all changed files\n  fix_syntax       — [LLM] one attempt to fix failures\n  test_sample      — run verify_cmd from CLAUDE.md\n  mid-iter fix     — [LLM] if test fails → fix → re-test (Stripe pattern)\n  verify           — require an explicit final-state pass\n  holdout          — run --holdout scenarios kept outside the repository\n  reconcile_goal   — coordinator marks exact task-bound goal items whose task changed the tree\n  record_attempts  — ledger: per task, did it land, and if not why (worker's own last message)\n  commit_changes   — sweep leftovers and count every iteration commit\n                ↓\nDeterministic convergence check:\n  - remaining unchecked items = 0 → CONVERGED (and every --holdout scenario passes)\n  - max iterations hit        → exit\n  - stuck (N× no-commits)    → exit\n                ↓\nRepeat until CONVERGED or max iterations\n```\n\n## What you write (goal.md)\n\n```markdown\n# Goal: Improve orchestrator loop mode\n\n## Requirements\n- [ ] Oracle rejection re-queues task with rejection reason as context\n- [ ] Worker context budget warning auto-injected at 80%\n- [ ] Workers get AGENTS.md prepended automatically\n\n## Success criteria (enforced by the verify command or --holdout, never ticked)\n- python -m py_compile server.py passes\n- Existing features unaffected\n```\n\nEach `- [ ]` line is a goal item: the loop counts them and converges when none is\nleft unchecked, ticking one only when a task bound to it changed the tree and\npassed the gates. A pass\u002Ffail property belongs in the repository's verify command\nor a `--holdout` scenario, which the loop actually runs; written as a checkbox it\nwould be ticked by an edit, not by the property. Full template:\n`~\u002F.claude\u002Ftemplates\u002Floop-goal.md`.\n\nThe **supervisor** does the task breakdown — not you.\n\n## Usage\n\n```\n\u002Floop goal.md                                # Start loop (sonnet, max 10 iter, 4 parallel workers)\n\u002Floop goal.md --model haiku                  # Cheaper\u002Ffaster supervisor+workers\n\u002Floop goal.md --max-iter 3                  # Short run to test\n\u002Floop goal.md --max-workers 2                # Limit parallel workers\n\u002Floop goal.md --max-consecutive-failures 5  # Stop after 5 consecutive worker failures (default: 3)\n\u002Floop --status                               # Check current loop progress\n\u002Floop --stop                                 # Stop loop after current iteration\n\u002Floop --dry-run goal.md                      # Preview without running (goal may precede or follow flags)\n\u002Floop goal.md --supervisor-timeout 600      # Bigger planning budget (default 300s)\n\u002Floop --resume goal.md                       # Resume an exact matching interrupted loop\n\u002Floop goal.md --holdout ~\u002Fholdout\u002Fmyproj     # Acceptance scenarios the workers' commits cannot reach\n```\n\n## Holdout scenarios (`--holdout DIR`)\n\nEvery gate above lives in the tree the workers commit into: `verify_cmd` is\nre-read from the repository's CLAUDE.md each iteration, and the whole goal file\nis pasted into the supervisor prompt. StrongDM's software-factory write-up names\nthe risk: \"A test, stored in the codebase, can be lazily rewritten to match the\ncode.\" `--holdout DIR` adds a gate kept outside it:\n\n- DIR must resolve outside the repository (`cd DIR && pwd -P` against\n  `git rev-parse --show-toplevel`, and outside every other worktree of the same\n  repository). An in-repo DIR, a scenario symlinked into the repository or\n  into another worktree of it, an empty DIR and an empty `--holdout` value are\n  refused before anything runs.\n- Each top-level executable file in DIR is a scenario. It runs after the verify\n  node with cwd = the checkout root and stdin closed; exit 0 = satisfied. A\n  scenario still running after 120 s is cut off and fails\n  (`CLADE_LOOP_HOLDOUT_TIMEOUT=N` changes the bound): the loop's own watchdog\n  (python3, so no `timeout`\u002F`gtimeout` is needed, stock macOS included) sends\n  SIGTERM to its whole process group, then SIGKILL 5 s later. Other files —\n  fixtures, expected outputs, helpers, notes — do not run.\n- A scenario must not write into the checkout. Whatever the scenarios create,\n  change or delete there (tracked or untracked, ignored files aside) is put\n  back after they run, so the iteration's commit cannot carry it. The git\n  index is put back byte for byte, so skip-worktree (sparse checkout) and\n  intent-to-add entries survive. The loop's own `.claude\u002F`, log directory and\n  state file are left alone.\n- A failing scenario keeps the iteration out of goal reconciliation and keeps\n  the run from converging, even when the checklist is ticked. So does a set\n  that can no longer run (deleted, or no longer executable).\n- Scenario names, paths, contents and output never enter a prompt or any file\n  inside the checkout: the supervisor sees only \"F of T held-out scenarios\n  failed\", and `logs\u002Floop\u002Floop.log` and `last-progress` get counts (a failing\n  scenario is \"scenario 2 of 3\"). Names, exit codes, output and what was put\n  back go to `~\u002F.claude\u002Floop-holdout\u002F\u003Ccheckout>-\u003Chash>\u002Fiter-N-holdout.log`,\n  outside the repository; the terminal is told the path at start and after\n  each check. `CLADE_LOOP_HOLDOUT_LOG_DIR` moves it, and is refused inside the\n  checkout, another worktree of it, or DIR.\n- A red holdout under a green `verify_cmd` logs `HOLDOUT FAILED — visible\n  verify_cmd passed`. Any file under DIR added, removed, edited or chmod'ed\n  mid-run — a fixture or an expected output as much as a scenario, at any\n  depth — logs `HOLDOUT CHANGED`; that iteration's pass does not count until\n  the set passes again unchanged, and the end-of-run report and `--status`\n  say \"scenario set CHANGED mid-run at iteration N\". A `verify_cmd` that\n  changes after pre-flight (including one deleted) is warned about once per\n  change.\n\nHonest scope: the workers run as your user, so they can still read or write\nDIR, and the holdout log, by absolute path. This makes the scenarios harder to\nrewrite, not impossible to rewrite. Never write the holdout path or a scenario\ninto the goal file or a `--context` file: both are pasted into the supervisor\nprompt. The runner warns, and does not refuse, when either names DIR as given,\nits physical path or its `~\u002F` form; a scenario name is not searched for, since\na short one would match prose.\n\nResume is explicit and fail-closed: the checkpoint must match the current\ncheckout, goal path, branch, HEAD and `--holdout` directory. Resume with the\nsame `--holdout DIR` the interrupted run had; a resume without it, or with\nanother one, is refused rather than run with the held-out gate off. A normal\nlaunch starts fresh and never silently consumes an older checkpoint.\n\nWorkers never mutate the shared goal file. The supervisor binds each task to\nexact goal line\u002Ftext evidence, and the coordinator marks those items only\nafter the worker, syntax, test, and final verification gates all pass, and only\nfor tasks whose worker actually changed the tree. Both worker runners record a\nper-task outcome (`changed` \u002F `unchanged` \u002F `failed`); a worker that exits 0\nhaving changed nothing (the Tier-2 \"skip, log, continue\" path) leaves its item\nunchecked and the coordinator logs it as withheld.\n\nFailures are remembered. After the gates, every task is recorded in an attempt\nledger beside the state file (`\u003Cstate>-attempts.jsonl`): whether it landed and,\nif not, why, including the worker's own final message. The next supervisor\nprompt shows the misses for every still-open goal item, so it can change the\napproach instead of re-planning the same task. A goal item gets 3 attempts that\ndo not land (one attempt plus two refinements, ScientistTwo's budget before it\nprunes an idea). Then the loop parks it in `.claude\u002Fskipped.md` and drops any\ntask bound to it. A fresh run starts an empty ledger; `--resume` keeps it. Commit\nprogress counts commits created directly by workers as well as the final sweep.\nIf the supervisor runtime is unavailable, Loop preserves its raw response,\nreports `supervisor_failed`, and leaves the checkpoint resumable instead of\nmisclassifying repeated provider failures as empty plans or max-iteration work;\nterminal execution failures also propagate a non-zero process exit.\n\n## After convergence\n\nRun `\u002Freview` to verify all behavior anchors still pass after autonomous changes.\n",{"name":5,"description":7,"when_to_use":53,"argument-hint":54,"user_invocable":55},"run loop with goal file, autonomous supervisor+worker loop, keep fixing until tests pass in background workers, iterate until converged, goal.md, Blueprint loop, 自动循环, run until converged — NOT for TODO.md tasks (\u002Fbatch-tasks), task decomposition (\u002Forchestrate), in-session iteration (\u002Filoop), or interval polling (CC built-in \u002Floop)","GOAL_FILE [--model haiku|sonnet|opus] [--worker-model MODEL] [--max-iter N] [--max-workers N] [--supervisor-timeout N] [--holdout DIR] [--dry-run] [--status] [--stop] [--resume]",true,"main","8d452d93b9be0483dcca919d49927b91f03d935b","mcp-package\u002Fskills\u002Floop",6,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade","https:\u002F\u002Falexshen.dev\u002Fen\u002Fblog\u002Fclade","https:\u002F\u002Fgithub.com\u002Fshenxingy","https:\u002F\u002Falexshen.dev\u002F","Founding Engineer @ Scam AI | ECE @ Duke University | Data Science @ Duke Kunshan University","2026-11-11 10:54:30",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":55},[68,71,74],{"tool":69,"command":70},"npx","npx skills add shenxingy\u002FClade --skill loop",{"tool":72,"command":73},"bunx","bunx skills add shenxingy\u002FClade --skill loop",{"tool":75,"command":76},"pnpm","pnpm dlx skills add shenxingy\u002FClade --skill loop","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fmcp-package\u002Fskills\u002Floop\u002FSKILL.md",[79],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"prompt.md","REFERENCE","参考文档",12709,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fmcp-package\u002Fskills\u002Floop\u002Fprompt.md",[86,105,133,153,178,193],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":93,"publishedAt":48},"01M6FNPBA3494GF2W7V4MMAKG3","worktree","Create or inspect runtime-adaptive isolated Git workspaces with explicit ownership and delivery routing","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fworktree\u002FSKILL.md",[92],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[88,94,95,96,97,98,99,100,101,102,103,104],"adaptive","inspect","with","ownership","delivery routing","runtime","delivery","workspaces","git","routing","create",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":113,"publishedAt":48},"01M6FNP75BY8CS006EWGN29FM0","web-search","Route online research and URL reading to native tools or TinyFish MCP\u002FAPI; prepare targeted requests, handle progress and failures, and check returned evidence. Applies to web search, fetching, and bulk collection; excludes repository\u002Ffile search.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fweb-search\u002FSKILL.md",[111,112],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,36,129,130,131,132],"web search","search","web","repository","file","research","MCP","requests","collection","reading","URL","native","bulk","progress","file search","tinyfish","evidence","check","api",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":48},"01M6FNP2616DRTZRSZJQM3HPHY","verify","Verify project behavior anchors — compilation, tests, and interaction checks after autonomous runs. NOT the Codex built-in \u002Fverify (which runs the app to observe a single change working) — this one walks the AGENTS.md \"Features (Behavior Anchors)\" list.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fverify\u002FSKILL.md",[139],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[135,141,142,143,144,145,146,147,148,40,149,150,151,152],"app","single","features","which","interaction","tests","project","observe","behavior","list","change","codex",{"skillNo":154,"name":47,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":48},"01M6FNNX95R9H29BNERFY15704","Coordinate dependency-aware project tasks across independent Codex, Codex, Kimi and human sessions using Beads. Use for shared plans, claiming work, task handoffs, acceptance and agent monitoring snapshots.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Ftasks\u002FSKILL.md",[158],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[47,160,161,162,147,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,152],"for","plans","work","shared","across","human","task","coordinate","kimi","snapshots","agent monitoring","dependency","use","using beads","beads","monitoring","acceptance","sessions",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":185,"publishedAt":48},"01M6FNNTAD1BCZX5Q9TC55MZCH","sync","End-of-session documentation sync — updates TODO.md and PROGRESS.md only (run \u002Fcommit after to commit everything)","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fsync\u002FSKILL.md",[184],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[180,186,46,187,188,189,190,191,127,192,37],"session","documentation","commit","only","documentation sync","updates","end",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":200,"publishedAt":48},"01M6FNNPTR5H23MD3849E66WYA","status","Show a provider-neutral, freshness-aware snapshot of active Agent work, Git delivery, execution identity, and usage limits. Use for “what's going on right now”, what is running, progress updates, active runtime\u002Fprovider\u002Fmodel, or stuck-work checks.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fstatus\u002FSKILL.md",[199],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[195,99,201,202,160,191,203,204,127,205,100,206,207,172,208,162,42,209,102,210],"running","limits","usage","now","active","show","provider","snapshot","execution","identity"]