[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JJ7DNKFGGE4SMHM97PVB1P":3,"skill-same:01M6JJ7DNKFGGE4SMHM97PVB1P":74},{"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":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M6JJ7DNKFGGE4SMHM97PVB1P","edit-spec",null,"Edit a vigiles .spec.ts to change a compiled instruction file (CLAUDE.md \u002F AGENTS.md) — add, modify, or remove a rule, section, command, or file pointer (including a request to add a \"key file\" — the keyFiles field is deprecated). Use whenever you need to change a CLAUDE.md\u002FAGENTS.md that carries a vigiles hash (edit the spec, never the artifact), including adding a new enforce()\u002Fcheck()\u002Fguidance() rule.","zernie\u002Fvigiles","zernie","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1765991?v=4","01M6JJ2Z99JQ4JRCMD45T5VJXZ","01M6JJ2ZDM1H6B9QVRBZFAN009",15,"MIT","https:\u002F\u002Fgithub.com\u002Fzernie\u002Fvigiles\u002Fblob\u002Fmain\u002Fskills\u002Fedit-spec\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"edit","edit spec","spec","remove","you","about","error","artifact","enforce","never","use","change","testing","read","command","check","Bash","file","error handling","update","2026-11-10 10:12:30",false,"---\nname: edit-spec\nallowed-tools: Read, Edit, Write, Glob, Grep, Bash\ndescription: Edit a vigiles .spec.ts to change a compiled instruction file (CLAUDE.md \u002F AGENTS.md) — add, modify, or remove a rule, section, command, or file pointer (including a request to add a \"key file\" — the keyFiles field is deprecated). Use whenever you need to change a CLAUDE.md\u002FAGENTS.md that carries a vigiles hash (edit the spec, never the artifact), including adding a new enforce()\u002Fcheck()\u002Fguidance() rule.\nargument-hint: \u003Cwhat to change — e.g., \"add a rule about error handling\" or \"update the testing section\">\n---\n\nEdit a `.spec.ts` file to update the project's instruction files. The spec is the source of truth — CLAUDE.md and AGENTS.md are compiled build artifacts that must not be edited directly.\n\n## Arguments\n\n$ARGUMENTS — What the user wants to change. Examples:\n\n- \"add a rule about always using the custom logger\"\n- \"update the architecture section\"\n- \"point the auth rule at src\u002Fservices\u002Fauth.ts\"\n- \"add npm run lint to commands\"\n- \"change the testing guidance\"\n\n## Instructions\n\n### Step 1: Find the Spec\n\nLook for spec files in the repo root:\n\n- `CLAUDE.md.spec.ts` — source for CLAUDE.md\n- `AGENTS.md.spec.ts` — source for AGENTS.md\n- Any `*.spec.ts` matching instruction files\n\nIf no spec exists: if there's a hand-written `CLAUDE.md`, suggest the\n`adopt-spec` skill; otherwise suggest `npx vigiles init` to scaffold one.\n\n### Step 2: Read and Understand the Spec\n\nRead the spec file. It's a TypeScript file that exports a `claude()` call with these fields:\n\n```typescript\nimport { claude, enforce, guidance, check, every } from \"vigiles\u002Fspec\";\n\nexport default claude({\n  \u002F\u002F Optional: output target (defaults to \"CLAUDE.md\")\n  target: \"CLAUDE.md\",\n  \u002F\u002F or multi-target:\n  \u002F\u002F target: [\"CLAUDE.md\", \"AGENTS.md\"],\n\n  \u002F\u002F Prose sections — become ## headings in compiled output\n  sections: {\n    positioning: \"What this project does...\",\n    architecture: \"How the codebase is structured...\",\n  },\n\n  \u002F\u002F (No `keyFiles` — deprecated; see \"A pointer to a file\" in Step 3.)\n\n  \u002F\u002F Commands verified against package.json\n  commands: {\n    \"npm run build\": \"Compile the project\",\n    \"npm test\": \"Run all tests\",\n  },\n\n  \u002F\u002F Rules — three types\n  rules: {\n    \u002F\u002F enforce() — backed by a linter rule, verified to exist AND be enabled\n    \"no-any\": enforce(\n      \"@typescript-eslint\u002Fno-explicit-any\",\n      \"Use unknown and narrow with type guards.\",\n    ),\n\n    \u002F\u002F check() — filesystem assertion run by vigiles\n    \"test-pairing\": check(\n      every(\"src\u002F**\u002F*.service.ts\").has(\"{name}.test.ts\"),\n      \"Every service must have tests.\",\n    ),\n\n    \u002F\u002F guidance() — prose only, no enforcement\n    \"research-first\": guidance(\"Google unfamiliar APIs before implementing.\"),\n  },\n});\n```\n\n### Step 3: Make the Changes\n\nBased on what the user asked for:\n\n**Adding a rule** (this absorbs the old `generate-rule` skill):\n\n- **Classify the rule** from the request:\n  - `enforce()` — a linter rule can back it. Check the project's linter configs\n    (ESLint, Ruff, Clippy, Pylint, RuboCop, Stylelint) for a matching rule; also\n    consider an architectural tool (ast-grep, Dependency Cruiser, Steiger). If\n    uncertain whether a rule exists, **ask the user** rather than guessing.\n  - `check()` — a filesystem structural convention (\"every X needs a Y\"). Only\n    for file-pairing; never for code content.\n  - `guidance()` — can't be mechanically enforced (subjective conventions,\n    process rules, migration context).\n- For `enforce()`: use the real linter rule name (e.g. `eslint\u002Fno-console`,\n  `@typescript-eslint\u002Fno-explicit-any`, `ruff\u002FT201`).\n- Add to the `rules` object with a kebab-case key derived from the intent,\n  preserving alphabetical order if the existing rules are alphabetical. Import\n  any new builders needed (e.g. `check` and `every` for the first `check()`).\n\n**Updating a section:**\n\n- Edit the string in `sections`. Sections are plain strings or tagged template literals with `file()`, `cmd()`, `ref()` for verified references\n- Do NOT add `#` or `##` headers inside sections — they break the document structure\n\n**Adding a command:**\n\n- Add to `commands`. The compiler verifies it against `package.json` scripts.\n- Keep the description to one line (aim for 120 characters, never exceed ~200):\n  the instruction file is loaded on EVERY request.\n\n**A pointer to a file (what used to be a \"key file\"):**\n\n- ? **Never add a `keyFiles` entry — not one, not even to a spec that already\n  has the field.** It is deprecated (`vigiles lint` reports it as\n  `deprecated-key-files`) and removed in the next major: it compiles a file\n  map into the instruction file loaded on every request, and the agent finds\n  files itself.\n- Asked to add a file? Place it by the first of these that fits, and say why:\n  1. the file's own header, the docs or the path already say it → add nothing;\n  2. a fact about that one file → write it in **the file's header comment**;\n  3. a rule an agent must follow while working in one folder → that folder's\n     **nested `CLAUDE.md`** (its own `\u003Cfolder>\u002FCLAUDE.md.spec.ts`, compiled);\n  4. only if nothing else would lead an agent there → a **one-line pointer**,\n     `${file(\"src\u002Fservices\u002Fauth.ts\")}` inside a `prose` section where the\n     decision that needs it is written — compile verifies it exists, exactly\n     as it verified a `keyFiles` path. (`guidance()` takes a plain string, so a\n     path typed there is not verified.)\n- **Opened a spec that still has `keyFiles`?** Propose removing it, in the same\n  reply: go through the entries with the same four steps (the full recipe is\n  `docs\u002Frules\u002Fdeprecated-key-files.md` in the vigiles repository; a path that\n  no longer exists is deleted) and show, per entry, where it goes and why.\n  Where each entry goes is the user's call; apply it once they confirm.\n\n### Step 4: Compile\n\nAfter editing the spec, run:\n\n```bash\nnpx vigiles compile\n```\n\nThis regenerates the compiled instruction file(s). Review the output for any errors:\n\n- `stale-file` — a `file()` (or deprecated `keyFiles`) path doesn't exist\n- `stale-command` — a command isn't in package.json\n- `invalid-rule` — a linter rule doesn't exist or is disabled\n- `section-has-header` — a section contains `#` headers (break into separate named sections)\n\n### Step 5: Verify\n\n```bash\nnpx vigiles lint\n```\n\nIf the vigiles plugin is installed (`\u002Fplugin marketplace add zernie\u002Fvigiles` then `\u002Fplugin install vigiles@vigiles`, or `npx vigiles init`), the PostToolUse hook recompiles automatically after you save the spec.\n\n## Important\n\n- **Do what's asked; don't silently escalate enforcement.** Add the rule the user asked for. If making it an `enforce()` would need a linter-config edit or a plugin install (a cost), or if it could fail a clean CI, **say so and let the user choose** — don't change linter config or flip on strict \u002F `workflow` gating on your own. A pure win (a rule that's already enabled) you can just apply. The `strengthen` skill owns `guidance()` → `enforce()` upgrades.\n- **Never edit CLAUDE.md or AGENTS.md directly** — they have a vigiles hash comment and are build artifacts\n- **The spec is TypeScript** — you get type checking, autocomplete, and verified references\n- **`enforce()` rules are verified** — the compiler checks the rule exists AND is enabled in your linter config\n- **Sections must not contain `#` or `##` headers** — use separate named sections instead\n","Edit a `.spec.ts` file to update the project's instruction files. The spec is the source of truth — CLAUDE.md and AGENTS.md are compiled build artifacts that must not be edited directly.\n\n## Arguments\n\n$ARGUMENTS — What the user wants to change. Examples:\n\n- \"add a rule about always using the custom logger\"\n- \"update the architecture section\"\n- \"point the auth rule at src\u002Fservices\u002Fauth.ts\"\n- \"add npm run lint to commands\"\n- \"change the testing guidance\"\n\n## Instructions\n\n### Step 1: Find the Spec\n\nLook for spec files in the repo root:\n\n- `CLAUDE.md.spec.ts` — source for CLAUDE.md\n- `AGENTS.md.spec.ts` — source for AGENTS.md\n- Any `*.spec.ts` matching instruction files\n\nIf no spec exists: if there's a hand-written `CLAUDE.md`, suggest the\n`adopt-spec` skill; otherwise suggest `npx vigiles init` to scaffold one.\n\n### Step 2: Read and Understand the Spec\n\nRead the spec file. It's a TypeScript file that exports a `claude()` call with these fields:\n\n```typescript\nimport { claude, enforce, guidance, check, every } from \"vigiles\u002Fspec\";\n\nexport default claude({\n  \u002F\u002F Optional: output target (defaults to \"CLAUDE.md\")\n  target: \"CLAUDE.md\",\n  \u002F\u002F or multi-target:\n  \u002F\u002F target: [\"CLAUDE.md\", \"AGENTS.md\"],\n\n  \u002F\u002F Prose sections — become ## headings in compiled output\n  sections: {\n    positioning: \"What this project does...\",\n    architecture: \"How the codebase is structured...\",\n  },\n\n  \u002F\u002F (No `keyFiles` — deprecated; see \"A pointer to a file\" in Step 3.)\n\n  \u002F\u002F Commands verified against package.json\n  commands: {\n    \"npm run build\": \"Compile the project\",\n    \"npm test\": \"Run all tests\",\n  },\n\n  \u002F\u002F Rules — three types\n  rules: {\n    \u002F\u002F enforce() — backed by a linter rule, verified to exist AND be enabled\n    \"no-any\": enforce(\n      \"@typescript-eslint\u002Fno-explicit-any\",\n      \"Use unknown and narrow with type guards.\",\n    ),\n\n    \u002F\u002F check() — filesystem assertion run by vigiles\n    \"test-pairing\": check(\n      every(\"src\u002F**\u002F*.service.ts\").has(\"{name}.test.ts\"),\n      \"Every service must have tests.\",\n    ),\n\n    \u002F\u002F guidance() — prose only, no enforcement\n    \"research-first\": guidance(\"Google unfamiliar APIs before implementing.\"),\n  },\n});\n```\n\n### Step 3: Make the Changes\n\nBased on what the user asked for:\n\n**Adding a rule** (this absorbs the old `generate-rule` skill):\n\n- **Classify the rule** from the request:\n  - `enforce()` — a linter rule can back it. Check the project's linter configs\n    (ESLint, Ruff, Clippy, Pylint, RuboCop, Stylelint) for a matching rule; also\n    consider an architectural tool (ast-grep, Dependency Cruiser, Steiger). If\n    uncertain whether a rule exists, **ask the user** rather than guessing.\n  - `check()` — a filesystem structural convention (\"every X needs a Y\"). Only\n    for file-pairing; never for code content.\n  - `guidance()` — can't be mechanically enforced (subjective conventions,\n    process rules, migration context).\n- For `enforce()`: use the real linter rule name (e.g. `eslint\u002Fno-console`,\n  `@typescript-eslint\u002Fno-explicit-any`, `ruff\u002FT201`).\n- Add to the `rules` object with a kebab-case key derived from the intent,\n  preserving alphabetical order if the existing rules are alphabetical. Import\n  any new builders needed (e.g. `check` and `every` for the first `check()`).\n\n**Updating a section:**\n\n- Edit the string in `sections`. Sections are plain strings or tagged template literals with `file()`, `cmd()`, `ref()` for verified references\n- Do NOT add `#` or `##` headers inside sections — they break the document structure\n\n**Adding a command:**\n\n- Add to `commands`. The compiler verifies it against `package.json` scripts.\n- Keep the description to one line (aim for 120 characters, never exceed ~200):\n  the instruction file is loaded on EVERY request.\n\n**A pointer to a file (what used to be a \"key file\"):**\n\n- ? **Never add a `keyFiles` entry — not one, not even to a spec that already\n  has the field.** It is deprecated (`vigiles lint` reports it as\n  `deprecated-key-files`) and removed in the next major: it compiles a file\n  map into the instruction file loaded on every request, and the agent finds\n  files itself.\n- Asked to add a file? Place it by the first of these that fits, and say why:\n  1. the file's own header, the docs or the path already say it → add nothing;\n  2. a fact about that one file → write it in **the file's header comment**;\n  3. a rule an agent must follow while working in one folder → that folder's\n     **nested `CLAUDE.md`** (its own `\u003Cfolder>\u002FCLAUDE.md.spec.ts`, compiled);\n  4. only if nothing else would lead an agent there → a **one-line pointer**,\n     `${file(\"src\u002Fservices\u002Fauth.ts\")}` inside a `prose` section where the\n     decision that needs it is written — compile verifies it exists, exactly\n     as it verified a `keyFiles` path. (`guidance()` takes a plain string, so a\n     path typed there is not verified.)\n- **Opened a spec that still has `keyFiles`?** Propose removing it, in the same\n  reply: go through the entries with the same four steps (the full recipe is\n  `docs\u002Frules\u002Fdeprecated-key-files.md` in the vigiles repository; a path that\n  no longer exists is deleted) and show, per entry, where it goes and why.\n  Where each entry goes is the user's call; apply it once they confirm.\n\n### Step 4: Compile\n\nAfter editing the spec, run:\n\n```bash\nnpx vigiles compile\n```\n\nThis regenerates the compiled instruction file(s). Review the output for any errors:\n\n- `stale-file` — a `file()` (or deprecated `keyFiles`) path doesn't exist\n- `stale-command` — a command isn't in package.json\n- `invalid-rule` — a linter rule doesn't exist or is disabled\n- `section-has-header` — a section contains `#` headers (break into separate named sections)\n\n### Step 5: Verify\n\n```bash\nnpx vigiles lint\n```\n\nIf the vigiles plugin is installed (`\u002Fplugin marketplace add zernie\u002Fvigiles` then `\u002Fplugin install vigiles@vigiles`, or `npx vigiles init`), the PostToolUse hook recompiles automatically after you save the spec.\n\n## Important\n\n- **Do what's asked; don't silently escalate enforcement.** Add the rule the user asked for. If making it an `enforce()` would need a linter-config edit or a plugin install (a cost), or if it could fail a clean CI, **say so and let the user choose** — don't change linter config or flip on strict \u002F `workflow` gating on your own. A pure win (a rule that's already enabled) you can just apply. The `strengthen` skill owns `guidance()` → `enforce()` upgrades.\n- **Never edit CLAUDE.md or AGENTS.md directly** — they have a vigiles hash comment and are build artifacts\n- **The spec is TypeScript** — you get type checking, autocomplete, and verified references\n- **`enforce()` rules are verified** — the compiler checks the rule exists AND is enabled in your linter config\n- **Sections must not contain `#` or `##` headers** — use separate named sections instead\n",{"name":5,"description":7,"allowed-tools":48,"argument-hint":49},"Read, Edit, Write, Glob, Grep, Bash","\u003Cwhat to change — e.g., \"add a rule about error handling\" or \"update the testing section\">","main","1a1de50f62f5c1093a46455488dcf6e8157c6182","skills\u002Fedit-spec",4,"https:\u002F\u002Fgithub.com\u002Fzernie\u002Fvigiles","https:\u002F\u002Fvigiles.sh","https:\u002F\u002Fgithub.com\u002Fzernie","https:\u002F\u002Fzernie.com?utm_source=github","Senior Fullstack Software Developer.\r\n\r\nRuby on Rails, React.JS\u002FRedux, TypeScript, Next.js.","2026-11-02 22:19:44",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add zernie\u002Fvigiles --skill edit-spec",{"tool":66,"command":67},"bunx","bunx skills add zernie\u002Fvigiles --skill edit-spec",{"tool":69,"command":70},"pnpm","pnpm dlx skills add zernie\u002Fvigiles --skill edit-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzernie\u002Fvigiles\u002Fblob\u002Fmain\u002Fskills\u002Fedit-spec\u002FSKILL.md",true,[],[75,99,120,153,182,206],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":82,"publishedAt":43},"01M6JJE6A64FF49TKDQ6F4JD0Q","wcag-audit-patterns","Conduct WCAG 2.2 accessibility audits with automated testing, manual verification, and remediation guidance. Use when auditing websites for accessibility, fixing WCAG violations, or implementing accessible design patterns.","https:\u002F\u002Fgithub.com\u002Fzernie\u002Fvigiles\u002Fblob\u002Fmain\u002Ftest\u002Fdogfood\u002Fwshobson-accessibility@cf6059d\u002Fskills\u002Fwcag-audit-patterns\u002FSKILL.md",[81],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[83,84,85,86,87,35,88,89,90,91,33,92,93,94,95,96,97,98],"audit","WCAG","wcag audit patterns","patterns","wcag audit","design","accessibility","verification","remediation","design patterns","guidance","automated testing","with","manual","implementing","for",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":106,"publishedAt":43},"01M6JJE24VZ3K0PRFHRJA4SNWG","screen-reader-testing","Test web applications with screen readers including VoiceOver, NVDA, and JAWS. Use when validating screen reader compatibility, debugging accessibility issues, or ensuring assistive technology support.","https:\u002F\u002Fgithub.com\u002Fzernie\u002Fvigiles\u002Fblob\u002Fmain\u002Ftest\u002Fdogfood\u002Fwshobson-accessibility@cf6059d\u002Fskills\u002Fscreen-reader-testing\u002FSKILL.md",[105],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[35,107,108,109,110,111,112,89,113,114,115,33,116,117,118,119,95],"reader","screen reader testing","screen","support","test","web","debugging","issues","applications","test web","voiceover","compatibility","technology",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":134,"publishedAt":43},"01M6JJDXJEEGWDJH531TH50Z2X","x-research","Searches X\u002FTwitter for real-time perspectives, dev discussions, product feedback, breaking news, and expert opinions using the X API v2. Provides search with engagement sorting, user profiles, thread fetching, watchlists, and result caching. Use when: (1) user says \"x research\", \"search x for\", \"search twitter for\", \"what are people saying about\", \"what's twitter saying\", \"check x for\", \"x search\", (2) user needs recent X discourse on a topic (library releases, API changes, product launches, industry events), (3) user wants to find what devs\u002Fexperts\u002Fcommunity thinks about a topic. NOT for: posting tweets or account management.","https:\u002F\u002Fgithub.com\u002Fzernie\u002Fvigiles\u002Fblob\u002Fmain\u002Ftest\u002Fdogfood\u002Ftrailofbits-skills-curated@6d05be4\u002Fplugins\u002Fx-research\u002Fskills\u002Fx-research\u002FSKILL.md",[126,129],{"categoryNo":127,"categoryName":128,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[135,136,137,138,139,140,39,141,142,36,143,144,145,146,147,148,149,150,151,152],"research","x research","api changes","product","search","api","x api","perspectives","write","releases","expert","community","search x","time","caching","people","sorting","experts",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":165,"publishedAt":43},"01M6JJDQQJE9RZWEN0E3FKB5KF","wooyun-legacy","Provides web vulnerability testing methodology distilled from 88,636 real-world cases from the WooYun vulnerability database (2010-2016). Use when performing penetration testing, security audits, code reviews for security flaws, or vulnerability research. Covers SQL injection, XSS, command execution, file upload, path traversal, unauthorized access, information disclosure, and business logic flaws.","https:\u002F\u002Fgithub.com\u002Fzernie\u002Fvigiles\u002Fblob\u002Fmain\u002Ftest\u002Fdogfood\u002Ftrailofbits-skills-curated@6d05be4\u002Fplugins\u002Fwooyun-legacy\u002Fskills\u002Fwooyun-legacy\u002FSKILL.md",[159,160,163,164],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":161,"categoryName":162,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":127,"categoryName":128,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},[166,167,35,168,169,170,171,172,173,174,39,175,37,36,176,177,178,179,180,181],"Legacy","wooyun legacy","security","sql","code","database","injection","xss","vulnerability","access","Performing Penetration Testing","world","penetration","information","reviews","path",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":191,"publishedAt":43},"01M6JJDJRQ8D4VEVYB2YS0ZG7G","skill-extractor","Extracts reusable skills from work sessions. Use when: (1) a non-obvious problem was solved worth preserving, (2) a pattern was discovered that would help future sessions, (3) a workaround or debugging technique needs documentation. Manual invocation only via \u002Fskill-extractor command - no automatic triggers or hooks.","https:\u002F\u002Fgithub.com\u002Fzernie\u002Fvigiles\u002Fblob\u002Fmain\u002Ftest\u002Fdogfood\u002Ftrailofbits-skills-curated@6d05be4\u002Fplugins\u002Fskill-extractor\u002Fskills\u002Fskill-extractor\u002FSKILL.md",[188],{"categoryNo":189,"categoryName":190,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[192,193,194,113,195,196,197,37,36,143,33,198,199,200,201,202,203,204,96,205],"skill extractor","sessions","documentation","help","grep","work","only","hooks","reusable","pattern","triggers","problem","via","websearch",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":212,"publishedAt":43},"01M6JJDE8FBAP7YD2Y3ES050JQ","security-awareness","Teaches agents to recognize and avoid security threats during normal activity. Covers phishing detection, credential protection, domain verification, and social engineering defense. Use when building or operating agents that access email, credential vaults, web browsers, or sensitive data.","https:\u002F\u002Fgithub.com\u002Fzernie\u002Fvigiles\u002Fblob\u002Fmain\u002Ftest\u002Fdogfood\u002Ftrailofbits-skills-curated@6d05be4\u002Fplugins\u002Fsecurity-awareness\u002Fskills\u002Fsecurity-awareness\u002FSKILL.md",[],[168,213,214,112,90,215,216,175,196,36,217,33,218,219,220,221,222,223,224,225],"awareness","security awareness","email","phishing","webfetch","protection","social","social engineering","domain","vaults","operating","activity","phishing detection"]