[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6991834X0J4D87MPV5ZGW2A":3,"skill-same:01M6991834X0J4D87MPV5ZGW2A":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6991834X0J4D87MPV5ZGW2A","implement-issue",null,"Implement a Site Kit GitHub issue end-to-end from its implementation brief. Use when the user asks to implement, build, or work on a GitHub issue \u002F feature by number (e.g. \"implement issue #12345\", \"build the feature in issue 12345\", \"follow the implementation brief for #12345\") in the google\u002Fsite-kit-wp repo.","google\u002Fsite-kit-wp","google","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1342004?v=4","01M698VYEFDM0VJBZDYYJ2T83S","Google","01M69913CJ7EWER6YJA1HXMZQV",1405,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fsite-kit-wp\u002Fblob\u002Fdevelop\u002F.agents\u002Fskills\u002Fimplement-issue\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,9,32,33,34,35,36,37,38],"implement issue","implement","issue","read","when","for","number","kit","end","feature","build","github issue","use","repo","work","work on","Bash","brief","site kit","github","2026-11-10 10:12:30",false,"---\nname: implement-issue\ndescription: >\n  Implement a Site Kit GitHub issue end-to-end from its implementation brief. Use when the\n  user asks to implement, build, or work on a GitHub issue \u002F feature by number (e.g.\n  \"implement issue #12345\", \"build the feature in issue 12345\", \"follow the implementation\n  brief for #12345\") in the google\u002Fsite-kit-wp repo.\nargument-hint: \"[issue-number]\"\nallowed-tools: Bash, Read, Grep, Glob, Edit, Write\n---\n\n# Implement a GitHub issue\n\nImplement GitHub issue **#$ARGUMENTS**. If no number was given, ask for one.\n\nThe convention details live in `docs\u002Fcontext\u002Fjs\u002F` and `docs\u002Fcontext\u002Fphp\u002F`. This skill tells you\n_what to do and in what order_; those docs tell you _how the code must look_. Read only the\nconvention docs relevant to the issue (see the map in Step 3).\n\n---\n\n## Step 1 — Fetch and parse the issue\n\nFetch the issue from `google\u002Fsite-kit-wp` (e.g. `gh issue view \u003Cnumber> --json title,body,labels`,\nor the GitHub MCP issue tools).\n\nSite Kit issues follow `.github\u002FISSUE_TEMPLATE\u002Ffeature_request.md`. Extract these sections\nverbatim:\n\n- **Feature Description** — the problem \u002F publisher need.\n- **Acceptance criteria** — between `## Acceptance criteria` and `## Implementation Brief`.\n- **Implementation Brief** — between `## Implementation Brief` and `### Test Coverage` (the\n  technical checkboxes; your plan of work).\n- **Test Coverage** — between `### Test Coverage` and `## QA Brief`.\n- **QA Brief** — between `## QA Brief` and `## Changelog entry`.\n\nNote: the **Changelog entry** section is filled in by the merge reviewer at PR-merge time,\nnot when the issue is created — expect it to be empty and don't rely on it.\n\n**The acceptance criteria are the contract; the Implementation Brief is one route to satisfying\nthem.** Read both before you write any code, and where the two disagree the criteria win — the\nbrief is drafted first and the criteria keep moving through review, so the brief is the half that\ngoes stale. The brief also leaves user-facing copy and observable behavior to the criteria on\npurpose rather than quoting them, so a heading, label or error message you cannot find in the\nbrief is in the criteria, not missing. Where a criterion and a brief bullet genuinely cannot both\nbe satisfied, stop and ask.\n\n**Stop and ask the user** if: the issue can't be found, the body is empty, the section\nmarkers are missing, or the Implementation Brief is ambiguous\u002Fcontradictory. Do not guess\nat requirements.\n\n## Read every issue this one references — before writing any code\n\nSite Kit issues lean on their siblings: a brief says `(added in #12950)` for the store it\nbuilds on, `(see #13005)` for the extension point it leaves open, \"the create variant is\n#13022\" for the half that isn't yours. Those references carry requirements that the issue\nin front of you does not repeat.\n\nCollect every issue referenced anywhere in the Feature Description, Acceptance criteria,\nImplementation Brief and Test Coverage — `#12345`, a full `github.com\u002Fgoogle\u002Fsite-kit-wp\u002Fissues\u002F…`\nURL, the parent epic, and anything GitHub lists as linked — and read each one with\n`gh issue view \u003Cnumber> --json title,body,state,url` **before** you start implementing. From\neach, take:\n\n- **What it delivered**, when it is closed — the classes, selectors, hooks and constants your\n  brief expects to already be there. Confirm they exist in the branch you are on; a closed\n  issue whose PR has not been merged into your base leaves you building on nothing.\n- **What it will deliver**, when it is still open — the work that is *not* yours. Stop at that\n  boundary rather than implementing it, and don't duplicate a symbol it is going to add.\n- **Its acceptance criteria**, where they constrain yours — a shared payload shape, a naming\n  scheme, an ordering guarantee. Where a referenced issue and your brief disagree, the code\n  wins if it is already written; otherwise ask.\n\nRead the referenced issues themselves, not their references — follow a second hop only when\nthe first leaves a requirement genuinely unclear.\n\n**Stop and ask the user** if: a referenced issue can't be fetched; your brief depends on work\nthat a referenced issue has not landed yet; or the issue refers to a sibling **indirectly**\n(\"the next issue\", \"issue 5\", \"the issue that adds the store\") rather than by number — ask for\nthe real number instead of guessing which issue is meant.\n\n## Step 2 — Determine scope\n\nClassify the work and identify the affected module:\n\n- **JS-only** \u002F **PHP-only** \u002F **full-stack**.\n- Which module? JS lives in `assets\u002Fjs\u002F`, PHP in `includes\u002F`.\n\nWork on a feature branch off `develop`. Study an existing, similar feature before writing\nanything — match its structure and idioms.\n\n## Step 3 — Load the relevant convention docs\n\nRead **only** what the issue touches. Map:\n\n**JavaScript (`docs\u002Fcontext\u002Fjs\u002F`)**\n\n| If the issue involves… | Read |\n| --- | --- |\n| React components, PropTypes, imports, file headers | `component-conventions.md` |\n| Module file layout \u002F placement | `module-architecture.md` |\n| `@wordpress\u002Fdata` stores, selectors, resolvers, actions | `state-management.md` |\n| Custom hooks | `hooks.md` |\n| Reusable utilities | `utils.md` |\n| Dashboard widgets (context\u002Farea\u002Fwidget) | `widgets.md` |\n| Notifications \u002F banners | `notifications.md` |\n| Feature tours | `feature-tours.md` |\n| Feature flags | `feature-flags.md` |\n| `trackEvent` \u002F `trackEventOnce` | `event-tracking.md` |\n| JSDoc on utilities\u002Fhooks | `jsdoc.md` |\n| Storybook stories | `storybook.md` |\n| Jest tests | `tests.md` |\n\n**PHP (`docs\u002Fcontext\u002Fphp\u002F`)**\n\n| If the issue involves… | Read |\n| --- | --- |\n| A module class \u002F lifecycle \u002F interfaces | `module-architecture.md` |\n| Class\u002Fmethod\u002Ffile naming | `naming-conventions.md` |\n| Constructor DI | `dependency-injection.md` |\n| The `Context` service | `context-pattern.md` |\n| Settings \u002F module settings | `settings-management.md` |\n| `Options` \u002F `User_Options` \u002F `Transients` | `storage-patterns.md` |\n| REST routes | `rest-api.md` |\n| Traits \u002F horizontal reuse | `trait-composition.md` |\n| Script\u002Fstylesheet registration | `asset-management.md` |\n| Admin screens \u002F notices \u002F pointers | `admin-features.md` |\n| Prompts & dismissals | `prompts-and-dismissals.md` |\n| PHPUnit integration tests | `phpunit.md` |\n\n## Step 4 — Implement\n\nFollow the conventions you loaded in Step 3. In addition:\n\n- **Co-locate tests.** Add `*.test.js` \u002F `*.test.ts` \u002F `*.test.tsx` next to each\n  JS or Typescript source file; add `*Test.php` under the mirroring path in\n  `tests\u002Fphpunit\u002Fintegration\u002F`.\n- **Storybook.** Add a `*.stories.js` or `*.stories.tsx` next to any new UI component (and update VRT\n  reference images where relevant — see `tests\u002Fvrt\u002FREADME.md`).\n- **Styles.** Put SCSS under `assets\u002Fsass\u002F`.\n- **Feature flags.** Gate not-yet-shippable work behind a flag in `feature-flags.json`\n  (see `docs\u002Fcontext\u002Fjs\u002Ffeature-flags.md`).\n- Cover every Implementation Brief checkbox and Acceptance criterion. Implement the\n  **Test Coverage** items as real tests.\n\n## Step 5 — Self-review\n\nBefore verifying, review your own diff against `.agents\u002Fskills\u002Freview-pr\u002Freview-checklist.md`.\nFix every requirements gap and convention violation you find; address critical\u002Fhigh quality\nissues. The bar is: all acceptance criteria met, all relevant conventions followed, tests\nwritten and passing.\n\n## Step 6 — Verify\n\nRun, and fix anything that fails:\n\n- **Lint** — prefer scoping to the files you touched over the whole codebase:\n  - JS: `npm run lint:js:files -- \u003Cpath\u002Fto\u002Ffile.js>` (auto-fix the full codebase with\n    `npm run lint:js-fix`, or just your files with\n    `npm run lint:js:files -- --fix \u003Cpath\u002Fto\u002Ffile.js>`).\n  - PHP: `composer lint -- \u003Cpath\u002Fto\u002FFile.php>` (auto-fix with `composer lint-fix`).\n- **Build** — `npm run build:dev` when JS\u002Fasset changes are non-trivial.\n- **Tests** — run the **specific** test files you touched, not the whole suite:\n  - JS: `npm -w tests\u002Fjs run test:js -- \u003Cpath\u002Fto\u002Ffile.test.js>`\n  - PHP: `composer test -- --filter \u003CTestClassName>`\n- **Visual check (any change that affects rendering)** — for SCSS, layout, spacing,\n  alignment, or responsive rules, **render the change and look at it** before declaring it\n  done. Lint and build passing do **not** prove visual correctness, and a change that looks\n  like a trivial value tweak in the brief can still be visually wrong. Prefer the Storybook\n  story at the affected viewport(s); if no dev server is running, build a throwaway HTML\n  reproduction using the **real computed values** (typography from\n  `assets\u002Fsass\u002Fcomponents\u002Fglobal\u002F_googlesitekit-typography.scss`, breakpoints\u002Fsizes from\n  `assets\u002Fsass\u002Fconfig\u002F`) and open it in the browser. For responsive \u002F `@media` changes,\n  check **both sides** of every breakpoint you touch (the breakpoint variables, such as\n  `$bp-tablet`, are defined in `assets\u002Fsass\u002Fconfig\u002F_variables.scss`). A mobile-only rule is\n  invisible at desktop width, so look at the change at a width on each side. Confirm that\n  the VRT viewports in `tests\u002Fvrt\u002FREADME.md` cover both sides too. Re-check the exact state\n  described in the issue (e.g. the badge *next to the title*, not just the component in\n  isolation).\n- **VRT** — if you added\u002Fchanged a Storybook story, check just that story rather than\n  the full suite: `npm run test:visualtest -- --grep \"\u003Cstory label>\"`, and\n  `npm run test:visualapprove -- --grep \"\u003Cstory label>\"` to write the new reference\n  images (see `tests\u002Fvrt\u002FREADME.md`).\n\n## Step 7 — Wrap up\n\nSummarize what changed: files created\u002Fmodified\u002Fdeleted, how acceptance criteria are met,\nand verification results.\n\n---\n\n## Guardrails\n\n- **Local only.** Do **not** commit, push, or open a pull request unless the user explicitly\n  asks. The deliverable is a working, verified local change on the feature branch.\n- **No scope creep.** Implement what the brief specifies; flag anything underspecified rather\n  than inventing behavior. A referenced issue is context, never a work item — never implement\n  a sibling's brief because your issue mentions it.\n- **Commit messages** (only when asked to commit) must satisfy `bin\u002Fcheck-commit-msg.php`:\n  start with a capital letter, begin with a present-tense verb, contain more than one word,\n  and end with a full stop — e.g. `Track learn more about conversion tracking link.`\n","# Implement a GitHub issue\n\nImplement GitHub issue **#$ARGUMENTS**. If no number was given, ask for one.\n\nThe convention details live in `docs\u002Fcontext\u002Fjs\u002F` and `docs\u002Fcontext\u002Fphp\u002F`. This skill tells you\n_what to do and in what order_; those docs tell you _how the code must look_. Read only the\nconvention docs relevant to the issue (see the map in Step 3).\n\n---\n\n## Step 1 — Fetch and parse the issue\n\nFetch the issue from `google\u002Fsite-kit-wp` (e.g. `gh issue view \u003Cnumber> --json title,body,labels`,\nor the GitHub MCP issue tools).\n\nSite Kit issues follow `.github\u002FISSUE_TEMPLATE\u002Ffeature_request.md`. Extract these sections\nverbatim:\n\n- **Feature Description** — the problem \u002F publisher need.\n- **Acceptance criteria** — between `## Acceptance criteria` and `## Implementation Brief`.\n- **Implementation Brief** — between `## Implementation Brief` and `### Test Coverage` (the\n  technical checkboxes; your plan of work).\n- **Test Coverage** — between `### Test Coverage` and `## QA Brief`.\n- **QA Brief** — between `## QA Brief` and `## Changelog entry`.\n\nNote: the **Changelog entry** section is filled in by the merge reviewer at PR-merge time,\nnot when the issue is created — expect it to be empty and don't rely on it.\n\n**The acceptance criteria are the contract; the Implementation Brief is one route to satisfying\nthem.** Read both before you write any code, and where the two disagree the criteria win — the\nbrief is drafted first and the criteria keep moving through review, so the brief is the half that\ngoes stale. The brief also leaves user-facing copy and observable behavior to the criteria on\npurpose rather than quoting them, so a heading, label or error message you cannot find in the\nbrief is in the criteria, not missing. Where a criterion and a brief bullet genuinely cannot both\nbe satisfied, stop and ask.\n\n**Stop and ask the user** if: the issue can't be found, the body is empty, the section\nmarkers are missing, or the Implementation Brief is ambiguous\u002Fcontradictory. Do not guess\nat requirements.\n\n## Read every issue this one references — before writing any code\n\nSite Kit issues lean on their siblings: a brief says `(added in #12950)` for the store it\nbuilds on, `(see #13005)` for the extension point it leaves open, \"the create variant is\n#13022\" for the half that isn't yours. Those references carry requirements that the issue\nin front of you does not repeat.\n\nCollect every issue referenced anywhere in the Feature Description, Acceptance criteria,\nImplementation Brief and Test Coverage — `#12345`, a full `github.com\u002Fgoogle\u002Fsite-kit-wp\u002Fissues\u002F…`\nURL, the parent epic, and anything GitHub lists as linked — and read each one with\n`gh issue view \u003Cnumber> --json title,body,state,url` **before** you start implementing. From\neach, take:\n\n- **What it delivered**, when it is closed — the classes, selectors, hooks and constants your\n  brief expects to already be there. Confirm they exist in the branch you are on; a closed\n  issue whose PR has not been merged into your base leaves you building on nothing.\n- **What it will deliver**, when it is still open — the work that is *not* yours. Stop at that\n  boundary rather than implementing it, and don't duplicate a symbol it is going to add.\n- **Its acceptance criteria**, where they constrain yours — a shared payload shape, a naming\n  scheme, an ordering guarantee. Where a referenced issue and your brief disagree, the code\n  wins if it is already written; otherwise ask.\n\nRead the referenced issues themselves, not their references — follow a second hop only when\nthe first leaves a requirement genuinely unclear.\n\n**Stop and ask the user** if: a referenced issue can't be fetched; your brief depends on work\nthat a referenced issue has not landed yet; or the issue refers to a sibling **indirectly**\n(\"the next issue\", \"issue 5\", \"the issue that adds the store\") rather than by number — ask for\nthe real number instead of guessing which issue is meant.\n\n## Step 2 — Determine scope\n\nClassify the work and identify the affected module:\n\n- **JS-only** \u002F **PHP-only** \u002F **full-stack**.\n- Which module? JS lives in `assets\u002Fjs\u002F`, PHP in `includes\u002F`.\n\nWork on a feature branch off `develop`. Study an existing, similar feature before writing\nanything — match its structure and idioms.\n\n## Step 3 — Load the relevant convention docs\n\nRead **only** what the issue touches. Map:\n\n**JavaScript (`docs\u002Fcontext\u002Fjs\u002F`)**\n\n| If the issue involves… | Read |\n| --- | --- |\n| React components, PropTypes, imports, file headers | `component-conventions.md` |\n| Module file layout \u002F placement | `module-architecture.md` |\n| `@wordpress\u002Fdata` stores, selectors, resolvers, actions | `state-management.md` |\n| Custom hooks | `hooks.md` |\n| Reusable utilities | `utils.md` |\n| Dashboard widgets (context\u002Farea\u002Fwidget) | `widgets.md` |\n| Notifications \u002F banners | `notifications.md` |\n| Feature tours | `feature-tours.md` |\n| Feature flags | `feature-flags.md` |\n| `trackEvent` \u002F `trackEventOnce` | `event-tracking.md` |\n| JSDoc on utilities\u002Fhooks | `jsdoc.md` |\n| Storybook stories | `storybook.md` |\n| Jest tests | `tests.md` |\n\n**PHP (`docs\u002Fcontext\u002Fphp\u002F`)**\n\n| If the issue involves… | Read |\n| --- | --- |\n| A module class \u002F lifecycle \u002F interfaces | `module-architecture.md` |\n| Class\u002Fmethod\u002Ffile naming | `naming-conventions.md` |\n| Constructor DI | `dependency-injection.md` |\n| The `Context` service | `context-pattern.md` |\n| Settings \u002F module settings | `settings-management.md` |\n| `Options` \u002F `User_Options` \u002F `Transients` | `storage-patterns.md` |\n| REST routes | `rest-api.md` |\n| Traits \u002F horizontal reuse | `trait-composition.md` |\n| Script\u002Fstylesheet registration | `asset-management.md` |\n| Admin screens \u002F notices \u002F pointers | `admin-features.md` |\n| Prompts & dismissals | `prompts-and-dismissals.md` |\n| PHPUnit integration tests | `phpunit.md` |\n\n## Step 4 — Implement\n\nFollow the conventions you loaded in Step 3. In addition:\n\n- **Co-locate tests.** Add `*.test.js` \u002F `*.test.ts` \u002F `*.test.tsx` next to each\n  JS or Typescript source file; add `*Test.php` under the mirroring path in\n  `tests\u002Fphpunit\u002Fintegration\u002F`.\n- **Storybook.** Add a `*.stories.js` or `*.stories.tsx` next to any new UI component (and update VRT\n  reference images where relevant — see `tests\u002Fvrt\u002FREADME.md`).\n- **Styles.** Put SCSS under `assets\u002Fsass\u002F`.\n- **Feature flags.** Gate not-yet-shippable work behind a flag in `feature-flags.json`\n  (see `docs\u002Fcontext\u002Fjs\u002Ffeature-flags.md`).\n- Cover every Implementation Brief checkbox and Acceptance criterion. Implement the\n  **Test Coverage** items as real tests.\n\n## Step 5 — Self-review\n\nBefore verifying, review your own diff against `.agents\u002Fskills\u002Freview-pr\u002Freview-checklist.md`.\nFix every requirements gap and convention violation you find; address critical\u002Fhigh quality\nissues. The bar is: all acceptance criteria met, all relevant conventions followed, tests\nwritten and passing.\n\n## Step 6 — Verify\n\nRun, and fix anything that fails:\n\n- **Lint** — prefer scoping to the files you touched over the whole codebase:\n  - JS: `npm run lint:js:files -- \u003Cpath\u002Fto\u002Ffile.js>` (auto-fix the full codebase with\n    `npm run lint:js-fix`, or just your files with\n    `npm run lint:js:files -- --fix \u003Cpath\u002Fto\u002Ffile.js>`).\n  - PHP: `composer lint -- \u003Cpath\u002Fto\u002FFile.php>` (auto-fix with `composer lint-fix`).\n- **Build** — `npm run build:dev` when JS\u002Fasset changes are non-trivial.\n- **Tests** — run the **specific** test files you touched, not the whole suite:\n  - JS: `npm -w tests\u002Fjs run test:js -- \u003Cpath\u002Fto\u002Ffile.test.js>`\n  - PHP: `composer test -- --filter \u003CTestClassName>`\n- **Visual check (any change that affects rendering)** — for SCSS, layout, spacing,\n  alignment, or responsive rules, **render the change and look at it** before declaring it\n  done. Lint and build passing do **not** prove visual correctness, and a change that looks\n  like a trivial value tweak in the brief can still be visually wrong. Prefer the Storybook\n  story at the affected viewport(s); if no dev server is running, build a throwaway HTML\n  reproduction using the **real computed values** (typography from\n  `assets\u002Fsass\u002Fcomponents\u002Fglobal\u002F_googlesitekit-typography.scss`, breakpoints\u002Fsizes from\n  `assets\u002Fsass\u002Fconfig\u002F`) and open it in the browser. For responsive \u002F `@media` changes,\n  check **both sides** of every breakpoint you touch (the breakpoint variables, such as\n  `$bp-tablet`, are defined in `assets\u002Fsass\u002Fconfig\u002F_variables.scss`). A mobile-only rule is\n  invisible at desktop width, so look at the change at a width on each side. Confirm that\n  the VRT viewports in `tests\u002Fvrt\u002FREADME.md` cover both sides too. Re-check the exact state\n  described in the issue (e.g. the badge *next to the title*, not just the component in\n  isolation).\n- **VRT** — if you added\u002Fchanged a Storybook story, check just that story rather than\n  the full suite: `npm run test:visualtest -- --grep \"\u003Cstory label>\"`, and\n  `npm run test:visualapprove -- --grep \"\u003Cstory label>\"` to write the new reference\n  images (see `tests\u002Fvrt\u002FREADME.md`).\n\n## Step 7 — Wrap up\n\nSummarize what changed: files created\u002Fmodified\u002Fdeleted, how acceptance criteria are met,\nand verification results.\n\n---\n\n## Guardrails\n\n- **Local only.** Do **not** commit, push, or open a pull request unless the user explicitly\n  asks. The deliverable is a working, verified local change on the feature branch.\n- **No scope creep.** Implement what the brief specifies; flag anything underspecified rather\n  than inventing behavior. A referenced issue is context, never a work item — never implement\n  a sibling's brief because your issue mentions it.\n- **Commit messages** (only when asked to commit) must satisfy `bin\u002Fcheck-commit-msg.php`:\n  start with a capital letter, begin with a present-tense verb, contain more than one word,\n  and end with a full stop — e.g. `Track learn more about conversion tracking link.`\n",{"name":5,"description":44,"allowed-tools":45,"argument-hint":46},"Implement a Site Kit GitHub issue end-to-end from its implementation brief. Use when the user asks to implement, build, or work on a GitHub issue \u002F feature by number (e.g. \"implement issue #12345\", \"build the feature in issue 12345\", \"follow the implementation brief for #12345\") in the google\u002Fsite-kit-wp repo.\n","Bash, Read, Grep, Glob, Edit, Write","[issue-number]","develop","b38aae779c9c94c62659315c2c20fa08042e103b",".agents\u002Fskills\u002Fimplement-issue",391,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fsite-kit-wp","https:\u002F\u002Fsitekit.withgoogle.com","https:\u002F\u002Fgithub.com\u002Fgoogle","https:\u002F\u002Fopensource.google\u002F","Google ❤️ Open Source","2026-11-12 02:07:38",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add google\u002Fsite-kit-wp --skill implement-issue",{"tool":63,"command":64},"bunx","bunx skills add google\u002Fsite-kit-wp --skill implement-issue",{"tool":66,"command":67},"pnpm","pnpm dlx skills add google\u002Fsite-kit-wp --skill implement-issue","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fsite-kit-wp\u002Fblob\u002Fdevelop\u002F.agents\u002Fskills\u002Fimplement-issue\u002FSKILL.md",true,[],[72,81,89,98,107,112],{"skillNo":73,"name":74,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":39},"01M6991PXQEEZDSJJ0053EK3S8","write-issue-requirements","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fsite-kit-wp\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Fwrite-issue-requirements\u002FSKILL.md",[],[78,21,79,80],"requirements","write","write issue requirements",{"skillNo":82,"name":83,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":39},"01M6991NR5S6R94Q2Z6R5SAB1M","write-implementation-brief","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fsite-kit-wp\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Fwrite-implementation-brief\u002FSKILL.md",[],[87,79,36,88],"implementation","write implementation brief",{"skillNo":90,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":39},"01M6991MK67HC2KMG7MM2W8PZ1","write-context-doc","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fsite-kit-wp\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Fwrite-context-doc\u002FSKILL.md",[],[95,96,79,97],"doc","context","write context doc",{"skillNo":99,"name":100,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":39},"01M6991K9D80ZZPWRNZZQSHCMP","review-pr","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fsite-kit-wp\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Freview-pr\u002FSKILL.md",[],[104,105,106],"pr","review pr","review",{"skillNo":108,"name":5,"nameZh":6,"description":6,"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":111,"publishedAt":39},"01M6991J07Q5HB2ZCRD2JRWR7Z","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fsite-kit-wp\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Fimplement-issue\u002FSKILL.md",[],[21,20,19],{"skillNo":113,"name":114,"nameZh":6,"description":6,"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":117,"publishedAt":39},"01M6991GS58C967HP03TW1PMEJ","check-pr-failures","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fsite-kit-wp\u002Fblob\u002Fdevelop\u002F.claude\u002Fskills\u002Fcheck-pr-failures\u002FSKILL.md",[],[118,119,104],"check pr failures","check"]