[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADMN395ZHESBP96MEQ5CS3":3,"skill-same:01M6ADMN395ZHESBP96MEQ5CS3":75},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6ADMN395ZHESBP96MEQ5CS3","git-commit",null,"Use this skill when the user wants to make a Git commit or split changes into more than one commit. Also use it when the user types \"\u002Fcommit\" or asks for a conventional commit. The skill examines the diff, stages the related files, writes a Conventional Commits message, and runs git commit. Do not use it when the user wants only a commit message and no commit. Do not use it to push, open a pull request, rebase, or change the commit history.","github\u002Fawesome-copilot","github","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9919?v=4","01M6AC83DS133TPXFSP1DHNCC6","GitHub","01M6AD3PBDYPK7NVFJNJ66Y8RS",41081,"MIT","https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fgit-commit\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],"git commit","commit","git","fallback","make","add","rebase","request","later","message","conventional commits","when","files","only","open","option","types","conventional commit","change","pull","2026-11-10 10:12:30",false,"---\nname: git-commit\ndescription: 'Use this skill when the user wants to make a Git commit or split changes into more than one commit. Also use it when the user types \"\u002Fcommit\" or asks for a conventional commit. The skill examines the diff, stages the related files, writes a Conventional Commits message, and runs git commit. Do not use it when the user wants only a commit message and no commit. Do not use it to push, open a pull request, rebase, or change the commit history.'\nlicense: MIT\ncompatibility: 'Requires Git. The `--resolved` option of `git add` requires Git 2.56 or later. Older versions use the fallback in step 3.'\nallowed-tools: shell(git:*)\n---\n\n# Git Commit with Conventional Commits\n\nMake Git commits that follow the [Conventional Commits 1.0.0](https:\u002F\u002Fwww.conventionalcommits.org\u002Fen\u002Fv1.0.0\u002F) specification. Get the type, the scope, and the summary from the diff.\n\n## Message Format\n\n```text\n\u003Ctype>(\u003Cscope>): \u003Csummary>\n\n\u003Cbody>\n\n\u003Cfooter>\n```\n\n- The scope, the body, and the footer are optional. Without a scope, write `\u003Ctype>: \u003Csummary>`.\n- Write the summary in the imperative mood: \"add\", not \"added\" or \"adds\".\n- Keep the first line at 72 characters or less. Do not put a period at the end.\n- In the body, tell what changed and why.\n- Write each footer as `Token: value` or `Token #value`, for example `Refs: #456` or `Closes #123`. Conventional Commits accepts the two forms, but Git reads only `Token: value` as a trailer. In a token, use `-` in place of a space.\n\n## Types\n\nConventional Commits defines only `feat` and `fix`. The other types come from the Angular convention ([`@commitlint\u002Fconfig-conventional`](https:\u002F\u002Fgithub.com\u002Fconventional-changelog\u002Fcommitlint\u002Ftree\u002Fmaster\u002F%40commitlint\u002Fconfig-conventional)). If the repository has its own list, use that list.\n\n| Type       | Use it for                                     |\n| ---------- | ---------------------------------------------- |\n| `feat`     | A new feature                                  |\n| `fix`      | A bug fix                                      |\n| `docs`     | Documentation only                             |\n| `style`    | Formatting only, with no change to the logic   |\n| `refactor` | A code change that is not a feature or a fix   |\n| `perf`     | A performance improvement                      |\n| `test`     | New or changed tests                           |\n| `build`    | The build system or the dependencies           |\n| `ci`       | The CI configuration                           |\n| `chore`    | Other maintenance                              |\n| `revert`   | A revert of an earlier commit                  |\n\n## Breaking Changes\n\nPut `!` before the colon, or add a `BREAKING CHANGE:` footer. Write the token in uppercase. `BREAKING-CHANGE:` is also correct.\n\n```text\nfeat(api)!: remove the v1 endpoints\n\nBREAKING CHANGE: Clients must use the v2 endpoints.\n```\n\n## Workflow\n\n### 1. Read the repository rules\n\nFind the commit rules before you write a message:\n\n- A commitlint configuration, for example `commitlint.config.js` or `.commitlintrc.json`.\n- `CONTRIBUTING.md`.\n- The recent messages: `git log --oneline -10`.\n\nIf a repository rule is different from this skill, use the repository rule.\n\n### 2. Examine the changes\n\n```bash\ngit status --porcelain\ngit diff --staged\ngit diff\n```\n\nIf there are no changes, run the checks at the start of step 3. If they find `MERGE_HEAD`, continue. If not, tell the user what `git status --long` shows. Do not make an empty commit.\n\n### 3. Stage the files\n\nFirst, check for an operation in progress. Run each command alone. Do not chain them with `&&`. In a subdirectory, run every command in this step as `git -C \u003Croot> ...`. `git rev-parse --show-toplevel` prints the root.\n\n```bash\ngit rev-parse -q --verify --symbolic-full-name MERGE_HEAD\ngit rev-parse -q --verify --symbolic-full-name CHERRY_PICK_HEAD\ngit rev-parse -q --verify --symbolic-full-name REVERT_HEAD\ngit diff --name-only --diff-filter=U --no-relative\ngit status --long\n```\n\nA `rev-parse` command prints a ref name if its operation is in progress. If not, the command prints nothing and exits with status 1. The `git diff` command lists unmerged files. It finds conflicts that have no ref, for example from `git stash pop`. `git status --long` shows the other cases.\n\n**If an operation is in progress or there are unmerged files**, do not unstage files. Do not split the commit. The index holds the result of the operation. If you unstage a file, Git drops the changes of the other side or removes a conflict entry.\n\n- Stop and tell the user if `git status --long` shows \"rebase in progress\", \"You are in the middle of an am session\", \"Cherry-pick currently in progress\", or \"Revert currently in progress\".\n- Run `git status --porcelain=v2`. A line that starts with `u` shows an unmerged file. You can resolve the file only if all these conditions are true:\n  - The line starts with `u UU N...` or `u AA N...`.\n  - Each mode on the line is `100644`, `100755`, or `000000`.\n  - `git diff --no-relative` does not show `Binary files differ` for the file.\n- Ask the user how to resolve all other unmerged files. Git cannot find conflict markers in these files. `git add --resolved` and the checks below stage these files without a warning. Stage each of these files only after the user resolves it: `git add -- \u003Cpath>`.\n- With Git 2.56 or later, stage the files that you can resolve with `git add --resolved -- \u003Cpaths>`.\n- With older Git, check those files and stage them:\n\n```bash\ngit diff --check -- path\u002Fto\u002Ffile1 path\u002Fto\u002Ffile2\ngit add -- path\u002Fto\u002Ffile1 path\u002Fto\u002Ffile2\n```\n\n- Stage the files only if `git diff --check` finds no \"leftover conflict marker\" line. Ignore whitespace warnings from the other branch.\n- Then, with any Git version, run `git diff --name-only --no-relative` and `git ls-files --others --exclude-standard`. They list edits in other files. Skip the files that are still unmerged.\n- Show these paths to the user. Ask if they belong to the commit. Stage only the approved paths with `git add -- \u003Cpaths>`.\n- Git quotes some paths, for example paths with non-ASCII characters. `git add` fails for a quoted path. Ask the user about these files.\n\n**If there is no operation and no unmerged file**, put one logical change in each commit. If the staged files contain more than one change, first unstage the files of the other changes. Then stage the files for this change:\n\n```bash\ngit reset -q -- path\u002Fto\u002Fother-file1 path\u002Fto\u002Fother-file2\ngit add -- path\u002Fto\u002Ffile1 path\u002Fto\u002Ffile2\ngit add -- '*.test.*'\ngit add -- src\u002Fcomponents\u002F\n```\n\n- Put a glob in quotes. Without quotes, the shell expands the glob and does not find the files in subdirectories.\n- Do not use `git add -p` or `git add -i`. These commands wait for input from a person.\n- Examine the list of staged files with `git diff --staged --name-only`. Do not commit secrets, for example `.env` files, `credentials.json`, or private keys.\n\n### 4. Write the message\n\nGet each part from the diff:\n\n- **Type**: The kind of change.\n- **Scope**: The module or the area that the change affects.\n- **Summary**: What changed, in one line.\n\n### 5. Commit\n\nWhen step 3 finds `MERGE_HEAD`, `CHERRY_PICK_HEAD`, or `REVERT_HEAD`, run `git commit --no-edit` with no paths and no `--cleanup` option. This keeps the message that Git prepared. Do not write a new `-m` message. The message can keep the `Conflicts:` comment lines from Git. Do not remove them.\n\nIn all other cases:\n\nGive each paragraph with a different `-m` option. Git puts a blank line between the paragraphs. This command works in Bash, PowerShell, and other shells.\n\n```bash\ngit commit -m \"feat(auth): add token refresh\"\ngit commit -m \"fix(parser): accept empty input\" -m \"An empty file caused a crash.\" -m \"Closes: #123\"\n```\n\nFor a long message, write the message to a temporary file. Then run `git commit -F \u003Cfile>`.\n\n### 6. Make sure that the commit is correct\n\n```bash\ngit log -1 --stat --first-parent\ngit status --porcelain\n```\n\n## Safety Rules\n\n- Do not change the Git configuration.\n- Do not use `--no-verify` unless the user tells you to. Hooks can be in `.git\u002Fhooks` or in the Git configuration.\n- If a hook fails, Git does not make the commit. Fix the problem, stage the files again, and run the same `git commit` command again. Do not use `--amend`, because it changes the previous commit.\n- Do not change the commit history unless the user tells you to. Do not use `git reset --hard`, `git rebase`, or the experimental `git history` command.\n- Do not push unless the user tells you to. Do not force push to the default branch.\n","# Git Commit with Conventional Commits\n\nMake Git commits that follow the [Conventional Commits 1.0.0](https:\u002F\u002Fwww.conventionalcommits.org\u002Fen\u002Fv1.0.0\u002F) specification. Get the type, the scope, and the summary from the diff.\n\n## Message Format\n\n```text\n\u003Ctype>(\u003Cscope>): \u003Csummary>\n\n\u003Cbody>\n\n\u003Cfooter>\n```\n\n- The scope, the body, and the footer are optional. Without a scope, write `\u003Ctype>: \u003Csummary>`.\n- Write the summary in the imperative mood: \"add\", not \"added\" or \"adds\".\n- Keep the first line at 72 characters or less. Do not put a period at the end.\n- In the body, tell what changed and why.\n- Write each footer as `Token: value` or `Token #value`, for example `Refs: #456` or `Closes #123`. Conventional Commits accepts the two forms, but Git reads only `Token: value` as a trailer. In a token, use `-` in place of a space.\n\n## Types\n\nConventional Commits defines only `feat` and `fix`. The other types come from the Angular convention ([`@commitlint\u002Fconfig-conventional`](https:\u002F\u002Fgithub.com\u002Fconventional-changelog\u002Fcommitlint\u002Ftree\u002Fmaster\u002F%40commitlint\u002Fconfig-conventional)). If the repository has its own list, use that list.\n\n| Type       | Use it for                                     |\n| ---------- | ---------------------------------------------- |\n| `feat`     | A new feature                                  |\n| `fix`      | A bug fix                                      |\n| `docs`     | Documentation only                             |\n| `style`    | Formatting only, with no change to the logic   |\n| `refactor` | A code change that is not a feature or a fix   |\n| `perf`     | A performance improvement                      |\n| `test`     | New or changed tests                           |\n| `build`    | The build system or the dependencies           |\n| `ci`       | The CI configuration                           |\n| `chore`    | Other maintenance                              |\n| `revert`   | A revert of an earlier commit                  |\n\n## Breaking Changes\n\nPut `!` before the colon, or add a `BREAKING CHANGE:` footer. Write the token in uppercase. `BREAKING-CHANGE:` is also correct.\n\n```text\nfeat(api)!: remove the v1 endpoints\n\nBREAKING CHANGE: Clients must use the v2 endpoints.\n```\n\n## Workflow\n\n### 1. Read the repository rules\n\nFind the commit rules before you write a message:\n\n- A commitlint configuration, for example `commitlint.config.js` or `.commitlintrc.json`.\n- `CONTRIBUTING.md`.\n- The recent messages: `git log --oneline -10`.\n\nIf a repository rule is different from this skill, use the repository rule.\n\n### 2. Examine the changes\n\n```bash\ngit status --porcelain\ngit diff --staged\ngit diff\n```\n\nIf there are no changes, run the checks at the start of step 3. If they find `MERGE_HEAD`, continue. If not, tell the user what `git status --long` shows. Do not make an empty commit.\n\n### 3. Stage the files\n\nFirst, check for an operation in progress. Run each command alone. Do not chain them with `&&`. In a subdirectory, run every command in this step as `git -C \u003Croot> ...`. `git rev-parse --show-toplevel` prints the root.\n\n```bash\ngit rev-parse -q --verify --symbolic-full-name MERGE_HEAD\ngit rev-parse -q --verify --symbolic-full-name CHERRY_PICK_HEAD\ngit rev-parse -q --verify --symbolic-full-name REVERT_HEAD\ngit diff --name-only --diff-filter=U --no-relative\ngit status --long\n```\n\nA `rev-parse` command prints a ref name if its operation is in progress. If not, the command prints nothing and exits with status 1. The `git diff` command lists unmerged files. It finds conflicts that have no ref, for example from `git stash pop`. `git status --long` shows the other cases.\n\n**If an operation is in progress or there are unmerged files**, do not unstage files. Do not split the commit. The index holds the result of the operation. If you unstage a file, Git drops the changes of the other side or removes a conflict entry.\n\n- Stop and tell the user if `git status --long` shows \"rebase in progress\", \"You are in the middle of an am session\", \"Cherry-pick currently in progress\", or \"Revert currently in progress\".\n- Run `git status --porcelain=v2`. A line that starts with `u` shows an unmerged file. You can resolve the file only if all these conditions are true:\n  - The line starts with `u UU N...` or `u AA N...`.\n  - Each mode on the line is `100644`, `100755`, or `000000`.\n  - `git diff --no-relative` does not show `Binary files differ` for the file.\n- Ask the user how to resolve all other unmerged files. Git cannot find conflict markers in these files. `git add --resolved` and the checks below stage these files without a warning. Stage each of these files only after the user resolves it: `git add -- \u003Cpath>`.\n- With Git 2.56 or later, stage the files that you can resolve with `git add --resolved -- \u003Cpaths>`.\n- With older Git, check those files and stage them:\n\n```bash\ngit diff --check -- path\u002Fto\u002Ffile1 path\u002Fto\u002Ffile2\ngit add -- path\u002Fto\u002Ffile1 path\u002Fto\u002Ffile2\n```\n\n- Stage the files only if `git diff --check` finds no \"leftover conflict marker\" line. Ignore whitespace warnings from the other branch.\n- Then, with any Git version, run `git diff --name-only --no-relative` and `git ls-files --others --exclude-standard`. They list edits in other files. Skip the files that are still unmerged.\n- Show these paths to the user. Ask if they belong to the commit. Stage only the approved paths with `git add -- \u003Cpaths>`.\n- Git quotes some paths, for example paths with non-ASCII characters. `git add` fails for a quoted path. Ask the user about these files.\n\n**If there is no operation and no unmerged file**, put one logical change in each commit. If the staged files contain more than one change, first unstage the files of the other changes. Then stage the files for this change:\n\n```bash\ngit reset -q -- path\u002Fto\u002Fother-file1 path\u002Fto\u002Fother-file2\ngit add -- path\u002Fto\u002Ffile1 path\u002Fto\u002Ffile2\ngit add -- '*.test.*'\ngit add -- src\u002Fcomponents\u002F\n```\n\n- Put a glob in quotes. Without quotes, the shell expands the glob and does not find the files in subdirectories.\n- Do not use `git add -p` or `git add -i`. These commands wait for input from a person.\n- Examine the list of staged files with `git diff --staged --name-only`. Do not commit secrets, for example `.env` files, `credentials.json`, or private keys.\n\n### 4. Write the message\n\nGet each part from the diff:\n\n- **Type**: The kind of change.\n- **Scope**: The module or the area that the change affects.\n- **Summary**: What changed, in one line.\n\n### 5. Commit\n\nWhen step 3 finds `MERGE_HEAD`, `CHERRY_PICK_HEAD`, or `REVERT_HEAD`, run `git commit --no-edit` with no paths and no `--cleanup` option. This keeps the message that Git prepared. Do not write a new `-m` message. The message can keep the `Conflicts:` comment lines from Git. Do not remove them.\n\nIn all other cases:\n\nGive each paragraph with a different `-m` option. Git puts a blank line between the paragraphs. This command works in Bash, PowerShell, and other shells.\n\n```bash\ngit commit -m \"feat(auth): add token refresh\"\ngit commit -m \"fix(parser): accept empty input\" -m \"An empty file caused a crash.\" -m \"Closes: #123\"\n```\n\nFor a long message, write the message to a temporary file. Then run `git commit -F \u003Cfile>`.\n\n### 6. Make sure that the commit is correct\n\n```bash\ngit log -1 --stat --first-parent\ngit status --porcelain\n```\n\n## Safety Rules\n\n- Do not change the Git configuration.\n- Do not use `--no-verify` unless the user tells you to. Hooks can be in `.git\u002Fhooks` or in the Git configuration.\n- If a hook fails, Git does not make the commit. Fix the problem, stage the files again, and run the same `git commit` command again. Do not use `--amend`, because it changes the previous commit.\n- Do not change the commit history unless the user tells you to. Do not use `git reset --hard`, `git rebase`, or the experimental `git history` command.\n- Do not push unless the user tells you to. Do not force push to the default branch.\n",{"name":5,"license":15,"description":7,"allowed-tools":49,"compatibility":50},"shell(git:*)","Requires Git. The `--resolved` option of `git add` requires Git 2.56 or later. Older versions use the fallback in step 3.","main","797337f33f73e35d08d82f840e21c4b8c4932d88","skills\u002Fgit-commit",5344,"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 02:05:36",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add github\u002Fawesome-copilot --skill git-commit",{"tool":67,"command":68},"bunx","bunx skills add github\u002Fawesome-copilot --skill git-commit",{"tool":70,"command":71},"pnpm","pnpm dlx skills add github\u002Fawesome-copilot --skill git-commit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fgit-commit\u002FSKILL.md",true,[],[76,105,133,163,197,214],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":86,"publishedAt":44},"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",[82,85],{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[87,88,89,90,91,35,92,42,93,94,95,96,97,98,99,100,101,102,103,104],"supabase","rls","supabase rls","supabase rls policies","project","review","read","write","security","isolation","tables","as","tests","prove","use","users","functions","with",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":44},"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",[111],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132],"distribution","skill distribution audit","audit","SET","deterministic","installer","for","discovery","comparison","helper","manifest","version","collection","drift","output","investigate","duplicate","template","release","reconcile",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":137,"sourceHtmlUrl":138,"categories":139,"keywords":145,"publishedAt":44},"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",[140],{"categoryNo":141,"categoryName":142,"taxonomyType":143,"taxonomyTypeDesc":144},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[146,147,148,149,150,151,119,91,152,153,154,155,156,157,158,101,159,160,161,162],"custom","code","logicapps custom code net10 migration","migration","projects","standalone","deployment","applications","local","azure","worker","upgrades","package","apps","Legacy","debugging","workflows",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":167,"sourceHtmlUrl":168,"categories":169,"keywords":174,"publishedAt":44},"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",[170,173],{"categoryNo":171,"categoryName":172,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":141,"categoryName":142,"taxonomyType":143,"taxonomyTypeDesc":144},[175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,35,190,191,192,193,194,119,195,196],"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":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":201,"licenseFileUrl":202,"sourceHtmlUrl":203,"categories":204,"keywords":210,"publishedAt":44},"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",[205,206,209],{"categoryNo":171,"categoryName":172,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":207,"categoryName":208,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[211,116,184,212,213],"resemble detect","https","identity",{"skillNo":215,"name":216,"nameZh":6,"description":217,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":201,"licenseFileUrl":218,"sourceHtmlUrl":219,"categories":220,"keywords":225,"publishedAt":44},"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",[221,224],{"categoryNo":222,"categoryName":223,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[226,227,228,229,147,92,9,115,230,231,212,232,233,234,235,236,237,238,239,240,241,242,99,243,244,245,246],"playbook","quality playbook","quality","code review","tdd","run","report","spec","bug report","council","engineering","functional","spec audit","bug","verified","multi-model","three","coverage","model","regression","structural"]