[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CR3RMXMZ6NETQFC0FSH031":3,"skill-same:01M6CR3RMXMZ6NETQFC0FSH031":83},{"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":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6CR3RMXMZ6NETQFC0FSH031","compute",null,"Plan, profile, schedule, and recover large CPU\u002FGPU experiments and data batches on shared machines. Use before scaling training, inference, rendering, extraction, or evaluation; excludes ordinary small builds and remote model API fan-out.","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\u002Fconfigs\u002Fskills\u002Fcompute\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","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],"schedule","batches","remote","rendering","CPU","scaling","shared","use","profile","inference","model","plan","api","data","Evaluation","extraction","gpu","training","experiments","2026-11-10 10:12:30",false,"---\nname: compute\ndescription: Plan, profile, schedule, and recover large CPU\u002FGPU experiments and data batches on shared machines. Use before scaling training, inference, rendering, extraction, or evaluation; excludes ordinary small builds and remote model API fan-out.\n---\n\n# Compute — measure, admit, run, recover\n\nUse existing schedulers and profilers. This workflow selects and verifies them;\nit is not a scheduler and does not reserve capacity by itself. Do not build a\nnew queue or deploy a cluster merely to execute a batch.\n\n## Resolve placement and the execution backend\n\nRead `~\u002F.clade\u002Fcompute-policy.md` when present, then the project's execution\ninstructions and the site's acceptable-use policy. Keep private hostnames,\npaths, budgets, and incident notes in that user-owned file, outside public\nrepositories. Current user instructions supersede older personal preferences;\nthey do not implicitly waive site restrictions or grant administrator access.\nIf the profile is missing, use known authorized resources and record defaults;\ndo not invent remote hosts, reservations, or permission to displace others.\nThe profile is optional: a standalone local machine can use a bounded local\nrunner after the same preflight. No specific host, quota value or scheduler is\nrequired by Clade itself.\n\nResolve the site's effective limits for the chosen user, group\u002Fproject\u002Faccount,\npartition\u002Fqueue and service class (such as QOS), using its documented precedence.\nCheck CPU\u002FGPU\u002FRAM, concurrent and submitted job counts, wall time\u002Fcompute credits,\nand storage bytes\u002Finodes where applicable. Record scope, source, current usage\nand remaining allowance; include other jobs\u002Fsessions charged to that scope.\nDo not give each host or worker a fresh copy of a fleet-wide allowance. Derive\nthis run's budget from the effective remaining quotas, its actual allocation,\nproject\u002Fuser caps, physical headroom and enforced cgroup\u002FOS limits together.\nAn idle host or free VRAM is not an allocation. Personal preferences and\ndedicated-host permission cannot relax site restrictions or other binding caps.\nIf quota details are hidden, use the site's authoritative admission system and\nrecord what remains unknown; missing visibility is not unlimited entitlement.\nIf neither authorized limits nor authoritative admission can be established,\nkeep that lane PREPARED\u002FBLOCKED instead of guessing a fleet-wide allowance.\n\nBefore starting even a compute smoke run, state its host, backend, resource\nlimits, and scratch location. Follow the profile's host tiers; within a tier,\nchoose by current headroom, data locality, and measured end-to-end throughput.\nUse fallback hosts only under the profile's conditions. A shell on a machine\nis not a reason to run the batch there.\n\nRead [backend selection](references\u002Fbackend-selection.md) for the applicable\nbackend. Inspect what is actually installed and usable: command\u002Fversion,\ncontroller connectivity, node state, user access, resource enforcement, and\ndurable restart support. An installed Slurm client, empty queue, live Ray\ndashboard, or `tmux` session is not proof of readiness. If site policy requires\na broken backend, park that lane with evidence; do not bypass it.\n\n## Preflight and local staging\n\nCapture a timestamped snapshot on each candidate host:\n\n- CPU affinity\u002Fcgroup quota and load; available RAM, swap pressure and effective\n  ancestor cgroup limits; other users' workload totals without their secrets.\n- GPU model, utilization, free VRAM, active allocations\u002Fprocesses and driver\n  health. A failed probe means unknown capacity, never an idle GPU.\n- Source, scratch and checkpoint mount types, local disk space\u002Finodes, and\n  network\u002FI\u002FO pressure. Resolve symlinks: a path named `ssd` may still be NFS.\n- Scheduler allocations plus work outside it. Recheck at admission; the\n  snapshot is not a reservation. Coordinate our simultaneous sessions through\n  the existing scheduler or one shared admission mechanism covering every\n  applicable quota scope, including aggregate user\u002Fproject limits across hosts.\n\nFor NFS\u002Fnetwork-backed random I\u002FO or many small files, stage the required inputs\nto verified host-local SSD\u002FNVMe before compute. Bound transfers independently\nof workers: avoid all hosts flooding one shared disk\u002Flink. Use resumable copies\nor packed shards with an input manifest\u002Fchecksums; validate before use. Reserve\nspace for outputs, checkpoints and temporary expansion. If it does not fit,\nstage bounded chunks. Do not move the whole dataset to RAM or silently revert\nto random NFS access. Measure staging, reads, writes and final sync separately.\n\n## Smoke and profile before scale\n\nRun the real pipeline on representative small, typical, largest and malformed\ninputs, with the same environment, mounts and backend intended for the batch.\nCheck output correctness first, then measure a warmed-up sustained sample:\n\n- Stage wall times, items\u002Fs, p50\u002Fp95 item duration and scheduler overhead.\n- Peak **process-tree\u002Fcgroup** RAM, peak VRAM, CPU\u002FGPU duty cycle, I\u002FO wait,\n  disk\u002Fnetwork throughput, and output\u002Fscratch growth.\n- For a bottleneck, use a short relevant trace: `pidstat`\u002F`iostat`, Python\n  profiling, PyTorch Profiler or Nsight Systems. Avoid an expensive full-run\n  trace. Confirm profiler overhead with an unprofiled timing sample.\n\nIncrease concurrency in bounded steps only while useful throughput improves\nwithin the resource budget. Account for parent\u002Fworker memory, model replicas,\nprefetch buffers and library thread pools. Set BLAS\u002FOpenMP\u002Fframework threads\nexplicitly so outer workers do not multiply inner threads without a budget.\nDo not use GPU for a CPU-only tool or infer acceleration from utilization.\n\nChoose worker count from the effective budget above, measured peak RAM with\nheadroom, VRAM, scratch, and observed storage\u002Fnetwork limits. With no execution\nheadroom, submit only a request that can eventually fit, within submission\nlimits; report QUEUED only with backend acceptance. Preserve personal shared-host\ncaps; dedicated-host permission changes only the owner's cap for that run.\nRecord the measurements and selected limits.\nFor RAM, subtract shared overhead and reserve first, then divide by measured\nper-worker peak: `floor((budget - shared - reserve) \u002F worker_peak)`. Recheck the\naggregate at that concurrency; neither RSS sums nor this estimate are a limit.\n\n## Partition and admit work\n\nKeep more bounded shards than execution slots; size by measured cost (pages,\npixels, tokens, bytes or prior time), not just equal file counts. Separate\noutliers\u002Fresource classes so one huge item does not stall a whole barrier.\nUse dynamic assignment of ready shards with bounded in-flight work and\nbackpressure between CPU decode, GPU inference, and output stages. Prefer data\nlocality when transfer cost exceeds rebalancing benefit. Rebalance remaining\nwork, not already running stateful jobs; avoid speculative duplicate side\neffects. Multi-GPU training needs coherent allocation, not independent workers.\n\nSubmit through the selected backend with explicit CPU\u002FRAM\u002FGPU\u002Ftime requests\nand OS-enforced limits where supported. Keep one authority for admission;\nnested Ray\u002FDask\u002FParallel workers must fit inside its allocation. Full hosts\nleave work pending in a durable queue, with its job ID and reason recorded.\nRespect pending-job\u002Fsubmission caps too; retain excess shards in the durable\nmanifest instead of flooding the scheduler. If even one shard exceeds a hard\nper-job limit, reduce\u002Frepartition it or report BLOCKED; waiting cannot fix it.\nPressure during execution stops new admissions, checkpoints at safe boundaries\nand requeues unfinished work. Do not evict other users or run a busy retry loop.\nUse bounded backoff and a real backend\u002Ftimer wake-up; a note saying \"queued\" is\nnot a queue. Separate remote API quotas from local compute capacity.\n\n## Prove recovery before unattended execution\n\nUse stable task\u002Fshard IDs tied to the input manifest, code revision, environment\nand parameters. Store pending\u002Frunning\u002Fvalidated\u002Ffailed status durably, with\nattempt ownership, logs, retry limit and exact resume command. A scheduler\nrestart retries work; it does not restore application state automatically.\n\nWrite results\u002Fcheckpoints to temporary files on local disk, flush and atomically\nrename on the same filesystem after validation. Replicate validated generations\nto durable storage with checksums and a completion marker committed last. Retain\nthe previous good generation until the new copy is verified. Never consume a\npartly copied checkpoint or treat file existence as success. Bound and record\nthe amount of work that can be lost between durable checkpoints.\n\nFor training, capture optimizer\u002Fscheduler\u002Fscaler, RNG, sampler\u002Fdata cursor and\nstep as well as model weights when required by the framework's resume contract.\nMake outputs idempotent; reclaim abandoned work only after verifying its owner\nis gone. For at-least-once execution, validate before skipping completed shards.\n\nOn a tiny **task-owned** fixture, interrupt a worker, restart through the actual\nbackend, and verify: completed outputs are unchanged; incomplete work resumes\nor retries; a partial\u002Fcorrupt checkpoint is rejected; output counts\u002Fchecksums\nmatch; no duplicate owner commits results. Test a resource-full pending state\nand release as well. Never reboot a shared host for this test.\n\nProve restart persistence separately (persistent units, enabled boot\u002Ftimer\nactivation, user lingering when needed, mounts\u002Fenvironment available after\nlogin loss). A transient `systemd-run`, `nohup`, or `tmux` is not reboot recovery.\nAfter an actual incident recheck uptime, mounts, driver, limits and the durable\nmanifest before resuming. Respect any private cooldown\u002Fhealth conditions.\nReport reboot recovery as UNVERIFIED unless actually observed; interruption\ntesting alone cannot prove power-loss recovery.\n\n## Evidence and stopping conditions\n\nKeep private execution evidence under the task's existing evidence directory or\n`~\u002F.clade\u002Fcompute\u002F\u003Crun-id>\u002F`: preflight timestamps, selected backend\u002Fversion and\nplacement, code\u002Finput IDs, resource requests and enforced limits, staging checks,\neffective quota scopes\u002Fusage and admission decisions,\nsmoke\u002Fprofiling measurements, worker\u002Fshard tuning, queue IDs, recovery test and\nresume command, checkpoint locations, output validation and final job status.\n\nDo not scale after failed correctness, unknown mandatory resources, inadequate\nspace, or failed recovery. Park a broken scheduler\u002Fdriver with its observed\nerror and continue independent preparation. Do not reset nodes, reboot, install\nsystem packages or alter shared scheduling policy by inference. Distinguish\nPREPARED, QUEUED, RUNNING, COMPLETE and BLOCKED; a submitted job is not completed\ninference. Completion includes validated outputs and verified durable sync.\nIf the backend cannot accept work, report PREPARED\u002FBLOCKED with the saved\nsubmission plan; call it QUEUED only after a real durable queue accepts it.\n","# Compute — measure, admit, run, recover\n\nUse existing schedulers and profilers. This workflow selects and verifies them;\nit is not a scheduler and does not reserve capacity by itself. Do not build a\nnew queue or deploy a cluster merely to execute a batch.\n\n## Resolve placement and the execution backend\n\nRead `~\u002F.clade\u002Fcompute-policy.md` when present, then the project's execution\ninstructions and the site's acceptable-use policy. Keep private hostnames,\npaths, budgets, and incident notes in that user-owned file, outside public\nrepositories. Current user instructions supersede older personal preferences;\nthey do not implicitly waive site restrictions or grant administrator access.\nIf the profile is missing, use known authorized resources and record defaults;\ndo not invent remote hosts, reservations, or permission to displace others.\nThe profile is optional: a standalone local machine can use a bounded local\nrunner after the same preflight. No specific host, quota value or scheduler is\nrequired by Clade itself.\n\nResolve the site's effective limits for the chosen user, group\u002Fproject\u002Faccount,\npartition\u002Fqueue and service class (such as QOS), using its documented precedence.\nCheck CPU\u002FGPU\u002FRAM, concurrent and submitted job counts, wall time\u002Fcompute credits,\nand storage bytes\u002Finodes where applicable. Record scope, source, current usage\nand remaining allowance; include other jobs\u002Fsessions charged to that scope.\nDo not give each host or worker a fresh copy of a fleet-wide allowance. Derive\nthis run's budget from the effective remaining quotas, its actual allocation,\nproject\u002Fuser caps, physical headroom and enforced cgroup\u002FOS limits together.\nAn idle host or free VRAM is not an allocation. Personal preferences and\ndedicated-host permission cannot relax site restrictions or other binding caps.\nIf quota details are hidden, use the site's authoritative admission system and\nrecord what remains unknown; missing visibility is not unlimited entitlement.\nIf neither authorized limits nor authoritative admission can be established,\nkeep that lane PREPARED\u002FBLOCKED instead of guessing a fleet-wide allowance.\n\nBefore starting even a compute smoke run, state its host, backend, resource\nlimits, and scratch location. Follow the profile's host tiers; within a tier,\nchoose by current headroom, data locality, and measured end-to-end throughput.\nUse fallback hosts only under the profile's conditions. A shell on a machine\nis not a reason to run the batch there.\n\nRead [backend selection](references\u002Fbackend-selection.md) for the applicable\nbackend. Inspect what is actually installed and usable: command\u002Fversion,\ncontroller connectivity, node state, user access, resource enforcement, and\ndurable restart support. An installed Slurm client, empty queue, live Ray\ndashboard, or `tmux` session is not proof of readiness. If site policy requires\na broken backend, park that lane with evidence; do not bypass it.\n\n## Preflight and local staging\n\nCapture a timestamped snapshot on each candidate host:\n\n- CPU affinity\u002Fcgroup quota and load; available RAM, swap pressure and effective\n  ancestor cgroup limits; other users' workload totals without their secrets.\n- GPU model, utilization, free VRAM, active allocations\u002Fprocesses and driver\n  health. A failed probe means unknown capacity, never an idle GPU.\n- Source, scratch and checkpoint mount types, local disk space\u002Finodes, and\n  network\u002FI\u002FO pressure. Resolve symlinks: a path named `ssd` may still be NFS.\n- Scheduler allocations plus work outside it. Recheck at admission; the\n  snapshot is not a reservation. Coordinate our simultaneous sessions through\n  the existing scheduler or one shared admission mechanism covering every\n  applicable quota scope, including aggregate user\u002Fproject limits across hosts.\n\nFor NFS\u002Fnetwork-backed random I\u002FO or many small files, stage the required inputs\nto verified host-local SSD\u002FNVMe before compute. Bound transfers independently\nof workers: avoid all hosts flooding one shared disk\u002Flink. Use resumable copies\nor packed shards with an input manifest\u002Fchecksums; validate before use. Reserve\nspace for outputs, checkpoints and temporary expansion. If it does not fit,\nstage bounded chunks. Do not move the whole dataset to RAM or silently revert\nto random NFS access. Measure staging, reads, writes and final sync separately.\n\n## Smoke and profile before scale\n\nRun the real pipeline on representative small, typical, largest and malformed\ninputs, with the same environment, mounts and backend intended for the batch.\nCheck output correctness first, then measure a warmed-up sustained sample:\n\n- Stage wall times, items\u002Fs, p50\u002Fp95 item duration and scheduler overhead.\n- Peak **process-tree\u002Fcgroup** RAM, peak VRAM, CPU\u002FGPU duty cycle, I\u002FO wait,\n  disk\u002Fnetwork throughput, and output\u002Fscratch growth.\n- For a bottleneck, use a short relevant trace: `pidstat`\u002F`iostat`, Python\n  profiling, PyTorch Profiler or Nsight Systems. Avoid an expensive full-run\n  trace. Confirm profiler overhead with an unprofiled timing sample.\n\nIncrease concurrency in bounded steps only while useful throughput improves\nwithin the resource budget. Account for parent\u002Fworker memory, model replicas,\nprefetch buffers and library thread pools. Set BLAS\u002FOpenMP\u002Fframework threads\nexplicitly so outer workers do not multiply inner threads without a budget.\nDo not use GPU for a CPU-only tool or infer acceleration from utilization.\n\nChoose worker count from the effective budget above, measured peak RAM with\nheadroom, VRAM, scratch, and observed storage\u002Fnetwork limits. With no execution\nheadroom, submit only a request that can eventually fit, within submission\nlimits; report QUEUED only with backend acceptance. Preserve personal shared-host\ncaps; dedicated-host permission changes only the owner's cap for that run.\nRecord the measurements and selected limits.\nFor RAM, subtract shared overhead and reserve first, then divide by measured\nper-worker peak: `floor((budget - shared - reserve) \u002F worker_peak)`. Recheck the\naggregate at that concurrency; neither RSS sums nor this estimate are a limit.\n\n## Partition and admit work\n\nKeep more bounded shards than execution slots; size by measured cost (pages,\npixels, tokens, bytes or prior time), not just equal file counts. Separate\noutliers\u002Fresource classes so one huge item does not stall a whole barrier.\nUse dynamic assignment of ready shards with bounded in-flight work and\nbackpressure between CPU decode, GPU inference, and output stages. Prefer data\nlocality when transfer cost exceeds rebalancing benefit. Rebalance remaining\nwork, not already running stateful jobs; avoid speculative duplicate side\neffects. Multi-GPU training needs coherent allocation, not independent workers.\n\nSubmit through the selected backend with explicit CPU\u002FRAM\u002FGPU\u002Ftime requests\nand OS-enforced limits where supported. Keep one authority for admission;\nnested Ray\u002FDask\u002FParallel workers must fit inside its allocation. Full hosts\nleave work pending in a durable queue, with its job ID and reason recorded.\nRespect pending-job\u002Fsubmission caps too; retain excess shards in the durable\nmanifest instead of flooding the scheduler. If even one shard exceeds a hard\nper-job limit, reduce\u002Frepartition it or report BLOCKED; waiting cannot fix it.\nPressure during execution stops new admissions, checkpoints at safe boundaries\nand requeues unfinished work. Do not evict other users or run a busy retry loop.\nUse bounded backoff and a real backend\u002Ftimer wake-up; a note saying \"queued\" is\nnot a queue. Separate remote API quotas from local compute capacity.\n\n## Prove recovery before unattended execution\n\nUse stable task\u002Fshard IDs tied to the input manifest, code revision, environment\nand parameters. Store pending\u002Frunning\u002Fvalidated\u002Ffailed status durably, with\nattempt ownership, logs, retry limit and exact resume command. A scheduler\nrestart retries work; it does not restore application state automatically.\n\nWrite results\u002Fcheckpoints to temporary files on local disk, flush and atomically\nrename on the same filesystem after validation. Replicate validated generations\nto durable storage with checksums and a completion marker committed last. Retain\nthe previous good generation until the new copy is verified. Never consume a\npartly copied checkpoint or treat file existence as success. Bound and record\nthe amount of work that can be lost between durable checkpoints.\n\nFor training, capture optimizer\u002Fscheduler\u002Fscaler, RNG, sampler\u002Fdata cursor and\nstep as well as model weights when required by the framework's resume contract.\nMake outputs idempotent; reclaim abandoned work only after verifying its owner\nis gone. For at-least-once execution, validate before skipping completed shards.\n\nOn a tiny **task-owned** fixture, interrupt a worker, restart through the actual\nbackend, and verify: completed outputs are unchanged; incomplete work resumes\nor retries; a partial\u002Fcorrupt checkpoint is rejected; output counts\u002Fchecksums\nmatch; no duplicate owner commits results. Test a resource-full pending state\nand release as well. Never reboot a shared host for this test.\n\nProve restart persistence separately (persistent units, enabled boot\u002Ftimer\nactivation, user lingering when needed, mounts\u002Fenvironment available after\nlogin loss). A transient `systemd-run`, `nohup`, or `tmux` is not reboot recovery.\nAfter an actual incident recheck uptime, mounts, driver, limits and the durable\nmanifest before resuming. Respect any private cooldown\u002Fhealth conditions.\nReport reboot recovery as UNVERIFIED unless actually observed; interruption\ntesting alone cannot prove power-loss recovery.\n\n## Evidence and stopping conditions\n\nKeep private execution evidence under the task's existing evidence directory or\n`~\u002F.clade\u002Fcompute\u002F\u003Crun-id>\u002F`: preflight timestamps, selected backend\u002Fversion and\nplacement, code\u002Finput IDs, resource requests and enforced limits, staging checks,\neffective quota scopes\u002Fusage and admission decisions,\nsmoke\u002Fprofiling measurements, worker\u002Fshard tuning, queue IDs, recovery test and\nresume command, checkpoint locations, output validation and final job status.\n\nDo not scale after failed correctness, unknown mandatory resources, inadequate\nspace, or failed recovery. Park a broken scheduler\u002Fdriver with its observed\nerror and continue independent preparation. Do not reset nodes, reboot, install\nsystem packages or alter shared scheduling policy by inference. Distinguish\nPREPARED, QUEUED, RUNNING, COMPLETE and BLOCKED; a submitted job is not completed\ninference. Completion includes validated outputs and verified durable sync.\nIf the backend cannot accept work, report PREPARED\u002FBLOCKED with the saved\nsubmission plan; call it QUEUED only after a real durable queue accepts it.\n",{"name":5,"description":7},"main","60a901a00f46e71601f58727cb5661f8d3fb6d24","configs\u002Fskills\u002Fcompute",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-10 11:54:03",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add shenxingy\u002FClade --skill compute",{"tool":69,"command":70},"bunx","bunx skills add shenxingy\u002FClade --skill compute",{"tool":72,"command":73},"pnpm","pnpm dlx skills add shenxingy\u002FClade --skill compute","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fcompute\u002FSKILL.md",true,[77],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fbackend-selection.md","REFERENCE","参考文档",7866,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fcompute\u002Freferences\u002Fbackend-selection.md",[84,105,133,154,178,195],{"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":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",[90],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[86,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":91,"categoryName":92,"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,129,130,131,132,41],"web search","search","web","repository","file","research","MCP","requests","collection","reading","URL","native","bulk","progress","file search","route","tinyfish","evidence","check",{"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":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},[135,141,142,143,144,145,146,147,148,149,150,151,152,153],"app","single","features","which","interaction","tests","project","observe","autonomous","behavior","list","change","codex",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":161,"publishedAt":48},"01M6FNNX95R9H29BNERFY15704","tasks","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",[160],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},[156,162,163,164,147,35,165,166,167,168,169,170,171,172,36,173,174,175,176,177,153],"for","plans","work","across","human","task","coordinate","kimi","snapshots","agent monitoring","dependency","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":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},[180,186,187,188,189,190,191,192,127,193,194],"session","run","documentation","commit","only","documentation sync","updates","end","todo",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":202,"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",[201],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},[197,99,203,204,162,192,205,206,127,207,100,208,209,36,210,164,39,211,102,212],"running","limits","usage","now","active","show","provider","snapshot","execution","identity"]