[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6M1HV7TN4FWERK7P7DN5Q4A":3,"skill-same:01M6M1HV7TN4FWERK7P7DN5Q4A":82},{"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":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6M1HV7TN4FWERK7P7DN5Q4A","diagnose-ci-gate",null,"Determine whether a failing CI check was caused by the current change, then recommend exactly one action. Use when a required check fails on a pull request, when asked \"is this failure mine?\", when a job passes locally but fails in CI, or before retrying a red build. Covers fetching the real log, reading the first error instead of the tail, classifying bug \u002F flaky \u002F environment \u002F pipeline, comparing against the base branch and recent runs, reproducing with CI versions, and fixing a flaky test rather than re-running it forever.","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41162,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdiagnose-ci-gate\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"diagnose","ci","diagnose ci gate","gate","failing","change","running","when","request","recommend","action","reading","re","error","mine","but","bug","log","use","environment","branch","pipeline","pull","2026-11-10 10:12:30",false,"---\nname: 'diagnose-ci-gate'\ndescription: 'Determine whether a failing CI check was caused by the current change, then recommend exactly one action. Use when a required check fails on a pull request, when asked \"is this failure mine?\", when a job passes locally but fails in CI, or before retrying a red build. Covers fetching the real log, reading the first error instead of the tail, classifying bug \u002F flaky \u002F environment \u002F pipeline, comparing against the base branch and recent runs, reproducing with CI versions, and fixing a flaky test rather than re-running it forever.'\n---\n\n# Diagnose CI Gate\n\nA red check is a claim, not a diagnosis. Before you change code or press\nre-run, establish three things from evidence: what actually failed, which class\nof failure it is, and whether this change caused it.\n\nThis skill is for a failing required check on a pull request or a branch. For\ncutting CI cost in general, use the `github-actions-efficiency` skill. For a\ndomain-specific flaky suite, use the skill for that tool (for example\n`cypress-flake-fixer`) after this triage.\n\n## When to Use This Skill\n\n- A required check fails on a pull request and you need to know if it is yours\n- A job passes locally but fails in CI, or fails on only some runs\n- Someone says \"that failure is unrelated, just re-run it\"\n- A build has been retried several times and keeps failing\n- You are about to edit a workflow file to make a check pass\n\n## Prerequisites\n\n- `gh` CLI authenticated, or the raw logs pasted by the user\n- Read access to the base branch and its recent runs\n- The commands in the failing step, so they can be reproduced\n\nIf logs are truncated, partial, or only a summary, stop and ask for the full\nlog. Do not diagnose from the last few lines of a summarized check.\n\n## Workflow\n\n### 1. Get the failing job, not the check summary\n\n```bash\ngh pr checks \u003Cpr-number>                     # which check, which state\ngh run list --branch \u003Cbranch> --limit 10     # current and recent runs\ngh run view \u003Crun-id> --log-failed            # only the failing steps\ngh run view \u003Crun-id> --job \u003Cjob-id> --log    # one job, full log\n```\n\nRecord the commit SHA under test, the runner image, and the time. A failure on\nan older SHA is a different problem from a failure on the current head.\n\n### 2. Read from the first error\n\nRead the top of the failing step, not the bottom. The first error is usually\nthe cause; everything after it is fallout from that cause or from the runner\ngiving up.\n\nQuote the exact lines, and name the command that produced them. If the log\nshows only a summary line (`Process completed with exit code 1`), find the step\nthat emitted it and read that step's output.\n\n### 3. Classify the failure\n\n| Class | Signal | Confirm by |\n| --- | --- | --- |\n| **Bug** | Same failure every run, deterministic input | Re-running fails identically at the same assertion |\n| **Flaky** | Passes sometimes, timing\u002Fordering\u002Fnetwork\u002Fshared state | At least one green run of the same job on the same SHA, or a local loop that fails intermittently |\n| **Environment** | Tool version, missing secret, runner image, cache, disk or memory | Version in CI differs from local, or the step fails before any project code runs |\n| **Pipeline** | The workflow itself is wrong: bad path filter, wrong working directory, missing dependency install, YAML error, or a check that asserts a target the pull request cannot produce (such as a production URL for a page that is not merged yet) | The command succeeds against the pull request's own build, and the workflow line or its target is demonstrably wrong |\n\nWrite the class and the evidence for it in one sentence each. A failure that\ncannot be classified is not ready for a fix.\n\n### 4. Decide whether this change caused it\n\nCompare with the base branch before claiming anything about ownership:\n\n```bash\ngh run list --branch main --limit 10\ngit merge-base HEAD origin\u002Fmain\n```\n\nIf the same job fails on the base branch, or on recent runs of the base branch,\nit is pre-existing. Say so and link the run.\n\nSome jobs only run on pull requests, so no base-branch run exists. In that case,\nsay that instead of implying you compared, and use the diff to establish what\nthe change added.\n\nTo test the base directly without disturbing the worktree, create a unique\nthrowaway worktree and remove it when done:\n\n```bash\nbase_dir=\"$(mktemp -d)\"\ngit worktree add \"$base_dir\" \"$(git merge-base HEAD origin\u002Fmain)\"\n( cd \"$base_dir\" && \u003Cfailing command> )\ngit worktree remove --force \"$base_dir\"\n```\n\n`mktemp -d` returns a fresh path, so concurrent runs cannot collide. `--force` is\nsafe here because the directory was created for this check and the failing\ncommand may have written build output into it. Never point this at a path that\nholds work, and remove the worktree with `git worktree remove` instead of\ndeleting the directory by hand. If a directory was deleted by hand, run\n`git worktree prune`.\n\nThis example is POSIX shell. On Windows, run it from Git Bash, or use\nPowerShell:\n\n```powershell\n$baseDir = Join-Path $env:TEMP (\"ci-base-\" + [guid]::NewGuid())\ngit worktree add $baseDir (git merge-base HEAD origin\u002Fmain)\nPush-Location $baseDir; \u003Cfailing command>; Pop-Location\ngit worktree remove --force $baseDir\n```\n\nIf it passes on the base and fails on the head, name the commit and the file and\nline that introduced it. If the change is a dependency bump, check the lockfile\ndiff and the tool version, not only the source diff.\n\n### 5. Reproduce with CI's versions\n\nRun the failing command with the versions CI used, from the same working\ndirectory, with the same environment variables and the same install step. Read\nthe versions from the log, not from your local machine.\n\nIf you cannot reproduce it, say so and name every difference you found: OS,\nruntime version, dependency resolution, environment variable, timezone,\nparallelism, cached state. \"Cannot reproduce\" is a finding, not a failure.\n\n### 6. Choose exactly one action\n\n- **Retry** - only when you already have evidence the failure is flaky. Name\n  the green run of the same job on the same SHA.\n- **Fix the code** - name the file, line, and change. This is the default for a\n  deterministic bug.\n- **Fix the pipeline** - name the workflow file and line. This is for pipeline\n  faults, not for hiding a real failure.\n\nFor a flaky test, do the follow-up work instead of re-running forever:\n\n1. Run it repeatedly and record the failure rate: `for i in $(seq 1 20); do \u003Ccommand>; done`\n2. Find the shared state, timing assumption, or ordering dependency behind it\n3. Fix or quarantine it with an owner and a removal date, and say which\n\n### 7. Verify and report\n\nRe-run the check after the fix and show the result. For a flaky test, show the\nrepeated runs.\n\nReport in this shape:\n\n```text\nCheck:      \u003Cname> on \u003CSHA>\nFirst error: \u003Cquoted line> (\u003Cstep>, \u003Ccommand>)\nClass:      bug | flaky | environment | pipeline\nOwnership:  introduced by \u003Ccommit\u002Ffile:line> | pre-existing (\u003Crun link>)\nReproduced: yes (\u003Ccommand>) | no (\u003Cdifferences>)\nAction:     retry | fix code | fix pipeline\nResult:     \u003Crun link, or the repeated-run tally>\n```\n\n## Verification Checklist\n\n- [ ] The quoted error comes from the real log, with the step and command named\n- [ ] The failure is classified, with the evidence for that class\n- [ ] The base branch and recent runs were checked before claiming ownership\n- [ ] The failure was reproduced with CI versions, or the differences are listed\n- [ ] The recommended action is one of retry, fix code, or fix pipeline, with a reason\n- [ ] The check was re-run after the fix, and the result is shown\n\n## Rules\n\n- Never recommend re-running without evidence that the failure is flaky\n- Never call a failure unrelated without comparing against the base branch\n- Never skip, delete, or weaken a failing test to make a check pass\n- Never add `continue-on-error`, `if: always()`, or a path filter to hide a real failure\n- Never treat a passing retry as proof the root cause is gone; say what changed\n- Never diagnose from a summary line when the full log is available\n\n## Validation\n\n[`references\u002Fvalidation.md`](references\u002Fvalidation.md) records this skill applied\nto real failed checks on a public repository: the job log, the classification,\nthe ownership evidence, the reproduction attempt, and the recommended action.\n\nThe first scenario is a transcript from GitHub Copilot CLI, prompted only with\nthe failing job log, in a checkout where the failing command passes. It returned\nthe report format below, classified the failure as pipeline, and attributed it to\nthe parent commit rather than the change under test. Both findings were confirmed\nafterwards, and a depth-1 checkout reproduces the failure. The scenario exists to\nshow the report surviving a green local run instead of collapsing into \"cannot\nreproduce, probably flaky\".\n\n## Limitations\n\n- Log access depends on permissions. Without it, ask for the log instead of guessing\n- Private runners and self-hosted infrastructure can fail for reasons the log does not show\n- A failure that only reproduces under load or on real hardware may need production-like infrastructure\n- This skill diagnoses and recommends. It does not decide whether a check is allowed to be bypassed; that is a policy decision for the repository owner\n","# Diagnose CI Gate\n\nA red check is a claim, not a diagnosis. Before you change code or press\nre-run, establish three things from evidence: what actually failed, which class\nof failure it is, and whether this change caused it.\n\nThis skill is for a failing required check on a pull request or a branch. For\ncutting CI cost in general, use the `github-actions-efficiency` skill. For a\ndomain-specific flaky suite, use the skill for that tool (for example\n`cypress-flake-fixer`) after this triage.\n\n## When to Use This Skill\n\n- A required check fails on a pull request and you need to know if it is yours\n- A job passes locally but fails in CI, or fails on only some runs\n- Someone says \"that failure is unrelated, just re-run it\"\n- A build has been retried several times and keeps failing\n- You are about to edit a workflow file to make a check pass\n\n## Prerequisites\n\n- `gh` CLI authenticated, or the raw logs pasted by the user\n- Read access to the base branch and its recent runs\n- The commands in the failing step, so they can be reproduced\n\nIf logs are truncated, partial, or only a summary, stop and ask for the full\nlog. Do not diagnose from the last few lines of a summarized check.\n\n## Workflow\n\n### 1. Get the failing job, not the check summary\n\n```bash\ngh pr checks \u003Cpr-number>                     # which check, which state\ngh run list --branch \u003Cbranch> --limit 10     # current and recent runs\ngh run view \u003Crun-id> --log-failed            # only the failing steps\ngh run view \u003Crun-id> --job \u003Cjob-id> --log    # one job, full log\n```\n\nRecord the commit SHA under test, the runner image, and the time. A failure on\nan older SHA is a different problem from a failure on the current head.\n\n### 2. Read from the first error\n\nRead the top of the failing step, not the bottom. The first error is usually\nthe cause; everything after it is fallout from that cause or from the runner\ngiving up.\n\nQuote the exact lines, and name the command that produced them. If the log\nshows only a summary line (`Process completed with exit code 1`), find the step\nthat emitted it and read that step's output.\n\n### 3. Classify the failure\n\n| Class | Signal | Confirm by |\n| --- | --- | --- |\n| **Bug** | Same failure every run, deterministic input | Re-running fails identically at the same assertion |\n| **Flaky** | Passes sometimes, timing\u002Fordering\u002Fnetwork\u002Fshared state | At least one green run of the same job on the same SHA, or a local loop that fails intermittently |\n| **Environment** | Tool version, missing secret, runner image, cache, disk or memory | Version in CI differs from local, or the step fails before any project code runs |\n| **Pipeline** | The workflow itself is wrong: bad path filter, wrong working directory, missing dependency install, YAML error, or a check that asserts a target the pull request cannot produce (such as a production URL for a page that is not merged yet) | The command succeeds against the pull request's own build, and the workflow line or its target is demonstrably wrong |\n\nWrite the class and the evidence for it in one sentence each. A failure that\ncannot be classified is not ready for a fix.\n\n### 4. Decide whether this change caused it\n\nCompare with the base branch before claiming anything about ownership:\n\n```bash\ngh run list --branch main --limit 10\ngit merge-base HEAD origin\u002Fmain\n```\n\nIf the same job fails on the base branch, or on recent runs of the base branch,\nit is pre-existing. Say so and link the run.\n\nSome jobs only run on pull requests, so no base-branch run exists. In that case,\nsay that instead of implying you compared, and use the diff to establish what\nthe change added.\n\nTo test the base directly without disturbing the worktree, create a unique\nthrowaway worktree and remove it when done:\n\n```bash\nbase_dir=\"$(mktemp -d)\"\ngit worktree add \"$base_dir\" \"$(git merge-base HEAD origin\u002Fmain)\"\n( cd \"$base_dir\" && \u003Cfailing command> )\ngit worktree remove --force \"$base_dir\"\n```\n\n`mktemp -d` returns a fresh path, so concurrent runs cannot collide. `--force` is\nsafe here because the directory was created for this check and the failing\ncommand may have written build output into it. Never point this at a path that\nholds work, and remove the worktree with `git worktree remove` instead of\ndeleting the directory by hand. If a directory was deleted by hand, run\n`git worktree prune`.\n\nThis example is POSIX shell. On Windows, run it from Git Bash, or use\nPowerShell:\n\n```powershell\n$baseDir = Join-Path $env:TEMP (\"ci-base-\" + [guid]::NewGuid())\ngit worktree add $baseDir (git merge-base HEAD origin\u002Fmain)\nPush-Location $baseDir; \u003Cfailing command>; Pop-Location\ngit worktree remove --force $baseDir\n```\n\nIf it passes on the base and fails on the head, name the commit and the file and\nline that introduced it. If the change is a dependency bump, check the lockfile\ndiff and the tool version, not only the source diff.\n\n### 5. Reproduce with CI's versions\n\nRun the failing command with the versions CI used, from the same working\ndirectory, with the same environment variables and the same install step. Read\nthe versions from the log, not from your local machine.\n\nIf you cannot reproduce it, say so and name every difference you found: OS,\nruntime version, dependency resolution, environment variable, timezone,\nparallelism, cached state. \"Cannot reproduce\" is a finding, not a failure.\n\n### 6. Choose exactly one action\n\n- **Retry** - only when you already have evidence the failure is flaky. Name\n  the green run of the same job on the same SHA.\n- **Fix the code** - name the file, line, and change. This is the default for a\n  deterministic bug.\n- **Fix the pipeline** - name the workflow file and line. This is for pipeline\n  faults, not for hiding a real failure.\n\nFor a flaky test, do the follow-up work instead of re-running forever:\n\n1. Run it repeatedly and record the failure rate: `for i in $(seq 1 20); do \u003Ccommand>; done`\n2. Find the shared state, timing assumption, or ordering dependency behind it\n3. Fix or quarantine it with an owner and a removal date, and say which\n\n### 7. Verify and report\n\nRe-run the check after the fix and show the result. For a flaky test, show the\nrepeated runs.\n\nReport in this shape:\n\n```text\nCheck:      \u003Cname> on \u003CSHA>\nFirst error: \u003Cquoted line> (\u003Cstep>, \u003Ccommand>)\nClass:      bug | flaky | environment | pipeline\nOwnership:  introduced by \u003Ccommit\u002Ffile:line> | pre-existing (\u003Crun link>)\nReproduced: yes (\u003Ccommand>) | no (\u003Cdifferences>)\nAction:     retry | fix code | fix pipeline\nResult:     \u003Crun link, or the repeated-run tally>\n```\n\n## Verification Checklist\n\n- [ ] The quoted error comes from the real log, with the step and command named\n- [ ] The failure is classified, with the evidence for that class\n- [ ] The base branch and recent runs were checked before claiming ownership\n- [ ] The failure was reproduced with CI versions, or the differences are listed\n- [ ] The recommended action is one of retry, fix code, or fix pipeline, with a reason\n- [ ] The check was re-run after the fix, and the result is shown\n\n## Rules\n\n- Never recommend re-running without evidence that the failure is flaky\n- Never call a failure unrelated without comparing against the base branch\n- Never skip, delete, or weaken a failing test to make a check pass\n- Never add `continue-on-error`, `if: always()`, or a path filter to hide a real failure\n- Never treat a passing retry as proof the root cause is gone; say what changed\n- Never diagnose from a summary line when the full log is available\n\n## Validation\n\n[`references\u002Fvalidation.md`](references\u002Fvalidation.md) records this skill applied\nto real failed checks on a public repository: the job log, the classification,\nthe ownership evidence, the reproduction attempt, and the recommended action.\n\nThe first scenario is a transcript from GitHub Copilot CLI, prompted only with\nthe failing job log, in a checkout where the failing command passes. It returned\nthe report format below, classified the failure as pipeline, and attributed it to\nthe parent commit rather than the change under test. Both findings were confirmed\nafterwards, and a depth-1 checkout reproduces the failure. The scenario exists to\nshow the report surviving a green local run instead of collapsing into \"cannot\nreproduce, probably flaky\".\n\n## Limitations\n\n- Log access depends on permissions. Without it, ask for the log instead of guessing\n- Private runners and self-hosted infrastructure can fail for reasons the log does not show\n- A failure that only reproduces under load or on real hardware may need production-like infrastructure\n- This skill diagnoses and recommends. It does not decide whether a check is allowed to be bypassed; that is a policy decision for the repository owner\n",{"name":5,"description":7},"main","7e408815ddcb64889a3683799a85399331cfd4ef","skills\u002Fdiagnose-ci-gate",5360,"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-15 04:42:30",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add github\u002Fawesome-copilot --skill diagnose-ci-gate",{"tool":68,"command":69},"bunx","bunx skills add github\u002Fawesome-copilot --skill diagnose-ci-gate",{"tool":71,"command":72},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill diagnose-ci-gate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdiagnose-ci-gate\u002FSKILL.md",true,[76],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fvalidation.md","REFERENCE","参考文档",6284,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdiagnose-ci-gate\u002Freferences\u002Fvalidation.md",[83,111,139,169,203,220],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":93,"publishedAt":47},"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",[89,92],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[94,95,96,97,98,31,99,29,100,101,102,103,104,105,106,107,42,108,109,110],"supabase","rls","supabase rls","supabase rls policies","project","review","read","write","security","isolation","tables","as","tests","prove","users","functions","with",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":47},"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",[117],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138],"distribution","skill distribution audit","audit","SET","deterministic","installer","for","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","release","reconcile",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":143,"sourceHtmlUrl":144,"categories":145,"keywords":151,"publishedAt":47},"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",[146],{"categoryNo":147,"categoryName":148,"taxonomyType":149,"taxonomyTypeDesc":150},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[152,153,154,155,156,157,125,98,158,159,160,161,162,163,164,42,165,166,167,168],"custom","code","logicapps custom code net10 migration","migration","projects","standalone","deployment","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":173,"sourceHtmlUrl":174,"categories":175,"keywords":180,"publishedAt":47},"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",[176,179],{"categoryNo":177,"categoryName":178,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":147,"categoryName":148,"taxonomyType":149,"taxonomyTypeDesc":150},[181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,31,196,197,198,199,200,125,201,202],"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":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":207,"licenseFileUrl":208,"sourceHtmlUrl":209,"categories":210,"keywords":216,"publishedAt":47},"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",[211,212,215],{"categoryNo":177,"categoryName":178,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":213,"categoryName":214,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[217,122,190,218,219],"resemble detect","https","identity",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":207,"licenseFileUrl":224,"sourceHtmlUrl":225,"categories":226,"keywords":231,"publishedAt":47},"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",[227,230],{"categoryNo":228,"categoryName":229,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[232,233,234,235,153,99,9,121,236,237,218,238,239,240,241,242,243,244,40,245,246,247,106,248,249,250,251],"playbook","quality playbook","quality","code review","tdd","run","report","spec","bug report","council","engineering","functional","spec audit","verified","multi-model","three","coverage","model","regression","structural"]