[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69AHKC55VQHAQBHZYVHSEN3":3,"skill-same:01M69AHKC55VQHAQBHZYVHSEN3":98},{"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":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M69AHKC55VQHAQBHZYVHSEN3","writing-plans",null,"Use when design is complete and you need detailed implementation tasks for engineers with zero codebase context - creates comprehensive implementation plans with exact file paths, complete code examples, and verification steps assuming engineer has minimal domain knowledge","microsoft\u002FFluidFramework","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69AG0BQKNGBJQ5YNG09HXXW",4948,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.agency\u002Fplugins\u002Fnori\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"writing","writing plans","plans","when","design","for","you","with","complete","domain","design is","minimal","engineer","use","knowledge","ZeRO","examples","file","code","tasks","2026-11-10 10:12:30",false,"---\nname: writing-plans\ndescription: Use when design is complete and you need detailed implementation tasks for engineers with zero codebase context - creates comprehensive implementation plans with exact file paths, complete code examples, and verification steps assuming engineer has minimal domain knowledge\n---\n\n\u003Crequired>\nCRITICAL. Add the following steps to your Todo list using TodoWrite:\n\n- Read the 'Guidelines'.\n- Create a comprehensive plan that a senior engineer can follow.\n\u003Csystem-reminder>Any absolute paths in your plan MUST take into account any worktrees that may have been created\u003C\u002Fsystem-reminder>\n- Think about backwards compability. Add any notes to the plan.\n- Think about edge cases. Add them to the plan.\n- Think about questions or areas that require clarity. Add them to the plan.\n- Emphasize how you will test your plan.\n- Present plan to user.\n\u003C\u002Frequired>\n\n# Guidelines\n\n## Overview\n\nCreate a comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD.\n\nAssume they are a talented developer. However, assume that they know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.\n\nDo not add code, but include enough detail that the necessary code is obvious.\n\nDo not write a file to disk unless explicitly asked.\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n# [Feature Name] Implementation Plan\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies\u002Flibraries]\n\n---\n```\n\n## Test Section\n\nEvery plan MUST have a test section. This should be written first, and should\ndocument how you plan to test the *behavior*.\n\n```markdown\n\n**Testing Plan**\n\nI will add an integration test that ensures foo behaves like blah. The\nintegration test will mock A\u002FB\u002FC. The test will then call function\u002Fcli\u002Fetc.\n\nI will add a unit test that ensures baz behaves like qux...\n```\n\nYou should end EVERY testing plan section by writing:\n\n```markdown\nNOTE: I will write *all* tests before I add any implementation behavior.\n```\n\n\u003Csystem-reminder>Your tests should NOT contain tests for datastructures or\ntypes. Your tests should NOT simply test mocks. Always test actual behavior.\u003C\u002Fsystem-reminder>\n\n\u003Crequired>\nFor each test, follow this checklist:\n- Ensure that the test does not just test mocks. If it does, remove the test and try again.\n- Ensure the test does not test implementation detail. If it does, rewrite the test so that it tests boundary behavior.\n- Ensure the test does not test data structure format or types. If it does, remove the test and try again.\n- Ensure the test does not test for removed behavior. For example, if some behavior has been deprecated, do not write a test that simply confirms the behavior no longer works.\n- Evaluate if the test treats the interior of the test boundary as a blackbox. You should not know anything about interior variables, function calls, or control flow.\n\u003C\u002Frequired>\n\n## Plan Document Footer\n\n**Every plan MUST end with this footer:**\n\n```markdown\n**Testing Details** [Brief description of what tests are being added and how they specifically test BEHAVIOR and NOT just implementation]\n\n**Implementation Details** [maximum 10 bullets about key details]\n\n**Question** [any questions or concerns that may be relevant that need answers]\n\n---\n```\n","\u003Crequired>\nCRITICAL. Add the following steps to your Todo list using TodoWrite:\n\n- Read the 'Guidelines'.\n- Create a comprehensive plan that a senior engineer can follow.\n\u003Csystem-reminder>Any absolute paths in your plan MUST take into account any worktrees that may have been created\u003C\u002Fsystem-reminder>\n- Think about backwards compability. Add any notes to the plan.\n- Think about edge cases. Add them to the plan.\n- Think about questions or areas that require clarity. Add them to the plan.\n- Emphasize how you will test your plan.\n- Present plan to user.\n\u003C\u002Frequired>\n\n# Guidelines\n\n## Overview\n\nCreate a comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD.\n\nAssume they are a talented developer. However, assume that they know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.\n\nDo not add code, but include enough detail that the necessary code is obvious.\n\nDo not write a file to disk unless explicitly asked.\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n# [Feature Name] Implementation Plan\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies\u002Flibraries]\n\n---\n```\n\n## Test Section\n\nEvery plan MUST have a test section. This should be written first, and should\ndocument how you plan to test the *behavior*.\n\n```markdown\n\n**Testing Plan**\n\nI will add an integration test that ensures foo behaves like blah. The\nintegration test will mock A\u002FB\u002FC. The test will then call function\u002Fcli\u002Fetc.\n\nI will add a unit test that ensures baz behaves like qux...\n```\n\nYou should end EVERY testing plan section by writing:\n\n```markdown\nNOTE: I will write *all* tests before I add any implementation behavior.\n```\n\n\u003Csystem-reminder>Your tests should NOT contain tests for datastructures or\ntypes. Your tests should NOT simply test mocks. Always test actual behavior.\u003C\u002Fsystem-reminder>\n\n\u003Crequired>\nFor each test, follow this checklist:\n- Ensure that the test does not just test mocks. If it does, remove the test and try again.\n- Ensure the test does not test implementation detail. If it does, rewrite the test so that it tests boundary behavior.\n- Ensure the test does not test data structure format or types. If it does, remove the test and try again.\n- Ensure the test does not test for removed behavior. For example, if some behavior has been deprecated, do not write a test that simply confirms the behavior no longer works.\n- Evaluate if the test treats the interior of the test boundary as a blackbox. You should not know anything about interior variables, function calls, or control flow.\n\u003C\u002Frequired>\n\n## Plan Document Footer\n\n**Every plan MUST end with this footer:**\n\n```markdown\n**Testing Details** [Brief description of what tests are being added and how they specifically test BEHAVIOR and NOT just implementation]\n\n**Implementation Details** [maximum 10 bullets about key details]\n\n**Question** [any questions or concerns that may be relevant that need answers]\n\n---\n```\n",{"name":5,"description":7},"main","5e94cbfa27965a98428f7d26b69dd5b0a8abeb0d",".agency\u002Fplugins\u002Fnori\u002Fskills\u002Fwriting-plans",590,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework","https:\u002F\u002Ffluidframework.com","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 02:16:36",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add microsoft\u002FFluidFramework --skill writing-plans",{"tool":70,"command":71},"bunx","bunx skills add microsoft\u002FFluidFramework --skill writing-plans",{"tool":73,"command":74},"pnpm","pnpm dlx skills add microsoft\u002FFluidFramework --skill writing-plans","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.agency\u002Fplugins\u002Fnori\u002Fskills\u002Fwriting-plans\u002FSKILL.md",true,[78,84,88,94],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"assets\u002Ffan-out-pool.md","ASSET","资产文件",1345,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fapm\u002Fblob\u002Fmain\u002Fpackages\u002Fautopilot\u002Fautopilot-issue-triage-scheduler\u002F.apm\u002Fskills\u002Fautopilot-issue-triage-scheduler\u002Fassets\u002Ffan-out-pool.md",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"assets\u002Flabel-contract.json",4653,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fapm\u002Fblob\u002Fmain\u002Fpackages\u002Fautopilot\u002Fautopilot-issue-triage-scheduler\u002F.apm\u002Fskills\u002Fautopilot-issue-triage-scheduler\u002Fassets\u002Flabel-contract.json",{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"scripts\u002Ffetch_queue.py","SCRIPT","脚本",22451,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fapm\u002Fblob\u002Fmain\u002Fpackages\u002Fautopilot\u002Fautopilot-issue-triage-scheduler\u002F.apm\u002Fskills\u002Fautopilot-issue-triage-scheduler\u002Fscripts\u002Ffetch_queue.py",{"path":95,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":96,"sourceHtmlUrl":97},"scripts\u002Ftriage_state.py",4648,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fapm\u002Fblob\u002Fmain\u002Fpackages\u002Fautopilot\u002Fautopilot-issue-triage-scheduler\u002F.apm\u002Fskills\u002Fautopilot-issue-triage-scheduler\u002Fscripts\u002Ftriage_state.py",[99,119,152,175,193,216],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":49},"01M6PJ5SAHYFZFWDG5Y4RW56EP","trigger-pipelines-for-copilot-pr","Trigger ADO pipelines for a Copilot-created PR by posting \u002Fazp run comments. Use when the user asks to trigger CI pipelines for a specific PR.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftrigger-pipelines-for-copilot-pr\u002FSKILL.md",[],[106,107,34,108,109,110,111,112,113,114,42,115,116,117,118,32],"pr","trigger pipelines for copilot pr","trigger","copilot","pipelines","ado","posting","run","ci","number","URL","comments","user",{"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":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":134,"publishedAt":49},"01M6PJ5M4ZG7E78C4GM4041HEP","review","Review changes relative to a prior state, such as a diff, pull request, branch, commit, or working-tree changes. Use for change-focused code review and regression analysis. Do not use to assess an existing file, API, design, implementation, or other artifact without a comparison; if the request is ambiguous, ask whether the user wants a change review and what prior state to compare against.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freview\u002FSKILL.md",[125,128,131],{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":129,"categoryName":130,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":132,"categoryName":133,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",[121,135,136,137,33,138,139,47,140,141,142,143,144,145,146,147,148,149,34,150,151],"branch","regression","code review","ask","analysis","commit","api","change","artifact","request","pull","tree","as","do","diff","assess","ambiguous",{"skillNo":153,"name":154,"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":161,"publishedAt":49},"01M6PJ5E3PCBDS319FFMHPFACN","review-pr-local","The authority on pulling a pull request — Azure DevOps or GitHub — into an isolated local worktree so a human can review it in their editor, and on posting human-controlled review comments back to the PR (ADO via the ado PR-thread MCP tools or the Azure DevOps REST API, GitHub via the gh CLI). Auto-detects the platform and all identifiers from the PR URL; not tied to any specific repository. The AI assists an interactive human review and only ever posts comments the human explicitly requests. If you find yourself checking out a PR branch over the user's own working tree, or posting AI-authored review prose the human did not ask for, invoke this skill instead.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freview-pr-local\u002FSKILL.md",[158],{"categoryNo":159,"categoryName":160,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[162,121,106,163,164,165,135,166,167,168,169,170,171,172,116,35,138,141,173,174],"local","review pr local","review pr","back","posts","only","MCP","authority","auto","invoke","azure devops","cli","worktree",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":49},"01M6PJ5AVZAS0AEBPCYJZ9ZMMD","policy-check","This skill should be used when the user asks to \"run policy check\", \"check policy\", \"policy-check\", or needs to validate package compliance. Provides guidance on running policy checks for specific packages or the entire repository.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpolicy-check\u002FSKILL.md",[],[182,183,184,185,186,34,113,187,188,189,190,118,191,32,192],"policy check","policy","check","packages","compliance","repository","guidance","validate","package","running","entire",{"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":202,"publishedAt":49},"01M6PJ54H068MZF2WD2JDKCVDC","pipeline-test-triage","Triage test failures in an Azure DevOps pipeline run for Fluid Framework. Use when the user shares an ADO build\u002Fpipeline URL or build ID and wants failures analyzed, when they ask \"why did this pipeline fail\", \"summarize the test failures\", \"is this test flaky or a real bug\", \"compare these runs\", or wants bugs filed for genuine failures. Covers the Real Service End to End Tests pipeline as the worked example but applies to any FF test pipeline.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpipeline-test-triage\u002FSKILL.md",[199],{"categoryNo":200,"categoryName":201,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[203,204,205,206,207,208,209,210,172,116,138,113,211,212,213,214,111,147,215,34,32],"pipeline","test triage","pipeline test triage","pipeline test","test","triage","end","test pipeline","why","bug","but","framework","bugs",{"skillNo":217,"name":218,"nameZh":6,"description":219,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":220,"categories":221,"keywords":222,"publishedAt":49},"01M6PJ4ZJASDV2CGQTG1JWKBFE","fluid-release","Fluid Framework client release group — minor releases, patch releases, and post-release type test updates. Covers release prep, branching, version bumps, changelogs, release notes, and type test baselines. In autonomous mode, auto-detects state from the repo, attempts to execute, and falls back to a GitHub issue on failure. Triggers on \"release\", \"do the release\", \"release status\", version bump, release notes, changelog, release branch, or release engineering.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffluid-release\u002FSKILL.md",[],[223,224,225,165,135,226,227,228,229,230,170,231,232,233,234,235,236,237,238,239],"release","fluid release","fluid","bump","mode","autonomous","release notes","release status","updates","patch","notes","changelog","release prep","releases","status","issue","branching"]