[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BSEXR6R02SVZ0PP60FF81":3,"skill-same:01M69BSEXR6R02SVZ0PP60FF81":68},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M69BSEXR6R02SVZ0PP60FF81","cargo-anvil-adoption",null,"Complete cargo-anvil adoption in an existing Rust repository after the first cargo anvil run. Use when generated Anvil files coexist with legacy CI, recipes, scripts, tool configuration, or validation failures.","microsoft\u002Fox-tools","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BSBXT1VCZ6P12FAQYYVA2",28,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fox-tools\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcargo-anvil-adoption\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"cargo anvil adoption","adoption","cargo","anvil","use","when","Existing","with","complete","scripts","recipes","files","Legacy","rust","generated","tool","first","ci","repository","validation","run","2026-11-10 10:12:30",false,"---\nname: cargo-anvil-adoption\ndescription: Complete cargo-anvil adoption in an existing Rust repository after the first cargo anvil run. Use when generated Anvil files coexist with legacy CI, recipes, scripts, tool configuration, or validation failures.\nlicense: MIT\n---\n\n\u003C!-- GENERATED BY cargo-anvil. DO NOT EDIT DIRECTLY. -->\n\n# Complete cargo-anvil adoption\n\nUse this skill after the first `cargo anvil` run in a repository that already\ncontained Rust build and CI infrastructure. The goal is a clean, reviewable\nAnvil installation that adopts the Anvil catalog as its default build and\nvalidation contract, removes duplicate capabilities, and passes the generated\nchecks.\n\nDo the work in the repository. Do not stop at an audit or plan unless a\ndecision genuinely requires the user.\n\n## Invariants\n\n- Read the repository's instructions and design documentation before editing.\n- Preserve unrelated working-tree changes. Never discard or rewrite user work.\n- Treat existing CI, scripts, configuration, and branch policies as evidence of\n  prior behavior to evaluate, not as behavior that must be preserved.\n- Compare legacy and Anvil behavior across command arguments, operating systems,\n  feature sets, toolchains, failure policy, outputs, schedules, permissions,\n  and downstream consumers. Call out meaningful differences, then prefer the\n  Anvil behavior unless a concrete repository requirement justifies divergence.\n- Migrate justified repository requirements to Anvil-supported configuration\n  before deleting their old implementation. Do not preserve historical\n  customization solely to maintain exact legacy behavior.\n- Keep release, deployment, packaging, compliance, code-signing, and\n  other capabilities outside Anvil's scope. Keep repository-specific test\n  automation only when it covers a documented requirement that the Anvil\n  catalog does not satisfy.\n- Change cargo-anvil templates rather than generated copies when working in the\n  cargo-anvil source repository, then regenerate.\n\n## 1. Establish the adoption state\n\n1. Inspect the current branch, working tree, repository root, and remotes.\n2. Read `AGENTS.md`, nested instruction files, design docs, and contributor\n   documentation.\n3. Inspect `.anvil.lock`, generated files, and any `.anvil-proposed` siblings.\n4. Run `cargo anvil --dry-run`. Classify every proposed update, refusal,\n   customized file, disabled item, and stale manifest entry.\n5. If Anvil prerequisites are missing, run `just anvil-setup` and retry.\n\nDo not use `--force` merely to make the run succeed. Use it only when the\nrepository is intentionally switching from a different tool recorded in\n`.anvil.lock`.\n\n## 2. Inventory the existing build system\n\nSearch for all local and cloud build surfaces:\n\n- GitHub Actions, Azure DevOps pipelines, reusable templates, composite actions,\n  and scheduled jobs;\n- root and imported Justfiles, Makefiles, task runners, and developer scripts;\n- Rust toolchain files and independent tool-version lists;\n- `rustfmt.toml`, `clippy.toml`, Cargo lint tables, `deny.toml`, audit config,\n  spelling dictionaries, coverage configuration, and impact configuration;\n- mutation, Miri, Loom, fuzzing, examples, documentation, semver, external-type,\n  license, and dependency checks;\n- badges, contributor docs, agent instructions, branch protection, rulesets,\n  required contexts, and merge queues.\n\nBuild a capability map from each legacy entry point to its Anvil counterpart.\nRecord meaningful differences and unmatched behavior. For every retained\nrepository-specific capability, document the requirement that prevents using\nthe Anvil behavior.\n\n## 3. Align the repository to Anvil\n\nResolve differences at the policy source:\n\n- Merge formatting and lint policy into the repository's normal Rust,\n  rustfmt, and Clippy configuration outside Anvil-managed regions.\n- Preserve license, source, advisory, ban, and duplicate-dependency policy in\n  `deny.toml` or the relevant tool configuration.\n- Move spelling exceptions into `.spelling`.\n- Express coverage thresholds and opt-outs through cargo-coverage-gate metadata\n  or narrowly scoped source attributes. Do not preserve a second coverage\n  exclusion list when the Anvil gate cannot read it.\n- Record intentional external public types in the package metadata understood\n  by cargo-check-external-types.\n- Ensure the root MSRV and stable toolchain selection are intentional and\n  compatible with Anvil's deterministic selection rules.\n- Represent Miri exclusions next to the affected tests, using profile-specific\n  cfgs when only one scheduled profile needs an exception.\n- Represent Loom support structurally with a feature, a required-feature test\n  target, and a cfg-gated dependency.\n- Mark interactive, credentialed, destructive, or long-running examples in\n  `[package.metadata.anvil.examples].no-run`.\n\nPrefer changing repository configuration or code to weakening a generated\ncheck. Never convert discovery errors or unsupported states into silent skips.\nWhen the legacy and Anvil behaviors differ, explain the resulting behavior\nchange and recommend the Anvil standard. Preserve the legacy behavior only when\nthe repository has a current, explicit requirement that Anvil cannot represent.\n\n## 4. Resolve generated-content conflicts\n\nFor every Anvil-owned file or managed region:\n\n1. Determine whether the repository edit encodes real policy or is an obsolete\n   implementation detail.\n2. Prefer the catalog behavior. Move only justified repository policy to the\n   supported configuration surface where possible.\n3. Revert the generated content to the catalog form by running `cargo anvil`.\n4. Take ownership of generated content only when the repository has a durable\n   requirement the catalog cannot represent. Document why it must diverge.\n5. Re-run `cargo anvil --dry-run` until there are no unexplained proposals,\n   refusals, or manifest changes.\n\nDo not hand-edit emitted files when their source template is available.\n\n## 5. Evaluate differences before deleting duplicates\n\nRun the narrow Anvil recipe corresponding to each legacy capability and resolve\nits failures first. Examples:\n\n- `just anvil-fmt`\n- `just anvil-clippy`\n- `just anvil-doc-build`\n- `just anvil-pr-test`\n- `just anvil-pr-msrv`\n- `just anvil-pr-runtime-analysis`\n- `just anvil-pr-fuzzing`\n- `just anvil-pr-mutants`\n\nWhen a check fails, fix the root cause and rerun that specific recipe instead of\nrepeating the entire tier. Install missing prerequisites with the matching\n`*-setup` recipe or `just anvil-setup`.\n\nCompare results with the legacy command where behavior is not obviously\nidentical. Treat disagreements as migration decisions, not automatic Anvil\ndefects: describe the impact and adopt Anvil's behavior unless the legacy\nbehavior serves a current requirement outside the catalog. Account for impact\nscoping by using `ANVIL_IMPACT=off` when a deliberate full-workspace comparison\nis required.\n\n## 6. Remove duplicate infrastructure\n\nAfter equivalence is established:\n\n- delete legacy workflows, scheduled jobs, setup actions, recipes, and scripts\n  whose complete behavior is now owned by Anvil;\n- remove duplicate tool-version files and updaters when\n  `justfiles\u002Fanvil\u002Fversions.just` is the authoritative list;\n- update badges, contributor documentation, and agent instructions to name the\n  Anvil workflows and recipes;\n- retain scripts and pipelines only for requirements outside Anvil's scope, and\n  document the unmet requirement and why the catalog behavior is insufficient;\n- identify required status contexts or external rulesets that must change\n  before the cleanup can merge.\n\nDo not change hosted branch protection or organization policy without the\nrequired authorization. Report the exact old and new contexts for the\nmaintainer when an atomic external update is necessary.\n\n## 7. Final verification\n\n1. Run `cargo anvil` and then `cargo anvil --dry-run`; the second run must be\n   clean.\n2. Run `just anvil-pr-fast`.\n3. Run `just anvil-pr` for the complete local PR tier. If that is impractical,\n   and a generated CI backend will validate the current change, ask whether to\n   stop after the fast tier and rely on PR checks for the remaining groups. A\n   local-only installation must run the remaining groups locally. Never\n   describe partial validation as complete.\n4. Confirm generated README files and documentation are current.\n5. Search again for deleted workflow names, stale badges, old recipe names,\n   duplicate version lists, and orphaned scripts.\n6. Review the final diff for unrelated changes and accidental policy loss.\n\nFinish with:\n\n- what Anvil now owns;\n- what legacy infrastructure was removed;\n- what repository-specific infrastructure remains, which requirement it serves,\n  and why the Anvil behavior is insufficient;\n- any intentional behavioral differences;\n- any branch-policy or ruleset action required before merge;\n- the exact validation completed and anything left to cloud CI.\n","\u003C!-- GENERATED BY cargo-anvil. DO NOT EDIT DIRECTLY. -->\n\n# Complete cargo-anvil adoption\n\nUse this skill after the first `cargo anvil` run in a repository that already\ncontained Rust build and CI infrastructure. The goal is a clean, reviewable\nAnvil installation that adopts the Anvil catalog as its default build and\nvalidation contract, removes duplicate capabilities, and passes the generated\nchecks.\n\nDo the work in the repository. Do not stop at an audit or plan unless a\ndecision genuinely requires the user.\n\n## Invariants\n\n- Read the repository's instructions and design documentation before editing.\n- Preserve unrelated working-tree changes. Never discard or rewrite user work.\n- Treat existing CI, scripts, configuration, and branch policies as evidence of\n  prior behavior to evaluate, not as behavior that must be preserved.\n- Compare legacy and Anvil behavior across command arguments, operating systems,\n  feature sets, toolchains, failure policy, outputs, schedules, permissions,\n  and downstream consumers. Call out meaningful differences, then prefer the\n  Anvil behavior unless a concrete repository requirement justifies divergence.\n- Migrate justified repository requirements to Anvil-supported configuration\n  before deleting their old implementation. Do not preserve historical\n  customization solely to maintain exact legacy behavior.\n- Keep release, deployment, packaging, compliance, code-signing, and\n  other capabilities outside Anvil's scope. Keep repository-specific test\n  automation only when it covers a documented requirement that the Anvil\n  catalog does not satisfy.\n- Change cargo-anvil templates rather than generated copies when working in the\n  cargo-anvil source repository, then regenerate.\n\n## 1. Establish the adoption state\n\n1. Inspect the current branch, working tree, repository root, and remotes.\n2. Read `AGENTS.md`, nested instruction files, design docs, and contributor\n   documentation.\n3. Inspect `.anvil.lock`, generated files, and any `.anvil-proposed` siblings.\n4. Run `cargo anvil --dry-run`. Classify every proposed update, refusal,\n   customized file, disabled item, and stale manifest entry.\n5. If Anvil prerequisites are missing, run `just anvil-setup` and retry.\n\nDo not use `--force` merely to make the run succeed. Use it only when the\nrepository is intentionally switching from a different tool recorded in\n`.anvil.lock`.\n\n## 2. Inventory the existing build system\n\nSearch for all local and cloud build surfaces:\n\n- GitHub Actions, Azure DevOps pipelines, reusable templates, composite actions,\n  and scheduled jobs;\n- root and imported Justfiles, Makefiles, task runners, and developer scripts;\n- Rust toolchain files and independent tool-version lists;\n- `rustfmt.toml`, `clippy.toml`, Cargo lint tables, `deny.toml`, audit config,\n  spelling dictionaries, coverage configuration, and impact configuration;\n- mutation, Miri, Loom, fuzzing, examples, documentation, semver, external-type,\n  license, and dependency checks;\n- badges, contributor docs, agent instructions, branch protection, rulesets,\n  required contexts, and merge queues.\n\nBuild a capability map from each legacy entry point to its Anvil counterpart.\nRecord meaningful differences and unmatched behavior. For every retained\nrepository-specific capability, document the requirement that prevents using\nthe Anvil behavior.\n\n## 3. Align the repository to Anvil\n\nResolve differences at the policy source:\n\n- Merge formatting and lint policy into the repository's normal Rust,\n  rustfmt, and Clippy configuration outside Anvil-managed regions.\n- Preserve license, source, advisory, ban, and duplicate-dependency policy in\n  `deny.toml` or the relevant tool configuration.\n- Move spelling exceptions into `.spelling`.\n- Express coverage thresholds and opt-outs through cargo-coverage-gate metadata\n  or narrowly scoped source attributes. Do not preserve a second coverage\n  exclusion list when the Anvil gate cannot read it.\n- Record intentional external public types in the package metadata understood\n  by cargo-check-external-types.\n- Ensure the root MSRV and stable toolchain selection are intentional and\n  compatible with Anvil's deterministic selection rules.\n- Represent Miri exclusions next to the affected tests, using profile-specific\n  cfgs when only one scheduled profile needs an exception.\n- Represent Loom support structurally with a feature, a required-feature test\n  target, and a cfg-gated dependency.\n- Mark interactive, credentialed, destructive, or long-running examples in\n  `[package.metadata.anvil.examples].no-run`.\n\nPrefer changing repository configuration or code to weakening a generated\ncheck. Never convert discovery errors or unsupported states into silent skips.\nWhen the legacy and Anvil behaviors differ, explain the resulting behavior\nchange and recommend the Anvil standard. Preserve the legacy behavior only when\nthe repository has a current, explicit requirement that Anvil cannot represent.\n\n## 4. Resolve generated-content conflicts\n\nFor every Anvil-owned file or managed region:\n\n1. Determine whether the repository edit encodes real policy or is an obsolete\n   implementation detail.\n2. Prefer the catalog behavior. Move only justified repository policy to the\n   supported configuration surface where possible.\n3. Revert the generated content to the catalog form by running `cargo anvil`.\n4. Take ownership of generated content only when the repository has a durable\n   requirement the catalog cannot represent. Document why it must diverge.\n5. Re-run `cargo anvil --dry-run` until there are no unexplained proposals,\n   refusals, or manifest changes.\n\nDo not hand-edit emitted files when their source template is available.\n\n## 5. Evaluate differences before deleting duplicates\n\nRun the narrow Anvil recipe corresponding to each legacy capability and resolve\nits failures first. Examples:\n\n- `just anvil-fmt`\n- `just anvil-clippy`\n- `just anvil-doc-build`\n- `just anvil-pr-test`\n- `just anvil-pr-msrv`\n- `just anvil-pr-runtime-analysis`\n- `just anvil-pr-fuzzing`\n- `just anvil-pr-mutants`\n\nWhen a check fails, fix the root cause and rerun that specific recipe instead of\nrepeating the entire tier. Install missing prerequisites with the matching\n`*-setup` recipe or `just anvil-setup`.\n\nCompare results with the legacy command where behavior is not obviously\nidentical. Treat disagreements as migration decisions, not automatic Anvil\ndefects: describe the impact and adopt Anvil's behavior unless the legacy\nbehavior serves a current requirement outside the catalog. Account for impact\nscoping by using `ANVIL_IMPACT=off` when a deliberate full-workspace comparison\nis required.\n\n## 6. Remove duplicate infrastructure\n\nAfter equivalence is established:\n\n- delete legacy workflows, scheduled jobs, setup actions, recipes, and scripts\n  whose complete behavior is now owned by Anvil;\n- remove duplicate tool-version files and updaters when\n  `justfiles\u002Fanvil\u002Fversions.just` is the authoritative list;\n- update badges, contributor documentation, and agent instructions to name the\n  Anvil workflows and recipes;\n- retain scripts and pipelines only for requirements outside Anvil's scope, and\n  document the unmet requirement and why the catalog behavior is insufficient;\n- identify required status contexts or external rulesets that must change\n  before the cleanup can merge.\n\nDo not change hosted branch protection or organization policy without the\nrequired authorization. Report the exact old and new contexts for the\nmaintainer when an atomic external update is necessary.\n\n## 7. Final verification\n\n1. Run `cargo anvil` and then `cargo anvil --dry-run`; the second run must be\n   clean.\n2. Run `just anvil-pr-fast`.\n3. Run `just anvil-pr` for the complete local PR tier. If that is impractical,\n   and a generated CI backend will validate the current change, ask whether to\n   stop after the fast tier and rely on PR checks for the remaining groups. A\n   local-only installation must run the remaining groups locally. Never\n   describe partial validation as complete.\n4. Confirm generated README files and documentation are current.\n5. Search again for deleted workflow names, stale badges, old recipe names,\n   duplicate version lists, and orphaned scripts.\n6. Review the final diff for unrelated changes and accidental policy loss.\n\nFinish with:\n\n- what Anvil now owns;\n- what legacy infrastructure was removed;\n- what repository-specific infrastructure remains, which requirement it serves,\n  and why the Anvil behavior is insufficient;\n- any intentional behavioral differences;\n- any branch-policy or ruleset action required before merge;\n- the exact validation completed and anything left to cloud CI.\n",{"name":5,"license":15,"description":7},"main","38d7f16604d963212002ce0002cfd75481d5e405",".github\u002Fskills\u002Fcargo-anvil-adoption",8,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fox-tools","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-13 22:20:30",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add microsoft\u002Fox-tools --skill cargo-anvil-adoption",{"tool":60,"command":61},"bunx","bunx skills add microsoft\u002Fox-tools --skill cargo-anvil-adoption",{"tool":63,"command":64},"pnpm","pnpm dlx skills add microsoft\u002Fox-tools --skill cargo-anvil-adoption","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fox-tools\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcargo-anvil-adoption\u002FSKILL.md",true,[],[69,74],{"skillNo":70,"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":71,"categories":72,"keywords":73,"publishedAt":40},"01M69BSJ2S21MWSNEQZ92Z98X0","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fox-tools\u002Fblob\u002Fmain\u002Fcrates\u002Fcargo-anvil\u002Ftemplates\u002Fskills\u002Fcargo-anvil-adoption\u002FSKILL.md",[],[19,20,22,21,23,24,38,37,36,35,34,33,26,31,30,25,29,28,27,39,32],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":90,"publishedAt":40},"01M69BSG8TWR4WME57PYGJ3G0Y","code-review","Review guidance for pull requests in this repository. Use when reviewing a pull request, to keep comments on evidence you can see rather than on predicted build outcomes, remembered API signatures, or assumed conventions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fox-tools\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcode-review\u002FSKILL.md",[80,85],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[91,92,93,94,95,96,97,98,23,99,100,101,102,103,104,105,106,107,108,24],"review","code","code review","keep","pull requests","pull request","pull","api","outcomes","evidence","build","signatures","comments","you","requests","can","for","request"]