[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7A9M3N77Z95XQQSWF10ZF2J":3,"skill-same:01M7A9M3N77Z95XQQSWF10ZF2J":81},{"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":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M7A9M3N77Z95XQQSWF10ZF2J","nemo-rl-auto-research",null,"Autonomous NeMo-RL research agent workflow for directed hypothesis testing and open-ended discovery. Guides agents through the full experiment lifecycle: understanding recipes and environments, wiring RL or NeMo-gym runs, launching reproducible baselines and iterations, analyzing results, preserving human oversight, and using git plus TSV logs as the research ledger. Do NOT use for: bug fixes, code review, documentation, refactoring, dependency updates, or single-file changes.","themusebook\u002Fskills","themusebook","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F349927247?v=4","01M7A5C1RV5S3V5FF6ZACVDNRN","musebook","01M7A5C1SFC3KRZAXNN60XJ7KM",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fnemo-rl-auto-research\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: nemo-rl-auto-research\nlicense: Apache-2.0\ndescription: \"Autonomous NeMo-RL research agent workflow for directed hypothesis testing and open-ended discovery. Guides agents through the full experiment lifecycle: understanding recipes and environments, wiring RL or NeMo-gym runs, launching reproducible baselines and iterations, analyzing results, preserving human oversight, and using git plus TSV logs as the research ledger. Do NOT use for: bug fixes, code review, documentation, refactoring, dependency updates, or single-file changes.\"\nwhen_to_use: auto research; run experiments; test these hypotheses; find a better recipe; improve accuracy; long-running NeMo-RL or NeMo-gym research campaigns; autonomous discovery; directed execution.\n---\n\n# Auto Research\n\nRun iterative NeMo-RL experiments in this repository against the user's stated objective, such as accuracy, reward, throughput, latency, stability, or another recipe-specific metric, with git as the research ledger.\n\nTreat dependencies as ready, but choose the runtime deliberately. Use the recipe's authoritative metric as the source of truth. Keep changes small, reproducible, and simple. Preserve unrelated user work.\n\n**Safety:** This skill creates git branches, writes files to disk, and executes shell commands including training jobs that may consume GPU resources. Always confirm the campaign plan with the user before creating branches or launching jobs. Do not execute destructive git operations (reset, force-push) or launch compute-intensive jobs without explicit user approval.\n\nUse the `nemo-rl-session-memory` skill for every auto-research campaign. Start or resume a session record before branching, then checkpoint after forming the plan, before and after meaningful edits or long-running launches, when the user changes direction, and before handoff or final summary.\n\nAfter context compaction, handoff, disconnect, or a long gap, reload this skill and any companion skills already in use, read the latest `nemo-rl-session-memory` handoff, and restate the overall objective, stop rules, current branch, and latest result before continuing. Treat follow-up steering as additive unless the user explicitly changes the main objective.\n\n## Workflow\n\n1. Inspect the current git state and identify unrelated user changes before branching.\n2. Use a shared branch prefix. Prefer a user-provided one; otherwise create a suggestive default such as `autoresearch\u002F2026-03-24-dapo-qwen2p5`.\n3. Read the target recipe, its parents, and the relevant code paths in `examples\u002Frun_grpo.py`, `nemo_rl\u002Fmodels\u002F`, `nemo_rl\u002Falgorithms\u002F`, `nemo_rl\u002Fenvironments\u002F`, and `docs\u002F`. For NeMo-gym recipes, also inspect `examples\u002Fnemo_gym\u002F` entrypoints, configs, and launch scripts.\n4. Translate any user stop rule into explicit values you can monitor, such as the requested number of experiments as `target_experiment_count`, `campaign_deadline`, `per_experiment_timeout`, or `target_metric`.\n5. Verify required data, checkpoints, runtime inputs, and the launcher.\n6. Create an untracked TSV log and per-experiment log directory.\n7. Run a baseline first on `\u003Cprefix>\u002Fbaseline` if none exists.\n\nFor GPU, CPU-heavy, distributed, or long-running work, choose the execution environment deliberately. Run locally when the current machine has suitable GPUs and capacity; otherwise follow the user's requested environment, use `launch-nemo-rl` for nrl-k8s\u002FKubernetes, use the environment's native launcher for Slurm, or clarify with the user before launching. Use CPU-only local runs only for light inspection, dry runs, and short non-GPU checks.\n\nIf the user mentions Brev, or if `\u002Fhome\u002Fubuntu\u002FRL` exists and `\u002Fephemeral` is available as a volume, treat the machine as a Brev instance and use `nemo-rl-brev-etiquette` before creating experiment directories, caches, logs, checkpoints, or authenticated runtime state.\n\n## Branching\n\n- Put every experiment on its own branch under the shared prefix.\n- Keep every branch, even for failed or weak ideas.\n- Put at least one commit on each branch for the hypothesis.\n- Add follow-up fix commits on the same branch when a rerun is justified.\n- Never stash, reset, or overwrite unrelated user changes silently. If dirty files overlap the experiment, use a separate worktree or ask before proceeding.\n\nSee `references\u002Fgit-workflow.md` for the exact pattern.\n\n## Loop\n\n1. Pick one concrete hypothesis.\n2. Create a branch such as `autoresearch\u002F2026-03-24-dapo-qwen2p5\u002Fprompt-compact-schema`.\n3. Edit the smallest set of files needed.\n4. Commit the hypothesis.\n5. Before launching the run, check the monitored stop conditions. Do not stop early unless one is already clearly met.\n6. Identify the authoritative metric source from the recipe or logging code, then run with a unique log path:\n\n```bash\nLOG_DIR=reports\u002Fauto_research\u002F\u003Ccampaign>\u002F\u003Cexperiment>\nmkdir -p \"$LOG_DIR\"\nuv run \u003Centrypoint> > \"$LOG_DIR\u002Frun.log\" 2>&1\n```\n\n7. If the user gave a per-experiment wall-clock limit, enforce it explicitly. Prefer a recipe-level timeout when one already exists; otherwise wrap the command with an external timeout. If both exist, honor the tighter limit.\n8. Extract the primary metric with a command appropriate for the actual log format. If extraction is empty, inspect the last log lines and the recipe's logging path before marking the run.\n9. Record index, branch, parent commit, commit, recipe, metric name, metric value, memory (GB), elapsed time (minutes), launcher, job id, command, log path, status, and description in the TSV, along with enough timing or count information to evaluate the stop rule.\n10. Periodically print user-facing progress updates during the campaign. Include the current branch, latest known result, attempted experiment count, remaining experiment count if applicable, remaining campaign time if applicable, and whether any stop condition has been met yet.\n11. Re-check the monitored stop conditions after the experiment completes and state the result explicitly, for example `stop condition not yet met: 17\u002F24 attempted, 6h12m remaining` or `stop condition met: 24\u002F24 attempted`.\n12. Mark the result as `keep`, `discard`, or `crash`, then move to the next branch unless a user-specified stop condition has been clearly met.\n\nFor count-based stop rules, count attempted ideas, not only successful or fully completed runs.\n\nFor campaign time budgets, convert the user limit into an absolute deadline at the start of the campaign and keep checking remaining time.\n\nFor per-experiment budgets, enforce a timeout on every run and treat overruns as failures.\n\nExamples:\n- `do 50 experiments`: stop only after 50 attempted experiment rows exist in the TSV\n- `10h total, 1h each`: enforce a 1 hour limit per run and stop when the 10 hour campaign budget is reached, or when there is not enough remaining budget to start another 1 hour run\n- `50 experiments or 10h total, 1h each`: monitor all three values, never exceed the per-run cap, and stop only when one campaign-level stop trigger is clearly reached\n\n## Priorities\n\nPrefer ideas with high expected objective gain and low complexity cost:\n- correctness and backend compatibility\n- prompt and rollout formatting\n- batch, sequence, and precision layout\n- optimizer and scheduler tuning\n- reward shaping, clipping, or scaling\n- dataset mix or validation changes\n- synchronous versus asynchronous execution based on hardware\n\nAll else equal, prefer simpler wins and avoid brittle hardware-specific hacks.\n\n## Avoid\n\n- Do not conclude a training idea failed from an underpowered smoke run. If a run uses tiny batch sizes, very few optimizer steps, or otherwise non-representative settings, treat it as plumbing validation only; scale to a meaningful batch size and train long enough to test the hypothesis before marking it `discard`.\n- Do not repeatedly pay batch-scheduler setup costs for tight edit-run-debug loops. If Slurm batch jobs have a large startup tax and failures require quick iteration, use the documented interactive Slurm pattern or ask the user before resubmitting more batch jobs.\n- Do not let context compaction or follow-up steering questions erase the original campaign goal. Refresh `nemo-rl-session-memory`, reload active skills, and preserve the main objective unless the user explicitly changes it.\n\n## Stop\n\nIf the user gives explicit stopping conditions, they override the generic rule. Do not stop because the search feels sufficient; stop only when the requested count, deadline, budget, or target condition has been clearly met.\n\nDuring the campaign, explicitly inform the user whether the stop condition has been met. If not, report the remaining count, remaining time, or other remaining threshold in concrete terms.\n\nIf the user does not give explicit stopping conditions, run the baseline plus up to three low-risk experiments, then summarize the best result and ask before continuing.\n\n## References\n\n- `references\u002Fgit-workflow.md` for branch, dirty-worktree, parent-commit, and baseline rules.\n- `references\u002Fexploration-ideas.md` for turning symptoms into concrete hypotheses.\n- `references\u002Fexperiment-log-template.md` for the TSV schema and reproducibility fields.\n","# Auto Research\n\nRun iterative NeMo-RL experiments in this repository against the user's stated objective, such as accuracy, reward, throughput, latency, stability, or another recipe-specific metric, with git as the research ledger.\n\nTreat dependencies as ready, but choose the runtime deliberately. Use the recipe's authoritative metric as the source of truth. Keep changes small, reproducible, and simple. Preserve unrelated user work.\n\n**Safety:** This skill creates git branches, writes files to disk, and executes shell commands including training jobs that may consume GPU resources. Always confirm the campaign plan with the user before creating branches or launching jobs. Do not execute destructive git operations (reset, force-push) or launch compute-intensive jobs without explicit user approval.\n\nUse the `nemo-rl-session-memory` skill for every auto-research campaign. Start or resume a session record before branching, then checkpoint after forming the plan, before and after meaningful edits or long-running launches, when the user changes direction, and before handoff or final summary.\n\nAfter context compaction, handoff, disconnect, or a long gap, reload this skill and any companion skills already in use, read the latest `nemo-rl-session-memory` handoff, and restate the overall objective, stop rules, current branch, and latest result before continuing. Treat follow-up steering as additive unless the user explicitly changes the main objective.\n\n## Workflow\n\n1. Inspect the current git state and identify unrelated user changes before branching.\n2. Use a shared branch prefix. Prefer a user-provided one; otherwise create a suggestive default such as `autoresearch\u002F2026-03-24-dapo-qwen2p5`.\n3. Read the target recipe, its parents, and the relevant code paths in `examples\u002Frun_grpo.py`, `nemo_rl\u002Fmodels\u002F`, `nemo_rl\u002Falgorithms\u002F`, `nemo_rl\u002Fenvironments\u002F`, and `docs\u002F`. For NeMo-gym recipes, also inspect `examples\u002Fnemo_gym\u002F` entrypoints, configs, and launch scripts.\n4. Translate any user stop rule into explicit values you can monitor, such as the requested number of experiments as `target_experiment_count`, `campaign_deadline`, `per_experiment_timeout`, or `target_metric`.\n5. Verify required data, checkpoints, runtime inputs, and the launcher.\n6. Create an untracked TSV log and per-experiment log directory.\n7. Run a baseline first on `\u003Cprefix>\u002Fbaseline` if none exists.\n\nFor GPU, CPU-heavy, distributed, or long-running work, choose the execution environment deliberately. Run locally when the current machine has suitable GPUs and capacity; otherwise follow the user's requested environment, use `launch-nemo-rl` for nrl-k8s\u002FKubernetes, use the environment's native launcher for Slurm, or clarify with the user before launching. Use CPU-only local runs only for light inspection, dry runs, and short non-GPU checks.\n\nIf the user mentions Brev, or if `\u002Fhome\u002Fubuntu\u002FRL` exists and `\u002Fephemeral` is available as a volume, treat the machine as a Brev instance and use `nemo-rl-brev-etiquette` before creating experiment directories, caches, logs, checkpoints, or authenticated runtime state.\n\n## Branching\n\n- Put every experiment on its own branch under the shared prefix.\n- Keep every branch, even for failed or weak ideas.\n- Put at least one commit on each branch for the hypothesis.\n- Add follow-up fix commits on the same branch when a rerun is justified.\n- Never stash, reset, or overwrite unrelated user changes silently. If dirty files overlap the experiment, use a separate worktree or ask before proceeding.\n\nSee `references\u002Fgit-workflow.md` for the exact pattern.\n\n## Loop\n\n1. Pick one concrete hypothesis.\n2. Create a branch such as `autoresearch\u002F2026-03-24-dapo-qwen2p5\u002Fprompt-compact-schema`.\n3. Edit the smallest set of files needed.\n4. Commit the hypothesis.\n5. Before launching the run, check the monitored stop conditions. Do not stop early unless one is already clearly met.\n6. Identify the authoritative metric source from the recipe or logging code, then run with a unique log path:\n\n```bash\nLOG_DIR=reports\u002Fauto_research\u002F\u003Ccampaign>\u002F\u003Cexperiment>\nmkdir -p \"$LOG_DIR\"\nuv run \u003Centrypoint> > \"$LOG_DIR\u002Frun.log\" 2>&1\n```\n\n7. If the user gave a per-experiment wall-clock limit, enforce it explicitly. Prefer a recipe-level timeout when one already exists; otherwise wrap the command with an external timeout. If both exist, honor the tighter limit.\n8. Extract the primary metric with a command appropriate for the actual log format. If extraction is empty, inspect the last log lines and the recipe's logging path before marking the run.\n9. Record index, branch, parent commit, commit, recipe, metric name, metric value, memory (GB), elapsed time (minutes), launcher, job id, command, log path, status, and description in the TSV, along with enough timing or count information to evaluate the stop rule.\n10. Periodically print user-facing progress updates during the campaign. Include the current branch, latest known result, attempted experiment count, remaining experiment count if applicable, remaining campaign time if applicable, and whether any stop condition has been met yet.\n11. Re-check the monitored stop conditions after the experiment completes and state the result explicitly, for example `stop condition not yet met: 17\u002F24 attempted, 6h12m remaining` or `stop condition met: 24\u002F24 attempted`.\n12. Mark the result as `keep`, `discard`, or `crash`, then move to the next branch unless a user-specified stop condition has been clearly met.\n\nFor count-based stop rules, count attempted ideas, not only successful or fully completed runs.\n\nFor campaign time budgets, convert the user limit into an absolute deadline at the start of the campaign and keep checking remaining time.\n\nFor per-experiment budgets, enforce a timeout on every run and treat overruns as failures.\n\nExamples:\n- `do 50 experiments`: stop only after 50 attempted experiment rows exist in the TSV\n- `10h total, 1h each`: enforce a 1 hour limit per run and stop when the 10 hour campaign budget is reached, or when there is not enough remaining budget to start another 1 hour run\n- `50 experiments or 10h total, 1h each`: monitor all three values, never exceed the per-run cap, and stop only when one campaign-level stop trigger is clearly reached\n\n## Priorities\n\nPrefer ideas with high expected objective gain and low complexity cost:\n- correctness and backend compatibility\n- prompt and rollout formatting\n- batch, sequence, and precision layout\n- optimizer and scheduler tuning\n- reward shaping, clipping, or scaling\n- dataset mix or validation changes\n- synchronous versus asynchronous execution based on hardware\n\nAll else equal, prefer simpler wins and avoid brittle hardware-specific hacks.\n\n## Avoid\n\n- Do not conclude a training idea failed from an underpowered smoke run. If a run uses tiny batch sizes, very few optimizer steps, or otherwise non-representative settings, treat it as plumbing validation only; scale to a meaningful batch size and train long enough to test the hypothesis before marking it `discard`.\n- Do not repeatedly pay batch-scheduler setup costs for tight edit-run-debug loops. If Slurm batch jobs have a large startup tax and failures require quick iteration, use the documented interactive Slurm pattern or ask the user before resubmitting more batch jobs.\n- Do not let context compaction or follow-up steering questions erase the original campaign goal. Refresh `nemo-rl-session-memory`, reload active skills, and preserve the main objective unless the user explicitly changes it.\n\n## Stop\n\nIf the user gives explicit stopping conditions, they override the generic rule. Do not stop because the search feels sufficient; stop only when the requested count, deadline, budget, or target condition has been clearly met.\n\nDuring the campaign, explicitly inform the user whether the stop condition has been met. If not, report the remaining count, remaining time, or other remaining threshold in concrete terms.\n\nIf the user does not give explicit stopping conditions, run the baseline plus up to three low-risk experiments, then summarize the best result and ask before continuing.\n\n## References\n\n- `references\u002Fgit-workflow.md` for branch, dirty-worktree, parent-commit, and baseline rules.\n- `references\u002Fexploration-ideas.md` for turning symptoms into concrete hypotheses.\n- `references\u002Fexperiment-log-template.md` for the TSV schema and reproducibility fields.\n",{"name":5,"license":15,"description":7,"when_to_use":24},"auto research; run experiments; test these hypotheses; find a better recipe; improve accuracy; long-running NeMo-RL or NeMo-gym research campaigns; autonomous discovery; directed execution.","main","1c523aba5cdf867a79f078847075492d7778092a","skills\u002Fnvidia\u002Fnemo-rl-auto-research",1,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills","https:\u002F\u002Fskills.x402.wtf","https:\u002F\u002Fgithub.com\u002Fthemusebook","https:\u002F\u002Fmusebook.trade","The official Github of musebook","2026-11-02 23:42:26",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add themusebook\u002Fskills --skill nemo-rl-auto-research",{"tool":41,"command":42},"bunx","bunx skills add themusebook\u002Fskills --skill nemo-rl-auto-research",{"tool":44,"command":45},"pnpm","pnpm dlx skills add themusebook\u002Fskills --skill nemo-rl-auto-research","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fnemo-rl-auto-research\u002FSKILL.md",true,[49,55,59,63,67,71,75],{"path":50,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":54},"BENCHMARK.md","REFERENCE","参考文档",4252,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fnemo-rl-auto-research\u002FBENCHMARK.md",{"path":56,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":57,"sourceHtmlUrl":58},"evals\u002Fevals.json",3216,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fnemo-rl-auto-research\u002Fevals\u002Fevals.json",{"path":60,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":61,"sourceHtmlUrl":62},"references\u002Fexperiment-log-template.md",2582,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fnemo-rl-auto-research\u002Freferences\u002Fexperiment-log-template.md",{"path":64,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":65,"sourceHtmlUrl":66},"references\u002Fexploration-ideas.md",5627,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fnemo-rl-auto-research\u002Freferences\u002Fexploration-ideas.md",{"path":68,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Fgit-workflow.md",3856,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fnemo-rl-auto-research\u002Freferences\u002Fgit-workflow.md",{"path":72,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":73,"sourceHtmlUrl":74},"skill-card.md",4054,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fnemo-rl-auto-research\u002Fskill-card.md",{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"skill.oms.sig","OTHER","其他",5333,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fnemo-rl-auto-research\u002Fskill.oms.sig",[82,91,98,105,112,119],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":86,"licenseFileUrl":87,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M7AB34SPKVSDRRG009PM1CZH","youtube-clipper","YouTube 视频智能剪辑工具。下载视频和字幕，AI 分析生成精细章节（几分钟级别）， 用户选择片段后自动剪辑、翻译字幕为中英双语、烧录字幕到视频，并生成总结文案。 使用场景：当用户需要剪辑 YouTube 视频、生成短视频片段、制作双语字幕版本时。 关键词：视频剪辑、YouTube、字幕翻译、双语字幕、视频下载、clip video","MIT","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-clipper\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-clipper\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":86,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":19},"01M7AB18BH6N7KR7939HRNWVMQ","viem-integration","Integrate EVM blockchains using viem. Use when user says \"read blockchain data\", \"send transaction\", \"interact with smart contract\", \"connect to Ethereum\", \"use viem\", \"use wagmi\", \"wallet integration\", \"viem setup\", or mentions blockchain\u002FEVM development with TypeScript.","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fviem-integration\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":86,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":19},"01M7AB12GHGP48WCNXDQQ9222H","v4-security-foundations","Security-first Uniswap v4 hook development. Use when user mentions \"v4 hooks\", \"hook security\", \"PoolManager\", \"beforeSwap\", \"afterSwap\", or asks about V4 hook best practices, vulnerabilities, or audit requirements.","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fv4-security-foundations\u002FSKILL.md",[],[],{"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":86,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":19},"01M7AB0XM3PSR7V3Q2ZRR0Q0FB","v4-sdk-integration","App-layer SDK guide for building swap and liquidity experiences directly with the Uniswap v4 SDK. Use when user asks about \"v4 sdk\", \"uniswap v4\", \"v4 swap\", \"v4 liquidity\", \"PoolManager\", \"V4Planner\", \"StateView\", \"PositionManager\", \"pool state\", \"v4 position\", \"uniswap sdk\", or when building swap\u002Fliquidity UX directly with SDKs rather than via the Trading API.","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fv4-sdk-integration\u002FSKILL.md",[],[],{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":86,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":19},"01M7AB0SGA93ASA588DJW4P9WT","v4-hook-generator","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.","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fv4-hook-generator\u002FSKILL.md",[],[],{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":86,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":19},"01M7AAZYH75H4CS03WSW2EZ8DM","testing","For testing with Light Protocol programs and clients on localnet, devnet, and mainnet validation.","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002FSKILL.md",[],[]]