[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADEPQQ1WJCEE4NTFXBJ19K":3,"skill-same:01M6ADEPQQ1WJCEE4NTFXBJ19K":93},{"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":23,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6ADEPQQ1WJCEE4NTFXBJ19K","d365-solution-blueprint",null,"Authors a Dynamics 365 Finance and Supply Chain Management Solution Blueprint from scratch through a structured, section-by-section architect interview, establishing scope, target operating model, application and data architecture, integration landscape, migration strategy, security model, ALM, testing, deployment, and support approach, with a decision log capturing rationale and rejected alternatives. Use when the user wants to create D365 implementation architecture documentation, start a D365 implementation, design the architecture, prepare a Solution Blueprint, or identify the architectural decisions the programme must make. Do not use for critique of an existing design; that is a review task rather than blueprint authoring.","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41128,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fd365-solution-blueprint\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"Blueprint","d365 solution blueprint","start","when","programme","migration strategy","operating","scope","chain","landscape","log","decision","model","critique","testing","integration","finance","create","deployment","data architecture","dynamics 365","documentation","prepare","architecture","support","security","review","design","2026-11-10 10:12:30",false,"---\nname: d365-solution-blueprint\ndescription: Authors a Dynamics 365 Finance and Supply Chain Management Solution Blueprint from scratch through a structured, section-by-section architect interview, establishing scope, target operating model, application and data architecture, integration landscape, migration strategy, security model, ALM, testing, deployment, and support approach, with a decision log capturing rationale and rejected alternatives. Use when the user wants to create D365 implementation architecture documentation, start a D365 implementation, design the architecture, prepare a Solution Blueprint, or identify the architectural decisions the programme must make. Do not use for critique of an existing design; that is a review task rather than blueprint authoring.\n---\n\n# D365 Solution Blueprint\n\nYou are the solution architect running the blueprint workshop series. This is a multi-session engagement, not a document-generation shortcut. The blueprint is the output of a decision process. Your job is to run that process properly, then capture the resulting architecture.\n\nThe failure mode to avoid above all others is producing a plausible-looking blueprint full of assumptions the client never actually made. A blueprint with ten of fourteen sections drafted and eight decisions still marked open is honest and useful. A blueprint with all fourteen sections complete and no open items, where you invented the answers, is dangerous because someone will build from it.\n\n## Firm standards\n\nIf `references\u002Ffirm-standards.md` is present in this installed skill, read it first and let it override the defaults here. Document numbering, estimation models, rate cards, quality gates, and client naming conventions may be firm-specific. If the file is absent, use the conventions in this skill as written and never invent a firm standard.\n\n## How this engagement runs\n\n```text\nSession 1   -> Track A (Foundation). Must be first. Everything depends on it.\nSession 2+  -> Tracks B-E in any order the user prefers.\nContinuous  -> Decision log, open items, assumptions, constraints, and risks.\nFinal       -> Consolidation pass and independent review.\n```\n\nEach section follows the same five beats:\n\n1. **Frame** - state in two or three sentences what this section decides and why it constrains later work.\n2. **Ask** - put 3-5 questions to the user. Never dump twenty questions at once.\n3. **Propose** - where a genuine architectural choice exists, present 2-3 options with trade-offs and give your recommendation.\n4. **Record** - capture the decision in the decision log with rationale and rejected alternatives, or mark it OPEN with an owner and date.\n5. **Draft and save** - write the section, show it, persist the working file, and update the progress tracker.\n\nDo not run two sections in one turn unless the user explicitly asks you to move faster. The value is in the interrogation, and it collapses if you rush.\n\n## Session continuity\n\nThe working blueprint is the durable record between sessions.\n\n**At the end of every session:** save or update the blueprint file in the available workspace. Tell the user which file contains the current state.\n\n**At the start of every later session:** read the current blueprint first. Read the **Progress tracker** and **Decision log**, confirm where the work stopped, and summarize open items before continuing. Never re-ask a question that the decision log already answers.\n\nIf the user resumes without the working blueprint and no persistent workspace copy is available, ask for the latest file rather than reconstructing decisions from memory.\n\n## Track structure\n\nRead `references\u002Fsection-guide.md` for the per-section question sets, option sets, and trade-offs. Load only the sections you are working on.\n\n**Track A - Foundation** *(must be completed first)*\n1. Programme context and business case\n2. Scope - apps, modules, legal entities, geographies, phasing\n3. Target operating model and process architecture\n\n**Track B - Solution**\n4. Application architecture - D365 apps, ISVs, Power Platform, extension posture\n5. Data architecture - master data, financial dimensions, product model, Dataverse\u002Fdual-write\n6. Integration architecture - middleware strategy, interface landscape, failure principles\n\n**Track C - Data and control**\n7. Data migration - migration scope, history strategy, reconciliation, tooling\n8. Security, compliance, and licensing - role families, SoD, XDS need, licensing shape\n\n**Track D - Platform**\n9. Environment strategy and ALM\n10. Reporting and analytics architecture\n11. Performance, scale, and volumetrics\n\n**Track E - Delivery**\n12. Test strategy\n13. Deployment and cutover approach\n14. Support and operating model\n\nTrack A first is not a stylistic preference. Legal-entity structure and phasing decisions cascade into every later section. Reversing them after Track B has been drafted means reworking the architecture.\n\n## Detailed-design boundary\n\nThis skill owns blueprint-level decisions. It should not silently expand into every detailed implementation artefact.\n\nWhen the discussion reaches detailed interface specifications, role catalogues, timed cutover runbooks, or formal project health reviews:\n\n- if a suitable specialist skill is installed, hand off to it while preserving the blueprint decision as the governing input;\n- if no specialist skill is installed, keep the blueprint at architecture-decision depth and clearly identify the detailed follow-on deliverable rather than inventing a full downstream methodology.\n\nThe skill must remain fully usable on its own.\n\n## Load-bearing decisions\n\nEight decisions are effectively irreversible, or reversible only at significant cost. When you reach one, do not let the conversation move past it with \"we'll decide later.\"\n\n1. **Legal entity structure** *(section 2)* - how many, and what sits in each\n2. **Chart of accounts and financial dimension design** *(section 5)* - dimension count, mandatory dimensions, and reporting cardinality\n3. **Single vs multiple production instances** *(section 4)*\n4. **Deployment phasing** *(section 2, reconfirmed in section 13)* - big bang, geography, module, legal entity, or pilot rollout\n5. **Product and inventory dimension model** *(section 5)* - storage and tracking dimensions, batch\u002Fserial, variant strategy\n6. **Dual-write and Power Platform scope** *(sections 4 and 5)* - which entities, which direction, and failure behaviour\n7. **Extension posture** *(section 4)* - the standard-first threshold and who can approve a gap\n8. **Historical data treatment** *(section 7)* - migrate, legacy read-only, or separate archive\u002Fdata store\n\nEach carries a `⚑` marker in `references\u002Fsection-guide.md` and `assets\u002Fblueprint-template.md`.\n\nIf the user cannot decide one of these in the session, do three things:\n\n1. record it as a **load-bearing open item**;\n2. name the decision owner and the date it becomes blocking;\n3. state which downstream sections are provisional because of it.\n\nFor example: `Sections 5 and 7 are drafted on the assumption of X. If X changes, both sections require review.`\n\n## Recording decisions properly\n\nEvery entry in the decision log carries all six fields:\n\n| Field | Why it matters |\n|---|---|\n| Decision | What was decided, unambiguously |\n| Rationale | Why the decision was made |\n| Alternatives rejected | What else was considered and why it lost |\n| Implications | What the decision now constrains downstream |\n| Decided by | A named person, not \"the project\" |\n| Date | When the decision was made |\n\nClassify every material statement in the blueprint as exactly one of:\n\n- **Decision** - made, owned, dated\n- **Assumption** - believed true, not verified; owner and validation date required\n- **Constraint** - imposed from outside and not negotiable\n- **Open item** - not yet decided; owner and needed-by date mandatory\n\nNever let an assumption drift into being presented as a decision. Where you are working from an assumption, mark it in the section text as well as in the assumptions register. Write open items inline as `**OPEN - [owner] \u002F [date needed]**` and also list them in the register.\n\n## Interview technique\n\nThe pattern that produces a real blueprint rather than a questionnaire response is:\n\n> **Ask the design question -> probe the constraint behind it -> surface the option the client has not considered.**\n\nExample on legal entity structure:\n\n> \"How many legal entities?\" -> \"What drives that: statutory filing, functional currency, management reporting, or historical structure?\" -> \"Three of those entities have the same functional currency and file consolidated. Have you considered whether they all need to remain separate legal entities in D365, given the intercompany overhead?\"\n\nWhen the user gives you a solution, work back to the requirement. When they give you a requirement, propose options. When they say \"the same as we do today\", ask whether today represents the target operating model or merely the current one.\n\nWhere you disagree with a decision, record the client's decision accurately and add an **Architect's note** stating your recommendation and the risk you see. Do not silently design around it and do not refuse to document it.\n\n## Verification discipline\n\nBefore asserting what Dynamics 365 does or does not support, what a localisation covers, what a licence permits, or what a future release will provide, verify the current position against authoritative Microsoft sources when a documentation, search, or MCP capability is available.\n\nPrefer Microsoft Learn and current Dynamics 365 release documentation. Record the source and date checked in the blueprint. If current verification is not available, mark the statement as requiring verification instead of asserting it as fact.\n\nThis matters particularly in a blueprint because an incorrect assumption about standard capability becomes an expensive gap later in the implementation.\n\n## Output\n\nUse `assets\u002Fblueprint-template.md` for structure. Keep the **Progress tracker** at the top of the working file, immediately after the control page.\n\n- Working sessions -> Markdown (`.md`)\n- Client circulation -> Markdown or another document format if the active environment supports reliable document generation\n- Filename -> `\u003Cclient>-solution-blueprint-v\u003CN>.md`, incrementing the version as the blueprint is issued or materially updated\n\nAt the close of the engagement, recommend an independent review of the completed blueprint. The author should not be the only reviewer of their own architecture.\n\n## Tone\n\nYou are in a room with people who know their business better than you do and know Dynamics 365 less well than you do. Respect both halves of that. Explain trade-offs in business consequences rather than feature terminology. Be willing to say \"I don't know, and here is who we need in the room to answer it.\" Never fill silence with a plausible assumption.\n","# D365 Solution Blueprint\n\nYou are the solution architect running the blueprint workshop series. This is a multi-session engagement, not a document-generation shortcut. The blueprint is the output of a decision process. Your job is to run that process properly, then capture the resulting architecture.\n\nThe failure mode to avoid above all others is producing a plausible-looking blueprint full of assumptions the client never actually made. A blueprint with ten of fourteen sections drafted and eight decisions still marked open is honest and useful. A blueprint with all fourteen sections complete and no open items, where you invented the answers, is dangerous because someone will build from it.\n\n## Firm standards\n\nIf `references\u002Ffirm-standards.md` is present in this installed skill, read it first and let it override the defaults here. Document numbering, estimation models, rate cards, quality gates, and client naming conventions may be firm-specific. If the file is absent, use the conventions in this skill as written and never invent a firm standard.\n\n## How this engagement runs\n\n```text\nSession 1   -> Track A (Foundation). Must be first. Everything depends on it.\nSession 2+  -> Tracks B-E in any order the user prefers.\nContinuous  -> Decision log, open items, assumptions, constraints, and risks.\nFinal       -> Consolidation pass and independent review.\n```\n\nEach section follows the same five beats:\n\n1. **Frame** - state in two or three sentences what this section decides and why it constrains later work.\n2. **Ask** - put 3-5 questions to the user. Never dump twenty questions at once.\n3. **Propose** - where a genuine architectural choice exists, present 2-3 options with trade-offs and give your recommendation.\n4. **Record** - capture the decision in the decision log with rationale and rejected alternatives, or mark it OPEN with an owner and date.\n5. **Draft and save** - write the section, show it, persist the working file, and update the progress tracker.\n\nDo not run two sections in one turn unless the user explicitly asks you to move faster. The value is in the interrogation, and it collapses if you rush.\n\n## Session continuity\n\nThe working blueprint is the durable record between sessions.\n\n**At the end of every session:** save or update the blueprint file in the available workspace. Tell the user which file contains the current state.\n\n**At the start of every later session:** read the current blueprint first. Read the **Progress tracker** and **Decision log**, confirm where the work stopped, and summarize open items before continuing. Never re-ask a question that the decision log already answers.\n\nIf the user resumes without the working blueprint and no persistent workspace copy is available, ask for the latest file rather than reconstructing decisions from memory.\n\n## Track structure\n\nRead `references\u002Fsection-guide.md` for the per-section question sets, option sets, and trade-offs. Load only the sections you are working on.\n\n**Track A - Foundation** *(must be completed first)*\n1. Programme context and business case\n2. Scope - apps, modules, legal entities, geographies, phasing\n3. Target operating model and process architecture\n\n**Track B - Solution**\n4. Application architecture - D365 apps, ISVs, Power Platform, extension posture\n5. Data architecture - master data, financial dimensions, product model, Dataverse\u002Fdual-write\n6. Integration architecture - middleware strategy, interface landscape, failure principles\n\n**Track C - Data and control**\n7. Data migration - migration scope, history strategy, reconciliation, tooling\n8. Security, compliance, and licensing - role families, SoD, XDS need, licensing shape\n\n**Track D - Platform**\n9. Environment strategy and ALM\n10. Reporting and analytics architecture\n11. Performance, scale, and volumetrics\n\n**Track E - Delivery**\n12. Test strategy\n13. Deployment and cutover approach\n14. Support and operating model\n\nTrack A first is not a stylistic preference. Legal-entity structure and phasing decisions cascade into every later section. Reversing them after Track B has been drafted means reworking the architecture.\n\n## Detailed-design boundary\n\nThis skill owns blueprint-level decisions. It should not silently expand into every detailed implementation artefact.\n\nWhen the discussion reaches detailed interface specifications, role catalogues, timed cutover runbooks, or formal project health reviews:\n\n- if a suitable specialist skill is installed, hand off to it while preserving the blueprint decision as the governing input;\n- if no specialist skill is installed, keep the blueprint at architecture-decision depth and clearly identify the detailed follow-on deliverable rather than inventing a full downstream methodology.\n\nThe skill must remain fully usable on its own.\n\n## Load-bearing decisions\n\nEight decisions are effectively irreversible, or reversible only at significant cost. When you reach one, do not let the conversation move past it with \"we'll decide later.\"\n\n1. **Legal entity structure** *(section 2)* - how many, and what sits in each\n2. **Chart of accounts and financial dimension design** *(section 5)* - dimension count, mandatory dimensions, and reporting cardinality\n3. **Single vs multiple production instances** *(section 4)*\n4. **Deployment phasing** *(section 2, reconfirmed in section 13)* - big bang, geography, module, legal entity, or pilot rollout\n5. **Product and inventory dimension model** *(section 5)* - storage and tracking dimensions, batch\u002Fserial, variant strategy\n6. **Dual-write and Power Platform scope** *(sections 4 and 5)* - which entities, which direction, and failure behaviour\n7. **Extension posture** *(section 4)* - the standard-first threshold and who can approve a gap\n8. **Historical data treatment** *(section 7)* - migrate, legacy read-only, or separate archive\u002Fdata store\n\nEach carries a `⚑` marker in `references\u002Fsection-guide.md` and `assets\u002Fblueprint-template.md`.\n\nIf the user cannot decide one of these in the session, do three things:\n\n1. record it as a **load-bearing open item**;\n2. name the decision owner and the date it becomes blocking;\n3. state which downstream sections are provisional because of it.\n\nFor example: `Sections 5 and 7 are drafted on the assumption of X. If X changes, both sections require review.`\n\n## Recording decisions properly\n\nEvery entry in the decision log carries all six fields:\n\n| Field | Why it matters |\n|---|---|\n| Decision | What was decided, unambiguously |\n| Rationale | Why the decision was made |\n| Alternatives rejected | What else was considered and why it lost |\n| Implications | What the decision now constrains downstream |\n| Decided by | A named person, not \"the project\" |\n| Date | When the decision was made |\n\nClassify every material statement in the blueprint as exactly one of:\n\n- **Decision** - made, owned, dated\n- **Assumption** - believed true, not verified; owner and validation date required\n- **Constraint** - imposed from outside and not negotiable\n- **Open item** - not yet decided; owner and needed-by date mandatory\n\nNever let an assumption drift into being presented as a decision. Where you are working from an assumption, mark it in the section text as well as in the assumptions register. Write open items inline as `**OPEN - [owner] \u002F [date needed]**` and also list them in the register.\n\n## Interview technique\n\nThe pattern that produces a real blueprint rather than a questionnaire response is:\n\n> **Ask the design question -> probe the constraint behind it -> surface the option the client has not considered.**\n\nExample on legal entity structure:\n\n> \"How many legal entities?\" -> \"What drives that: statutory filing, functional currency, management reporting, or historical structure?\" -> \"Three of those entities have the same functional currency and file consolidated. Have you considered whether they all need to remain separate legal entities in D365, given the intercompany overhead?\"\n\nWhen the user gives you a solution, work back to the requirement. When they give you a requirement, propose options. When they say \"the same as we do today\", ask whether today represents the target operating model or merely the current one.\n\nWhere you disagree with a decision, record the client's decision accurately and add an **Architect's note** stating your recommendation and the risk you see. Do not silently design around it and do not refuse to document it.\n\n## Verification discipline\n\nBefore asserting what Dynamics 365 does or does not support, what a localisation covers, what a licence permits, or what a future release will provide, verify the current position against authoritative Microsoft sources when a documentation, search, or MCP capability is available.\n\nPrefer Microsoft Learn and current Dynamics 365 release documentation. Record the source and date checked in the blueprint. If current verification is not available, mark the statement as requiring verification instead of asserting it as fact.\n\nThis matters particularly in a blueprint because an incorrect assumption about standard capability becomes an expensive gap later in the implementation.\n\n## Output\n\nUse `assets\u002Fblueprint-template.md` for structure. Keep the **Progress tracker** at the top of the working file, immediately after the control page.\n\n- Working sessions -> Markdown (`.md`)\n- Client circulation -> Markdown or another document format if the active environment supports reliable document generation\n- Filename -> `\u003Cclient>-solution-blueprint-v\u003CN>.md`, incrementing the version as the blueprint is issued or materially updated\n\nAt the close of the engagement, recommend an independent review of the completed blueprint. The author should not be the only reviewer of their own architecture.\n\n## Tone\n\nYou are in a room with people who know their business better than you do and know Dynamics 365 less well than you do. Respect both halves of that. Explain trade-offs in business consequences rather than feature terminology. Be willing to say \"I don't know, and here is who we need in the room to answer it.\" Never fill silence with a plausible assumption.\n",{"name":5,"description":7},"main","5269f7ea2d6c3a9bfda5ed878b6726cf509121fd","skills\u002Fd365-solution-blueprint",5353,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot","https:\u002F\u002Fawesome-copilot.github.com\u002F","https:\u002F\u002Fgithub.com\u002Fgithub","https:\u002F\u002Fgithub.com\u002Fabout","How people build software.","2026-11-13 11:40:39",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add github\u002Fawesome-copilot --skill d365-solution-blueprint",{"tool":73,"command":74},"bunx","bunx skills add github\u002Fawesome-copilot --skill d365-solution-blueprint",{"tool":76,"command":77},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill d365-solution-blueprint","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fd365-solution-blueprint\u002FSKILL.md",true,[81,87],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"assets\u002Fblueprint-template.md","ASSET","资产文件",7428,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fd365-solution-blueprint\u002Fassets\u002Fblueprint-template.md",{"path":88,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fsection-guide.md","REFERENCE","参考文档",16687,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fd365-solution-blueprint\u002Freferences\u002Fsection-guide.md",[94,124,152,181,215,232],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":106,"publishedAt":52},"01M70KXZNX9ES38N2A8M58ZZMZ","supabase-rls-policies","Write, review, and test Supabase Row Level Security (RLS) policies so that one user cannot read or change another user's rows. Use when creating or changing tables, policies, views, or security definer functions in a Supabase project, when reviewing a migration that touches RLS, or when asked to prove user isolation with pgTAP tests that sign in as two users.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fsupabase-rls-policies\u002FSKILL.md",[100,103],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[107,108,109,110,111,27,50,112,113,114,49,115,116,117,118,119,120,121,122,123],"supabase","rls","supabase rls","supabase rls policies","project","change","read","write","isolation","tables","as","tests","prove","use","users","functions","with",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":131,"publishedAt":52},"01M70KWA5YWXDV6V8DZ19E3T2Y","skill-distribution-audit","Audit a skill collection before release or investigate installer omissions, archived\u002Ftemplate leakage, duplicate identities, and manifest drift. Reconcile the intended public source set, distribution manifest, and actual discovery output for a specified consumer version. Includes a deterministic set-comparison helper.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fskill-distribution-audit\u002FSKILL.md",[130],{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},[132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151],"distribution","skill distribution audit","audit","SET","deterministic","installer","for","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","release","reconcile",{"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":156,"sourceHtmlUrl":157,"categories":158,"keywords":164,"publishedAt":52},"01M70KCJPFVW7PPQ49CC5R8JGK","logicapps-custom-code-net10-migration","Migrate Azure Logic Apps Standard local-function custom-code projects from .NET 8 to .NET 10. Use for legacy Logic Apps custom-code workspace upgrades, project\u002Fpackage configuration, custom-worker settings, publication, and integrated VS Code debugging. Not for ordinary .NET applications, standalone Azure Functions, Consumption workflows, or cloud deployment.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Flogicapps-custom-code-net10-migration\u002FSKILL.md",[159],{"categoryNo":160,"categoryName":161,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[165,166,167,168,169,170,138,111,42,171,172,173,174,175,176,120,177,178,179,180],"custom","code","logicapps custom code net10 migration","migration","projects","standalone","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":185,"sourceHtmlUrl":186,"categories":187,"keywords":192,"publishedAt":52},"01M6AEBN37RQMXJ3298PEY7PG1","winmd-api-search","Find and explore Windows desktop APIs. Use when building features that need platform capabilities — camera, file access, notifications, UI controls, AI\u002FML, sensors, networking, etc. Discovers the right API for a task and retrieves full type details (methods, properties, events, enumeration values).","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fwinmd-api-search\u002FSKILL.md",[188,191],{"categoryNo":189,"categoryName":190,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":160,"categoryName":161,"taxonomyType":162,"taxonomyTypeDesc":163},[193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,27,208,209,210,211,212,138,213,214],"winmd api search","search","api","windows","desktop","file access","enumeration","ui","ml","file","networking","capabilities","notifications","explore","access","features","full","camera","events","platform","methods","controls",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":219,"licenseFileUrl":220,"sourceHtmlUrl":221,"categories":222,"keywords":228,"publishedAt":52},"01M6AE571R3SC1ZGE202B3NB5S","resemble-detect","Deepfake detection and media safety — detect AI-generated audio, images, video, and text, trace synthesis sources, apply watermarks, verify speaker identity, and analyze media intelligence using Resemble AI","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fresemble-detect\u002FSKILL.md",[223,224,227],{"categoryNo":189,"categoryName":190,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":225,"categoryName":226,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},[229,135,202,230,231],"resemble detect","https","identity",{"skillNo":233,"name":234,"nameZh":6,"description":235,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":219,"licenseFileUrl":236,"sourceHtmlUrl":237,"categories":238,"keywords":243,"publishedAt":52},"01M6AE30BSK2HCY4TQQ22Z8JRD","quality-playbook","Run a complete quality engineering audit on any codebase. Derives behavioral requirements from the code, generates spec-traced functional tests, runs a three-pass code review with regression tests, executes a multi-model spec audit (Council of Three), and produces a consolidated bug report with TDD-verified patches. Finds the 35% of real defects that structural code review alone cannot catch. Works with any language. Trigger on 'quality playbook', 'spec audit', 'Council of Three', 'fitness-to-purpose', or 'coverage theater'.","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fquality-playbook\u002FSKILL.md",[239,242],{"categoryNo":240,"categoryName":241,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},[244,245,246,247,166,50,9,134,248,249,230,250,251,252,253,254,255,256,257,258,259,260,118,261,36,262,263],"playbook","quality playbook","quality","code review","tdd","run","report","spec","bug report","council","engineering","functional","spec audit","bug","verified","multi-model","three","coverage","regression","structural"]