[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C0JF777CCJ44ZYXP9F45AE":3,"skill-same:01M6C0JF777CCJ44ZYXP9F45AE":63},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":39,"ownerHtmlUrl":40,"ownerBlogUrl":41,"ownerDescription":9,"updatedAt":42,"install":43,"resources":56},"01M6C0JF777CCJ44ZYXP9F45AE","ci-prep",null,"Prepares the current branch for CI by running the exact same steps locally and fixing issues. If CI is already failing, fetches the GH Actions logs first to diagnose. Use before pushing, when CI is red, or when the user says \"fix ci\".","Nimblesite\u002FDataProvider","Nimblesite","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F178527684?v=4","01M6C0JCTZP0TRD8TD5ASTA0HY","01M6C0JD0KFR7H2S3JVJ0D031N",68,"MIT","https:\u002F\u002Fgithub.com\u002FNimblesite\u002FDataProvider\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fci-prep\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27],"ci","ci prep","fix ci","diagnose","issues","logs","actions","first","gh","branch","2026-11-10 10:12:30",false,"---\nname: ci-prep\ndescription: Prepares the current branch for CI by running the exact same steps locally and fixing issues. If CI is already failing, fetches the GH Actions logs first to diagnose. Use before pushing, when CI is red, or when the user says \"fix ci\".\nargument-hint: \"[--failing] [optional job name to focus on]\"\n---\n\u003C!-- agent-pmo:795a9c2 -->\n\n# CI Prep\n\nPrepare the current state for CI. If CI is already failing, fetch and analyze the logs first.\n\n## Arguments\n\n- `--failing` — Indicates a GitHub Actions run is already failing. When present, you MUST execute **Step 1** before doing anything else.\n- Any other argument is treated as a job name to focus on (but all failures are still reported).\n\nIf `--failing` is NOT passed, skip directly to **Step 2**.\n\n## Step 1 — Fetch failed CI logs (only when `--failing`)\n\nYou MUST do this before any other work.\n\n```bash\nBRANCH=$(git branch --show-current)\nPR_JSON=$(gh pr list --head \"$BRANCH\" --state open --json number,title,url --limit 1)\n```\n\nIf the JSON array is empty, **stop immediately**:\n> No open PR found for branch `$BRANCH`. Create a PR first.\n\nOtherwise fetch the logs:\n\n```bash\nPR_NUMBER=$(echo \"$PR_JSON\" | jq -r '.[0].number')\ngh pr checks \"$PR_NUMBER\"\nRUN_ID=$(gh run list --branch \"$BRANCH\" --limit 1 --json databaseId --jq '.[0].databaseId')\ngh run view \"$RUN_ID\"\ngh run view \"$RUN_ID\" --log-failed\n```\n\nRead **every line** of `--log-failed` output. For each failure note the exact file, line, and error message. If a job name argument was provided, prioritize that job but still report all failures.\n\n## Step 2 — Analyze the CI workflow\n\n1. Find the CI workflow file. Look in `.github\u002Fworkflows\u002F` for `ci.yml`, `build.yml`, `test.yml`, `checks.yml`, `main.yml`, `pull_request.yml`, or any workflow triggered on `pull_request` or `push`.\n2. Read the workflow file completely. Parse every job and every step.\n3. Extract the ordered list of commands the CI actually runs. In a spec-compliant repo this is `make lint → make test → make build` (REPO-STANDARDS-SPEC [MAKE-TARGETS]), but the actual CI may use `npm`, `cargo`, `dotnet`, raw shell commands, or anything else. Extract what is *actually there*.\n4. Note any environment variables, matrix strategies, or conditional steps that affect execution.\n\n**Do NOT assume the steps are `make lint`, `make test`, `make build`.** The actual CI may run different commands, in a different order. Extract what the CI *actually does*. If you find extra targets beyond the 7 in [MAKE-TARGETS] (e.g. `make fmt-check`, `make coverage-check`), flag them in your final report — they should be consolidated by the agent-pmo skill.\n\n### Release workflow blocker scan\n\nIf `.github\u002Fworkflows\u002Frelease.yml` exists, scan it before broad local CI. These are critical blockers\nand must be fixed before release work is considered CI-ready:\n\n- Tag-triggered jobs checking out `ref: main` instead of the tagged SHA.\n- Any `git commit`, `git push`, branch mutation, or tag mutation during release.\n- Version bump commits after the tag already exists.\n- Ad hoc `sed` version stamping of structured files instead of a first-class stamper\u002Fbuild input.\n- Missing tests that pass a test version into the same stamper used by release.\n- Native VSIX releases without Node `22.x`, `npx vsce package --target \u003CvsceTarget>`, one VSIX per\n  target, target-suffixed filenames, and package-content verification.\n- VS Code native-binary activation that reads or mutates PATH, uses package-manager\u002Fglobal installs\n  as normal startup sources, or copies bundled VSIX binaries after install.\n\n## Step 3 — Run each CI step locally, in order\n\nWork through failures in this priority order:\n\n1. **Formatting** — run auto-formatters first to clear noise\n2. **Compilation errors** — must compile before lint\u002Ftest\n3. **Lint violations** — fix the code pattern\n4. **Runtime \u002F test failures** — fix source code to satisfy the test\n\nFor each command extracted from the CI workflow:\n\n1. Run the command exactly as CI would run it (adjusting only for local environment differences like not needing `actions\u002Fcheckout`).\n2. If the step fails, **stop and fix the issues** before continuing to the next step.\n3. After fixing, re-run the same step to confirm it passes.\n4. Move to the next step only after the current one succeeds.\n\n### Hard constraints\n\n- **NEVER modify test files unless you are absolutely certain that the test is INCORRECT** — fix the source code, not the tests\n- **NEVER add suppressions** (`#[allow(...)]`, `\u002F\u002F eslint-disable`, `#pragma warning disable`)\n- **NEVER use `any` in TypeScript** to silence type errors\n- **NEVER delete or ignore failing tests**\n- **NEVER remove assertions**\n\nIf stuck on the same failure after 5 attempts, ask the user for help.\n\n## Step 4 — Report\n\n- List every step that was run and its result (pass\u002Ffail\u002Ffixed).\n- If any step could not be fixed, report what failed and why.\n- Confirm whether the branch is ready to push.\n\n## Step 5 — Remote CI follow-up (only when `--failing`)\n\nOnce all CI steps pass locally:\n\n1. Report the local fixes and exact commands that now pass.\n2. Do not commit or push. The user owns source-control writes.\n3. If the user pushes, monitor the new run until completion or failure.\n4. Upon failure, go back to Step 1.\n\n## Rules\n\n- **Always read the CI workflow first.** Never assume what commands CI runs.\n- Do not commit or push from this skill.\n- Fix issues found in each step before moving to the next\n- Never skip steps or suppress errors\n- If the CI workflow has multiple jobs, run all of them (respecting dependency order)\n- Skip steps that are CI-infrastructure-only (checkout, setup-node\u002Fpython\u002Frust actions, cache steps, artifact uploads) — focus on the actual build\u002Ftest\u002Flint commands\n\n## Success criteria\n\n- Every command that CI runs has been executed locally and passed\n- All fixes are applied to the working tree\n- The CI passes successfully (if you are correcting and existing failure)\n","\u003C!-- agent-pmo:795a9c2 -->\n\n# CI Prep\n\nPrepare the current state for CI. If CI is already failing, fetch and analyze the logs first.\n\n## Arguments\n\n- `--failing` — Indicates a GitHub Actions run is already failing. When present, you MUST execute **Step 1** before doing anything else.\n- Any other argument is treated as a job name to focus on (but all failures are still reported).\n\nIf `--failing` is NOT passed, skip directly to **Step 2**.\n\n## Step 1 — Fetch failed CI logs (only when `--failing`)\n\nYou MUST do this before any other work.\n\n```bash\nBRANCH=$(git branch --show-current)\nPR_JSON=$(gh pr list --head \"$BRANCH\" --state open --json number,title,url --limit 1)\n```\n\nIf the JSON array is empty, **stop immediately**:\n> No open PR found for branch `$BRANCH`. Create a PR first.\n\nOtherwise fetch the logs:\n\n```bash\nPR_NUMBER=$(echo \"$PR_JSON\" | jq -r '.[0].number')\ngh pr checks \"$PR_NUMBER\"\nRUN_ID=$(gh run list --branch \"$BRANCH\" --limit 1 --json databaseId --jq '.[0].databaseId')\ngh run view \"$RUN_ID\"\ngh run view \"$RUN_ID\" --log-failed\n```\n\nRead **every line** of `--log-failed` output. For each failure note the exact file, line, and error message. If a job name argument was provided, prioritize that job but still report all failures.\n\n## Step 2 — Analyze the CI workflow\n\n1. Find the CI workflow file. Look in `.github\u002Fworkflows\u002F` for `ci.yml`, `build.yml`, `test.yml`, `checks.yml`, `main.yml`, `pull_request.yml`, or any workflow triggered on `pull_request` or `push`.\n2. Read the workflow file completely. Parse every job and every step.\n3. Extract the ordered list of commands the CI actually runs. In a spec-compliant repo this is `make lint → make test → make build` (REPO-STANDARDS-SPEC [MAKE-TARGETS]), but the actual CI may use `npm`, `cargo`, `dotnet`, raw shell commands, or anything else. Extract what is *actually there*.\n4. Note any environment variables, matrix strategies, or conditional steps that affect execution.\n\n**Do NOT assume the steps are `make lint`, `make test`, `make build`.** The actual CI may run different commands, in a different order. Extract what the CI *actually does*. If you find extra targets beyond the 7 in [MAKE-TARGETS] (e.g. `make fmt-check`, `make coverage-check`), flag them in your final report — they should be consolidated by the agent-pmo skill.\n\n### Release workflow blocker scan\n\nIf `.github\u002Fworkflows\u002Frelease.yml` exists, scan it before broad local CI. These are critical blockers\nand must be fixed before release work is considered CI-ready:\n\n- Tag-triggered jobs checking out `ref: main` instead of the tagged SHA.\n- Any `git commit`, `git push`, branch mutation, or tag mutation during release.\n- Version bump commits after the tag already exists.\n- Ad hoc `sed` version stamping of structured files instead of a first-class stamper\u002Fbuild input.\n- Missing tests that pass a test version into the same stamper used by release.\n- Native VSIX releases without Node `22.x`, `npx vsce package --target \u003CvsceTarget>`, one VSIX per\n  target, target-suffixed filenames, and package-content verification.\n- VS Code native-binary activation that reads or mutates PATH, uses package-manager\u002Fglobal installs\n  as normal startup sources, or copies bundled VSIX binaries after install.\n\n## Step 3 — Run each CI step locally, in order\n\nWork through failures in this priority order:\n\n1. **Formatting** — run auto-formatters first to clear noise\n2. **Compilation errors** — must compile before lint\u002Ftest\n3. **Lint violations** — fix the code pattern\n4. **Runtime \u002F test failures** — fix source code to satisfy the test\n\nFor each command extracted from the CI workflow:\n\n1. Run the command exactly as CI would run it (adjusting only for local environment differences like not needing `actions\u002Fcheckout`).\n2. If the step fails, **stop and fix the issues** before continuing to the next step.\n3. After fixing, re-run the same step to confirm it passes.\n4. Move to the next step only after the current one succeeds.\n\n### Hard constraints\n\n- **NEVER modify test files unless you are absolutely certain that the test is INCORRECT** — fix the source code, not the tests\n- **NEVER add suppressions** (`#[allow(...)]`, `\u002F\u002F eslint-disable`, `#pragma warning disable`)\n- **NEVER use `any` in TypeScript** to silence type errors\n- **NEVER delete or ignore failing tests**\n- **NEVER remove assertions**\n\nIf stuck on the same failure after 5 attempts, ask the user for help.\n\n## Step 4 — Report\n\n- List every step that was run and its result (pass\u002Ffail\u002Ffixed).\n- If any step could not be fixed, report what failed and why.\n- Confirm whether the branch is ready to push.\n\n## Step 5 — Remote CI follow-up (only when `--failing`)\n\nOnce all CI steps pass locally:\n\n1. Report the local fixes and exact commands that now pass.\n2. Do not commit or push. The user owns source-control writes.\n3. If the user pushes, monitor the new run until completion or failure.\n4. Upon failure, go back to Step 1.\n\n## Rules\n\n- **Always read the CI workflow first.** Never assume what commands CI runs.\n- Do not commit or push from this skill.\n- Fix issues found in each step before moving to the next\n- Never skip steps or suppress errors\n- If the CI workflow has multiple jobs, run all of them (respecting dependency order)\n- Skip steps that are CI-infrastructure-only (checkout, setup-node\u002Fpython\u002Frust actions, cache steps, artifact uploads) — focus on the actual build\u002Ftest\u002Flint commands\n\n## Success criteria\n\n- Every command that CI runs has been executed locally and passed\n- All fixes are applied to the working tree\n- The CI passes successfully (if you are correcting and existing failure)\n",{"name":5,"description":7,"argument-hint":33},"[--failing] [optional job name to focus on]","main","52a3bb1b0b693dd04699b77cbfb8dfbe4befdec0",".agents\u002Fskills\u002Fci-prep",4,"https:\u002F\u002Fgithub.com\u002FNimblesite\u002FDataProvider","https:\u002F\u002Flql.dev\u002F","https:\u002F\u002Fgithub.com\u002FNimblesite","https:\u002F\u002Fwww.nimblesite.co\u002F","2026-11-03 10:27:35",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add Nimblesite\u002FDataProvider --skill ci-prep",{"tool":49,"command":50},"bunx","bunx skills add Nimblesite\u002FDataProvider --skill ci-prep",{"tool":52,"command":53},"pnpm","pnpm dlx skills add Nimblesite\u002FDataProvider --skill ci-prep","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNimblesite\u002FDataProvider\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fci-prep\u002FSKILL.md",true,[57],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"reference.md","REFERENCE","参考文档",1795,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-design-philosophy\u002Freference.md",[64,92,106,119,133,146],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":80,"publishedAt":28},"01M6C0KDKYAKZ8W4KCZZCGW4YN","website-audit","Audits a website for SEO, AI search performance, structured data, mobile usability, broken links, and social media cards. Fixes issues found. Use when the user mentions \"audit website\", \"SEO\", \"fix search ranking\", \"AI search\", \"structured data\", \"social media cards\", or \"website performance\".","https:\u002F\u002Fgithub.com\u002FNimblesite\u002FDataProvider\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwebsite-audit\u002FSKILL.md",[70,75],{"categoryNo":71,"categoryName":72,"taxonomyType":73,"taxonomyTypeDesc":74},"01JBSEEDCAT000000000000019","营销推广","SCENARIO","使用场景",{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000035","市场营销","PROFESSION","适用职业",[81,82,83,84,85,86,22,87,88,89,90,91],"website audit","audit","website","search","structured data","performance","data","seo","Media","social media","broken",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":28},"01M6C0KBQHTHM3Q8FTDZHVHHPQ","upgrade-packages","Upgrade all dependencies\u002Fpackages to their latest versions for the detected language(s). Use when the user says \"upgrade packages\", \"update dependencies\", \"bump versions\", \"update packages\", or \"upgrade deps\".","https:\u002F\u002Fgithub.com\u002FNimblesite\u002FDataProvider\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fupgrade-packages\u002FSKILL.md",[],[99,100,101,102,103,104,105],"upgrade packages","packages","update","package","deps","check","update dependencies",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":28},"01M6C0K9V6V43P869Q52DGDECN","submit-pr","Creates a pull request with a well-structured description after verifying CI passes. Use when the user asks to submit, create, or open a pull request.","https:\u002F\u002Fgithub.com\u002FNimblesite\u002FDataProvider\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsubmit-pr\u002FSKILL.md",[],[113,114,115,116,117,18,118],"submit pr","pr","pull request","create","pull","open",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":28},"01M6C0K7RTZMBVC01CZ6HKBP1C","spec-check","Audit spec\u002Fplan documents against the codebase. Ensures every spec section has implementing code, tests, and matching logic. Use when the user says \"check specs\", \"spec audit\", or \"verify specs\".","https:\u002F\u002Fgithub.com\u002FNimblesite\u002FDataProvider\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fspec-check\u002FSKILL.md",[],[126,104,127,128,129,130,82,131,132],"spec check","spec","documents","implementing code","code","verify","plan",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":28},"01M6C0K5HF3W1KN1J6K4PAQZ8V","fix-bug","Fix a bug using test-driven development. Use when the user reports a bug, describes unexpected behavior, wants to fix a defect, or says something is broken. Enforces a strict test-first workflow where a failing test must be written and verified before any fix is attempted.","https:\u002F\u002Fgithub.com\u002FNimblesite\u002FDataProvider\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffix-bug\u002FSKILL.md",[],[140,25,141,142,91,143,144,145],"fix bug","grep","Bash","development","test","workflow",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":155,"publishedAt":28},"01M6C0K3SD41A9H3E3NEYFXK9P","code-dedup","Searches for duplicate code, duplicate tests, and dead code, then safely merges or removes them. Use when the user says \"deduplicate\", \"find duplicates\", \"remove dead code\", \"DRY up\", or \"code dedup\". Requires test coverage — refuses to touch untested code.","https:\u002F\u002Fgithub.com\u002FNimblesite\u002FDataProvider\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcode-dedup\u002FSKILL.md",[152],{"categoryNo":153,"categoryName":154,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000030","开发工程师",[130,156,157,158,159,144],"code dedup","find","dead code","deduplicate"]