[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JJ71H4AAWDPPHXM3CYA8W7":3,"skill-same:01M6JJ71H4AAWDPPHXM3CYA8W7":59},{"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":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":41,"ownerHtmlUrl":42,"ownerBlogUrl":43,"ownerDescription":44,"updatedAt":45,"install":46,"resources":58},"01M6JJ71H4AAWDPPHXM3CYA8W7","adopt-spec",null,"Adopt a typed .spec.ts for an existing hand-written CLAUDE.md — start from the file you already have, non-destructively","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\u002Fadopt-spec\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28],"spec","adopt","adopt spec","file","start","you","true","hand","path","for","Existing","2026-11-10 10:12:30",false,"---\nname: adopt-spec\ndescription: Adopt a typed .spec.ts for an existing hand-written CLAUDE.md — start from the file you already have, non-destructively\ndisable-model-invocation: true\nargument-hint: \u003Cpath to CLAUDE.md, defaults to CLAUDE.md>\n---\n\nStart a typed `CLAUDE.md.spec.ts` from an existing hand-written CLAUDE.md (or AGENTS.md). This is the non-destructive adoption path — you keep your existing instruction file as the starting point and get type safety going forward.\n\n## Adoption rules\n\nAdoption is the **safe, faithful on-ramp — never an upgrade in disguise.** These are non-negotiable:\n\n- **Faithful.** Preserve every rule, command, and prose section as-is. Invent nothing — the spec must compile back to ~the user's existing file. The one exception is a file map (\"Key Files\"): never emit the deprecated `keyFiles` field — see the guideline under Step 3.\n- **Non-destructive.** Never edit the original `CLAUDE.md` \u002F `AGENTS.md`. Only write the new `.spec.ts`. Never auto-`compile` over the file — switching it to spec-managed is a separate, explicit step the user runs with a diff to review.\n- **Don't escalate enforcement.** Keep `guidance()` as `guidance()`. Upgrading to `enforce()` has a cost (config\u002Fplugins, possible false positives) and is a separate opt-in step — the `strengthen` skill. Adoption is **not** turning on strict \u002F `workflow` gating.\n- **Reversible.** `vigiles eject \u003Cfile>` hands the file back as plain hand-owned markdown anytime — it's never a one-way door. Tell the user this.\n- **Ask before writing.** Present the generated spec and a conversion summary first; write only on the user's yes.\n- **A lighter touch exists.** For no spec at all, inline `\u003C!-- vigiles:enforce ... -->` comments are verified by `vigiles lint` with the same engine.\n\n## Instructions\n\n### Step 1: Read the Existing File\n\nRead the target instruction file (default: `CLAUDE.md` in the repo root). If the user specified a path, use that.\n\nAlso check if vigiles is installed: look for `vigiles` in `package.json` devDependencies. If not, suggest:\n\n```bash\nnpm install -D vigiles\n```\n\n### Step 2: Parse the Structure\n\nIdentify these sections in the markdown:\n\n- **Commands** — lines like `` `npm run build` — description `` or ``- `command` — description``\n- **A file map (\"Key Files\")** — lines like `` `src\u002Ffoo.ts` — description `` listing important files. Never becomes `keyFiles` (deprecated); see the guideline under Step 3\n- **Rules** — `###` headings with `**Enforced by:**`, `**Claimed (unverified):**` or `**Guidance only**` annotations\n- **Prose sections** — everything else (positioning, architecture, principles, etc.)\n\nFor each rule, classify it:\n\n- Has `**Enforced by:** \\`linter\u002Frule\\``→`enforce(\"linter\u002Frule\", \"why\")`\n- Has `**Claimed (unverified):** \\`linter\u002Frule\\``→`enforce(\"linter\u002Frule\", \"why\")` too — the last compile could not verify it; the next one will say why\n- Has `**Enforced by:** \\`code-review\\``or similar non-linter →`guidance(\"...\")`\n- Has `**Guidance only**` → `guidance(\"...\")`\n- Has no annotation → mark as TODO for the user to classify\n\n### Step 3: Generate the Spec File\n\nCreate `CLAUDE.md.spec.ts` (or the appropriate name based on the source file) with this structure:\n\n```typescript\nimport {\n  claude,\n  enforce,\n  guidance,\n  file,\n  cmd,\n  ref,\n  instructions,\n} from \"vigiles\u002Fspec\";\n\nexport default claude({\n  sections: {\n    \u002F\u002F Prose sections here\n  },\n\n  \u002F\u002F No `keyFiles`: the field is deprecated (removed next major). A \"Key Files\"\n  \u002F\u002F list in the original file is NOT carried over as a map — see the\n  \u002F\u002F guideline below.\n\n  commands: {\n    \u002F\u002F Commands here\n  },\n\n  rules: {\n    \u002F\u002F Rules here\n  },\n});\n```\n\n**Important guidelines:**\n\n- Use `file()` refs in sections where file paths appear in backticks — this enables stale reference detection\n- ? **Never emit `keyFiles`.** The field is deprecated and removed in the next major (`vigiles lint` warns as `deprecated-key-files`). For a \"Key Files\" \u002F file-map section in the original, apply the migration recipe (`docs\u002Frules\u002Fdeprecated-key-files.md` in the vigiles repository) and show the user, per entry, where it goes — the first that fits: (1) the file's header, the docs or the path already say it (or the path no longer exists) → delete it; (2) a fact about that one file → that file's header comment; (3) a rule for working in one folder → that folder's nested `CLAUDE.md` (its own `\u003Cfolder>\u002FCLAUDE.md.spec.ts`); (4) nothing else would lead an agent to the file → a one-line `file()` pointer in the section where the decision that needs it is written. Where each entry goes is the user's call; that the map does not become `keyFiles` is not. Until they decide, carry the list over as a plain prose section so adoption stays faithful\n- Use `cmd()` refs for any `npm run` commands mentioned in sections\n- Convert `**Enforced by:** \\`code-review\\``rules to`guidance()` — code review is not a mechanical enforcement\n- For rules with no annotation, add a `\u002F\u002F TODO: classify as enforce() or guidance()` comment\n- Keep rule IDs as kebab-case versions of the heading text\n- Preserve the `**Why:**` text as the second argument to `enforce()` or `guidance()`\n- If sections reference other files or skills, use `ref()` for cross-references\n\n### Step 4: Verify the Spec Compiles\n\nRun:\n\n```bash\nnpm run build\nnpx vigiles compile CLAUDE.md.spec.ts\n```\n\nCompare the compiled output against the original file. Key differences are expected (formatting, section ordering), but all rules, commands, and prose content should be preserved (a file map is the exception — see the `keyFiles` guideline above).\n\n### Step 5: Present the Result\n\nShow the user:\n\n1. The generated spec file\n2. How many rules were converted (enforce vs guidance vs TODO)\n3. How many file\u002Fcmd refs were added for stale reference detection\n4. The command to compile: `npx vigiles compile`\n5. The command to verify: `npx vigiles lint`\n\nAsk if they want you to write the file. If yes, also suggest adding to `.gitignore` or updating CI to run `vigiles compile` and `vigiles lint`.\n\n### Step 6: Optional — Set Up CI\n\nIf the user wants CI integration, suggest adding to their GitHub Actions workflow:\n\n```yaml\n- name: Compile specs\n  run: npx vigiles compile\n- name: Verify references + integrity\n  run: npx vigiles lint\n```\n\nOr using the vigiles GitHub Action:\n\n```yaml\n- uses: zernie\u002Fvigiles@v1\n  with:\n    command: lint\n```\n","Start a typed `CLAUDE.md.spec.ts` from an existing hand-written CLAUDE.md (or AGENTS.md). This is the non-destructive adoption path — you keep your existing instruction file as the starting point and get type safety going forward.\n\n## Adoption rules\n\nAdoption is the **safe, faithful on-ramp — never an upgrade in disguise.** These are non-negotiable:\n\n- **Faithful.** Preserve every rule, command, and prose section as-is. Invent nothing — the spec must compile back to ~the user's existing file. The one exception is a file map (\"Key Files\"): never emit the deprecated `keyFiles` field — see the guideline under Step 3.\n- **Non-destructive.** Never edit the original `CLAUDE.md` \u002F `AGENTS.md`. Only write the new `.spec.ts`. Never auto-`compile` over the file — switching it to spec-managed is a separate, explicit step the user runs with a diff to review.\n- **Don't escalate enforcement.** Keep `guidance()` as `guidance()`. Upgrading to `enforce()` has a cost (config\u002Fplugins, possible false positives) and is a separate opt-in step — the `strengthen` skill. Adoption is **not** turning on strict \u002F `workflow` gating.\n- **Reversible.** `vigiles eject \u003Cfile>` hands the file back as plain hand-owned markdown anytime — it's never a one-way door. Tell the user this.\n- **Ask before writing.** Present the generated spec and a conversion summary first; write only on the user's yes.\n- **A lighter touch exists.** For no spec at all, inline `\u003C!-- vigiles:enforce ... -->` comments are verified by `vigiles lint` with the same engine.\n\n## Instructions\n\n### Step 1: Read the Existing File\n\nRead the target instruction file (default: `CLAUDE.md` in the repo root). If the user specified a path, use that.\n\nAlso check if vigiles is installed: look for `vigiles` in `package.json` devDependencies. If not, suggest:\n\n```bash\nnpm install -D vigiles\n```\n\n### Step 2: Parse the Structure\n\nIdentify these sections in the markdown:\n\n- **Commands** — lines like `` `npm run build` — description `` or ``- `command` — description``\n- **A file map (\"Key Files\")** — lines like `` `src\u002Ffoo.ts` — description `` listing important files. Never becomes `keyFiles` (deprecated); see the guideline under Step 3\n- **Rules** — `###` headings with `**Enforced by:**`, `**Claimed (unverified):**` or `**Guidance only**` annotations\n- **Prose sections** — everything else (positioning, architecture, principles, etc.)\n\nFor each rule, classify it:\n\n- Has `**Enforced by:** \\`linter\u002Frule\\``→`enforce(\"linter\u002Frule\", \"why\")`\n- Has `**Claimed (unverified):** \\`linter\u002Frule\\``→`enforce(\"linter\u002Frule\", \"why\")` too — the last compile could not verify it; the next one will say why\n- Has `**Enforced by:** \\`code-review\\``or similar non-linter →`guidance(\"...\")`\n- Has `**Guidance only**` → `guidance(\"...\")`\n- Has no annotation → mark as TODO for the user to classify\n\n### Step 3: Generate the Spec File\n\nCreate `CLAUDE.md.spec.ts` (or the appropriate name based on the source file) with this structure:\n\n```typescript\nimport {\n  claude,\n  enforce,\n  guidance,\n  file,\n  cmd,\n  ref,\n  instructions,\n} from \"vigiles\u002Fspec\";\n\nexport default claude({\n  sections: {\n    \u002F\u002F Prose sections here\n  },\n\n  \u002F\u002F No `keyFiles`: the field is deprecated (removed next major). A \"Key Files\"\n  \u002F\u002F list in the original file is NOT carried over as a map — see the\n  \u002F\u002F guideline below.\n\n  commands: {\n    \u002F\u002F Commands here\n  },\n\n  rules: {\n    \u002F\u002F Rules here\n  },\n});\n```\n\n**Important guidelines:**\n\n- Use `file()` refs in sections where file paths appear in backticks — this enables stale reference detection\n- ? **Never emit `keyFiles`.** The field is deprecated and removed in the next major (`vigiles lint` warns as `deprecated-key-files`). For a \"Key Files\" \u002F file-map section in the original, apply the migration recipe (`docs\u002Frules\u002Fdeprecated-key-files.md` in the vigiles repository) and show the user, per entry, where it goes — the first that fits: (1) the file's header, the docs or the path already say it (or the path no longer exists) → delete it; (2) a fact about that one file → that file's header comment; (3) a rule for working in one folder → that folder's nested `CLAUDE.md` (its own `\u003Cfolder>\u002FCLAUDE.md.spec.ts`); (4) nothing else would lead an agent to the file → a one-line `file()` pointer in the section where the decision that needs it is written. Where each entry goes is the user's call; that the map does not become `keyFiles` is not. Until they decide, carry the list over as a plain prose section so adoption stays faithful\n- Use `cmd()` refs for any `npm run` commands mentioned in sections\n- Convert `**Enforced by:** \\`code-review\\``rules to`guidance()` — code review is not a mechanical enforcement\n- For rules with no annotation, add a `\u002F\u002F TODO: classify as enforce() or guidance()` comment\n- Keep rule IDs as kebab-case versions of the heading text\n- Preserve the `**Why:**` text as the second argument to `enforce()` or `guidance()`\n- If sections reference other files or skills, use `ref()` for cross-references\n\n### Step 4: Verify the Spec Compiles\n\nRun:\n\n```bash\nnpm run build\nnpx vigiles compile CLAUDE.md.spec.ts\n```\n\nCompare the compiled output against the original file. Key differences are expected (formatting, section ordering), but all rules, commands, and prose content should be preserved (a file map is the exception — see the `keyFiles` guideline above).\n\n### Step 5: Present the Result\n\nShow the user:\n\n1. The generated spec file\n2. How many rules were converted (enforce vs guidance vs TODO)\n3. How many file\u002Fcmd refs were added for stale reference detection\n4. The command to compile: `npx vigiles compile`\n5. The command to verify: `npx vigiles lint`\n\nAsk if they want you to write the file. If yes, also suggest adding to `.gitignore` or updating CI to run `vigiles compile` and `vigiles lint`.\n\n### Step 6: Optional — Set Up CI\n\nIf the user wants CI integration, suggest adding to their GitHub Actions workflow:\n\n```yaml\n- name: Compile specs\n  run: npx vigiles compile\n- name: Verify references + integrity\n  run: npx vigiles lint\n```\n\nOr using the vigiles GitHub Action:\n\n```yaml\n- uses: zernie\u002Fvigiles@v1\n  with:\n    command: lint\n```\n",{"name":5,"description":7,"argument-hint":34,"disable-model-invocation":35},"\u003Cpath to CLAUDE.md, defaults to CLAUDE.md>",true,"main","1a1de50f62f5c1093a46455488dcf6e8157c6182","skills\u002Fadopt-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":47,"prompt":57,"zipAvailable":35},[48,51,54],{"tool":49,"command":50},"npx","npx skills add zernie\u002Fvigiles --skill adopt-spec",{"tool":52,"command":53},"bunx","bunx skills add zernie\u002Fvigiles --skill adopt-spec",{"tool":55,"command":56},"pnpm","pnpm dlx skills add zernie\u002Fvigiles --skill adopt-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzernie\u002Fvigiles\u002Fblob\u002Fmain\u002Fskills\u002Fadopt-spec\u002FSKILL.md",[],[60,89,110,145,174,198],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":71,"publishedAt":29},"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",[66],{"categoryNo":67,"categoryName":68,"taxonomyType":69,"taxonomyTypeDesc":70},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,27],"audit","WCAG","wcag audit patterns","patterns","wcag audit","testing","design","accessibility","verification","remediation","use","design patterns","guidance","automated testing","with","manual","implementing",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":96,"publishedAt":29},"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",[95],{"categoryNo":67,"categoryName":68,"taxonomyType":69,"taxonomyTypeDesc":70},[77,97,98,99,100,101,102,79,103,104,105,82,106,107,108,109,86],"reader","screen reader testing","screen","support","test","web","debugging","issues","applications","test web","voiceover","compatibility","technology",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":124,"publishedAt":29},"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",[116,119],{"categoryNo":117,"categoryName":118,"taxonomyType":69,"taxonomyTypeDesc":70},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144],"research","x research","api changes","product","search","api","Bash","x api","perspectives","read","write","releases","expert","community","search x","time","caching","people","sorting","experts",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":157,"publishedAt":29},"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",[151,152,155,156],{"categoryNo":67,"categoryName":68,"taxonomyType":69,"taxonomyTypeDesc":70},{"categoryNo":153,"categoryName":154,"taxonomyType":69,"taxonomyTypeDesc":70},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":117,"categoryName":118,"taxonomyType":69,"taxonomyTypeDesc":70},{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[158,159,77,160,161,162,163,164,165,166,131,167,168,134,169,170,171,172,173,26],"Legacy","wooyun legacy","security","sql","code","database","injection","xss","vulnerability","access","command","Performing Penetration Testing","world","penetration","information","reviews",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":183,"publishedAt":29},"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",[180],{"categoryNo":181,"categoryName":182,"taxonomyType":69,"taxonomyTypeDesc":70},"01JBSEEDCAT000000000000023","Skill与智能体开发",[184,185,186,103,187,188,189,168,134,135,82,190,191,192,193,194,195,196,87,197],"skill extractor","sessions","documentation","help","grep","work","only","hooks","reusable","pattern","triggers","problem","via","websearch",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"publishedAt":29},"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",[],[160,205,206,102,80,207,208,167,188,134,209,82,210,211,212,213,214,215,216,217],"awareness","security awareness","email","phishing","webfetch","protection","social","social engineering","domain","vaults","operating","activity","phishing detection"]