[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXRMKEYJK3275C4GJRH4WN":3,"skill-same:01M6DXRMKEYJK3275C4GJRH4WN":77},{"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":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6DXRMKEYJK3275C4GJRH4WN","nodejs-best-practices",null,"Node.js development principles and decision-making. Framework selection, async patterns, security, and architecture. Teaches thinking, not copying.","EthanSheehan\u002FGrid-Sentinel","EthanSheehan","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F174215275?v=4","01M6DX9589ENESB2AYW9YK4Y50","Ethan Sheehan","01M6DX95P06JXASASFQZRFQ1NM",0,"MIT","https:\u002F\u002Fgithub.com\u002FEthanSheehan\u002FGrid-Sentinel\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fnodejs-best-practices\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"best practices","nodejs","nodejs best practices","node","decision-making","patterns","thinking","selection","async","framework selection","edit","write","read","security","grep","decision","js","framework","development","architecture","2026-11-10 10:12:30",false,"---\nname: nodejs-best-practices\ndescription: Node.js development principles and decision-making. Framework selection, async patterns, security, and architecture. Teaches thinking, not copying.\nallowed-tools: Read, Write, Edit, Glob, Grep\n---\n\n# Node.js Best Practices\n\n> Principles and decision-making for Node.js development in 2025.\n> **Learn to THINK, not memorize code patterns.**\n\n---\n\n## ⚠️ How to Use This Skill\n\nThis skill teaches **decision-making principles**, not fixed code to copy.\n\n- ASK user for preferences when unclear\n- Choose framework\u002Fpattern based on CONTEXT\n- Don't default to same solution every time\n\n---\n\n## 1. Framework Selection (2025)\n\n### Decision Tree\n\n```\nWhat are you building?\n│\n├── Edge\u002FServerless (Cloudflare, Vercel)\n│   └── Hono (zero-dependency, ultra-fast cold starts)\n│\n├── High Performance API\n│   └── Fastify (2-3x faster than Express)\n│\n├── Enterprise\u002FTeam familiarity\n│   └── NestJS (structured, DI, decorators)\n│\n├── Legacy\u002FStable\u002FMaximum ecosystem\n│   └── Express (mature, most middleware)\n│\n└── Full-stack with frontend\n    └── Next.js API Routes or tRPC\n```\n\n### Comparison Principles\n\n| Factor | Hono | Fastify | Express |\n|--------|------|---------|---------|\n| **Best for** | Edge, serverless | Performance | Legacy, learning |\n| **Cold start** | Fastest | Fast | Moderate |\n| **Ecosystem** | Growing | Good | Largest |\n| **TypeScript** | Native | Excellent | Good |\n| **Learning curve** | Low | Medium | Low |\n\n### Selection Questions to Ask:\n1. What's the deployment target?\n2. Is cold start time critical?\n3. Does team have existing experience?\n4. Is there legacy code to maintain?\n\n---\n\n## 2. Runtime Considerations (2025)\n\n### Native TypeScript\n\n```\nNode.js 22+: --experimental-strip-types\n├── Run .ts files directly\n├── No build step needed for simple projects\n└── Consider for: scripts, simple APIs\n```\n\n### Module System Decision\n\n```\nESM (import\u002Fexport)\n├── Modern standard\n├── Better tree-shaking\n├── Async module loading\n└── Use for: new projects\n\nCommonJS (require)\n├── Legacy compatibility\n├── More npm packages support\n└── Use for: existing codebases, some edge cases\n```\n\n### Runtime Selection\n\n| Runtime | Best For |\n|---------|----------|\n| **Node.js** | General purpose, largest ecosystem |\n| **Bun** | Performance, built-in bundler |\n| **Deno** | Security-first, built-in TypeScript |\n\n---\n\n## 3. Architecture Principles\n\n### Layered Structure Concept\n\n```\nRequest Flow:\n│\n├── Controller\u002FRoute Layer\n│   ├── Handles HTTP specifics\n│   ├── Input validation at boundary\n│   └── Calls service layer\n│\n├── Service Layer\n│   ├── Business logic\n│   ├── Framework-agnostic\n│   └── Calls repository layer\n│\n└── Repository Layer\n    ├── Data access only\n    ├── Database queries\n    └── ORM interactions\n```\n\n### Why This Matters:\n- **Testability**: Mock layers independently\n- **Flexibility**: Swap database without touching business logic\n- **Clarity**: Each layer has single responsibility\n\n### When to Simplify:\n- Small scripts → Single file OK\n- Prototypes → Less structure acceptable\n- Always ask: \"Will this grow?\"\n\n---\n\n## 4. Error Handling Principles\n\n### Centralized Error Handling\n\n```\nPattern:\n├── Create custom error classes\n├── Throw from any layer\n├── Catch at top level (middleware)\n└── Format consistent response\n```\n\n### Error Response Philosophy\n\n```\nClient gets:\n├── Appropriate HTTP status\n├── Error code for programmatic handling\n├── User-friendly message\n└── NO internal details (security!)\n\nLogs get:\n├── Full stack trace\n├── Request context\n├── User ID (if applicable)\n└── Timestamp\n```\n\n### Status Code Selection\n\n| Situation | Status | When |\n|-----------|--------|------|\n| Bad input | 400 | Client sent invalid data |\n| No auth | 401 | Missing or invalid credentials |\n| No permission | 403 | Valid auth, but not allowed |\n| Not found | 404 | Resource doesn't exist |\n| Conflict | 409 | Duplicate or state conflict |\n| Validation | 422 | Schema valid but business rules fail |\n| Server error | 500 | Our fault, log everything |\n\n---\n\n## 5. Async Patterns Principles\n\n### When to Use Each\n\n| Pattern | Use When |\n|---------|----------|\n| `async\u002Fawait` | Sequential async operations |\n| `Promise.all` | Parallel independent operations |\n| `Promise.allSettled` | Parallel where some can fail |\n| `Promise.race` | Timeout or first response wins |\n\n### Event Loop Awareness\n\n```\nI\u002FO-bound (async helps):\n├── Database queries\n├── HTTP requests\n├── File system\n└── Network operations\n\nCPU-bound (async doesn't help):\n├── Crypto operations\n├── Image processing\n├── Complex calculations\n└── → Use worker threads or offload\n```\n\n### Avoiding Event Loop Blocking\n\n- Never use sync methods in production (fs.readFileSync, etc.)\n- Offload CPU-intensive work\n- Use streaming for large data\n\n---\n\n## 6. Validation Principles\n\n### Validate at Boundaries\n\n```\nWhere to validate:\n├── API entry point (request body\u002Fparams)\n├── Before database operations\n├── External data (API responses, file uploads)\n└── Environment variables (startup)\n```\n\n### Validation Library Selection\n\n| Library | Best For |\n|---------|----------|\n| **Zod** | TypeScript first, inference |\n| **Valibot** | Smaller bundle (tree-shakeable) |\n| **ArkType** | Performance critical |\n| **Yup** | Existing React Form usage |\n\n### Validation Philosophy\n\n- Fail fast: Validate early\n- Be specific: Clear error messages\n- Don't trust: Even \"internal\" data\n\n---\n\n## 7. Security Principles\n\n### Security Checklist (Not Code)\n\n- [ ] **Input validation**: All inputs validated\n- [ ] **Parameterized queries**: No string concatenation for SQL\n- [ ] **Password hashing**: bcrypt or argon2\n- [ ] **JWT verification**: Always verify signature and expiry\n- [ ] **Rate limiting**: Protect from abuse\n- [ ] **Security headers**: Helmet.js or equivalent\n- [ ] **HTTPS**: Everywhere in production\n- [ ] **CORS**: Properly configured\n- [ ] **Secrets**: Environment variables only\n- [ ] **Dependencies**: Regularly audited\n\n### Security Mindset\n\n```\nTrust nothing:\n├── Query params → validate\n├── Request body → validate\n├── Headers → verify\n├── Cookies → validate\n├── File uploads → scan\n└── External APIs → validate response\n```\n\n---\n\n## 8. Testing Principles\n\n### Test Strategy Selection\n\n| Type | Purpose | Tools |\n|------|---------|-------|\n| **Unit** | Business logic | node:test, Vitest |\n| **Integration** | API endpoints | Supertest |\n| **E2E** | Full flows | Playwright |\n\n### What to Test (Priorities)\n\n1. **Critical paths**: Auth, payments, core business\n2. **Edge cases**: Empty inputs, boundaries\n3. **Error handling**: What happens when things fail?\n4. **Not worth testing**: Framework code, trivial getters\n\n### Built-in Test Runner (Node.js 22+)\n\n```\nnode --test src\u002F**\u002F*.test.ts\n├── No external dependency\n├── Good coverage reporting\n└── Watch mode available\n```\n\n---\n\n## 10. Anti-Patterns to Avoid\n\n### ❌ DON'T:\n- Use Express for new edge projects (use Hono)\n- Use sync methods in production code\n- Put business logic in controllers\n- Skip input validation\n- Hardcode secrets\n- Trust external data without validation\n- Block event loop with CPU work\n\n### ✅ DO:\n- Choose framework based on context\n- Ask user for preferences when unclear\n- Use layered architecture for growing projects\n- Validate all inputs\n- Use environment variables for secrets\n- Profile before optimizing\n\n---\n\n## 11. Decision Checklist\n\nBefore implementing:\n\n- [ ] **Asked user about stack preference?**\n- [ ] **Chosen framework for THIS context?** (not just default)\n- [ ] **Considered deployment target?**\n- [ ] **Planned error handling strategy?**\n- [ ] **Identified validation points?**\n- [ ] **Considered security requirements?**\n\n---\n\n> **Remember**: Node.js best practices are about decision-making, not memorizing patterns. Every project deserves fresh consideration based on its requirements.\n","# Node.js Best Practices\n\n> Principles and decision-making for Node.js development in 2025.\n> **Learn to THINK, not memorize code patterns.**\n\n---\n\n## ⚠️ How to Use This Skill\n\nThis skill teaches **decision-making principles**, not fixed code to copy.\n\n- ASK user for preferences when unclear\n- Choose framework\u002Fpattern based on CONTEXT\n- Don't default to same solution every time\n\n---\n\n## 1. Framework Selection (2025)\n\n### Decision Tree\n\n```\nWhat are you building?\n│\n├── Edge\u002FServerless (Cloudflare, Vercel)\n│   └── Hono (zero-dependency, ultra-fast cold starts)\n│\n├── High Performance API\n│   └── Fastify (2-3x faster than Express)\n│\n├── Enterprise\u002FTeam familiarity\n│   └── NestJS (structured, DI, decorators)\n│\n├── Legacy\u002FStable\u002FMaximum ecosystem\n│   └── Express (mature, most middleware)\n│\n└── Full-stack with frontend\n    └── Next.js API Routes or tRPC\n```\n\n### Comparison Principles\n\n| Factor | Hono | Fastify | Express |\n|--------|------|---------|---------|\n| **Best for** | Edge, serverless | Performance | Legacy, learning |\n| **Cold start** | Fastest | Fast | Moderate |\n| **Ecosystem** | Growing | Good | Largest |\n| **TypeScript** | Native | Excellent | Good |\n| **Learning curve** | Low | Medium | Low |\n\n### Selection Questions to Ask:\n1. What's the deployment target?\n2. Is cold start time critical?\n3. Does team have existing experience?\n4. Is there legacy code to maintain?\n\n---\n\n## 2. Runtime Considerations (2025)\n\n### Native TypeScript\n\n```\nNode.js 22+: --experimental-strip-types\n├── Run .ts files directly\n├── No build step needed for simple projects\n└── Consider for: scripts, simple APIs\n```\n\n### Module System Decision\n\n```\nESM (import\u002Fexport)\n├── Modern standard\n├── Better tree-shaking\n├── Async module loading\n└── Use for: new projects\n\nCommonJS (require)\n├── Legacy compatibility\n├── More npm packages support\n└── Use for: existing codebases, some edge cases\n```\n\n### Runtime Selection\n\n| Runtime | Best For |\n|---------|----------|\n| **Node.js** | General purpose, largest ecosystem |\n| **Bun** | Performance, built-in bundler |\n| **Deno** | Security-first, built-in TypeScript |\n\n---\n\n## 3. Architecture Principles\n\n### Layered Structure Concept\n\n```\nRequest Flow:\n│\n├── Controller\u002FRoute Layer\n│   ├── Handles HTTP specifics\n│   ├── Input validation at boundary\n│   └── Calls service layer\n│\n├── Service Layer\n│   ├── Business logic\n│   ├── Framework-agnostic\n│   └── Calls repository layer\n│\n└── Repository Layer\n    ├── Data access only\n    ├── Database queries\n    └── ORM interactions\n```\n\n### Why This Matters:\n- **Testability**: Mock layers independently\n- **Flexibility**: Swap database without touching business logic\n- **Clarity**: Each layer has single responsibility\n\n### When to Simplify:\n- Small scripts → Single file OK\n- Prototypes → Less structure acceptable\n- Always ask: \"Will this grow?\"\n\n---\n\n## 4. Error Handling Principles\n\n### Centralized Error Handling\n\n```\nPattern:\n├── Create custom error classes\n├── Throw from any layer\n├── Catch at top level (middleware)\n└── Format consistent response\n```\n\n### Error Response Philosophy\n\n```\nClient gets:\n├── Appropriate HTTP status\n├── Error code for programmatic handling\n├── User-friendly message\n└── NO internal details (security!)\n\nLogs get:\n├── Full stack trace\n├── Request context\n├── User ID (if applicable)\n└── Timestamp\n```\n\n### Status Code Selection\n\n| Situation | Status | When |\n|-----------|--------|------|\n| Bad input | 400 | Client sent invalid data |\n| No auth | 401 | Missing or invalid credentials |\n| No permission | 403 | Valid auth, but not allowed |\n| Not found | 404 | Resource doesn't exist |\n| Conflict | 409 | Duplicate or state conflict |\n| Validation | 422 | Schema valid but business rules fail |\n| Server error | 500 | Our fault, log everything |\n\n---\n\n## 5. Async Patterns Principles\n\n### When to Use Each\n\n| Pattern | Use When |\n|---------|----------|\n| `async\u002Fawait` | Sequential async operations |\n| `Promise.all` | Parallel independent operations |\n| `Promise.allSettled` | Parallel where some can fail |\n| `Promise.race` | Timeout or first response wins |\n\n### Event Loop Awareness\n\n```\nI\u002FO-bound (async helps):\n├── Database queries\n├── HTTP requests\n├── File system\n└── Network operations\n\nCPU-bound (async doesn't help):\n├── Crypto operations\n├── Image processing\n├── Complex calculations\n└── → Use worker threads or offload\n```\n\n### Avoiding Event Loop Blocking\n\n- Never use sync methods in production (fs.readFileSync, etc.)\n- Offload CPU-intensive work\n- Use streaming for large data\n\n---\n\n## 6. Validation Principles\n\n### Validate at Boundaries\n\n```\nWhere to validate:\n├── API entry point (request body\u002Fparams)\n├── Before database operations\n├── External data (API responses, file uploads)\n└── Environment variables (startup)\n```\n\n### Validation Library Selection\n\n| Library | Best For |\n|---------|----------|\n| **Zod** | TypeScript first, inference |\n| **Valibot** | Smaller bundle (tree-shakeable) |\n| **ArkType** | Performance critical |\n| **Yup** | Existing React Form usage |\n\n### Validation Philosophy\n\n- Fail fast: Validate early\n- Be specific: Clear error messages\n- Don't trust: Even \"internal\" data\n\n---\n\n## 7. Security Principles\n\n### Security Checklist (Not Code)\n\n- [ ] **Input validation**: All inputs validated\n- [ ] **Parameterized queries**: No string concatenation for SQL\n- [ ] **Password hashing**: bcrypt or argon2\n- [ ] **JWT verification**: Always verify signature and expiry\n- [ ] **Rate limiting**: Protect from abuse\n- [ ] **Security headers**: Helmet.js or equivalent\n- [ ] **HTTPS**: Everywhere in production\n- [ ] **CORS**: Properly configured\n- [ ] **Secrets**: Environment variables only\n- [ ] **Dependencies**: Regularly audited\n\n### Security Mindset\n\n```\nTrust nothing:\n├── Query params → validate\n├── Request body → validate\n├── Headers → verify\n├── Cookies → validate\n├── File uploads → scan\n└── External APIs → validate response\n```\n\n---\n\n## 8. Testing Principles\n\n### Test Strategy Selection\n\n| Type | Purpose | Tools |\n|------|---------|-------|\n| **Unit** | Business logic | node:test, Vitest |\n| **Integration** | API endpoints | Supertest |\n| **E2E** | Full flows | Playwright |\n\n### What to Test (Priorities)\n\n1. **Critical paths**: Auth, payments, core business\n2. **Edge cases**: Empty inputs, boundaries\n3. **Error handling**: What happens when things fail?\n4. **Not worth testing**: Framework code, trivial getters\n\n### Built-in Test Runner (Node.js 22+)\n\n```\nnode --test src\u002F**\u002F*.test.ts\n├── No external dependency\n├── Good coverage reporting\n└── Watch mode available\n```\n\n---\n\n## 10. Anti-Patterns to Avoid\n\n### ❌ DON'T:\n- Use Express for new edge projects (use Hono)\n- Use sync methods in production code\n- Put business logic in controllers\n- Skip input validation\n- Hardcode secrets\n- Trust external data without validation\n- Block event loop with CPU work\n\n### ✅ DO:\n- Choose framework based on context\n- Ask user for preferences when unclear\n- Use layered architecture for growing projects\n- Validate all inputs\n- Use environment variables for secrets\n- Profile before optimizing\n\n---\n\n## 11. Decision Checklist\n\nBefore implementing:\n\n- [ ] **Asked user about stack preference?**\n- [ ] **Chosen framework for THIS context?** (not just default)\n- [ ] **Considered deployment target?**\n- [ ] **Planned error handling strategy?**\n- [ ] **Identified validation points?**\n- [ ] **Considered security requirements?**\n\n---\n\n> **Remember**: Node.js best practices are about decision-making, not memorizing patterns. Every project deserves fresh consideration based on its requirements.\n",{"name":5,"description":7,"allowed-tools":44},"Read, Write, Edit, Glob, Grep","main","33d99efaac9ea5758fc27120b467eca96ad020d9",".agent\u002Fskills\u002Fnodejs-best-practices","https:\u002F\u002Fgithub.com\u002FEthanSheehan\u002FGrid-Sentinel","https:\u002F\u002Fgithub.com\u002FEthanSheehan","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fethan-sheehan\u002F","Aerospace Engineering Student at the University of Bristol \u002F\u002F Propulsion Lead at HyPower Bristol","2026-05-22 21:19:23",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add EthanSheehan\u002FGrid-Sentinel --skill nodejs-best-practices",{"tool":59,"command":60},"bunx","bunx skills add EthanSheehan\u002FGrid-Sentinel --skill nodejs-best-practices",{"tool":62,"command":63},"pnpm","pnpm dlx skills add EthanSheehan\u002FGrid-Sentinel --skill nodejs-best-practices","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FEthanSheehan\u002FGrid-Sentinel\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fnodejs-best-practices\u002FSKILL.md",true,[67,73],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"scripts\u002Fmemento_cards.py","SCRIPT","脚本",11449,"https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002Fhermes-sovereign-unified-v13.6\u002Fblob\u002Fmain\u002Fhermes-agent\u002Foptional-skills\u002Fproductivity\u002Fmemento-flashcards\u002Fscripts\u002Fmemento_cards.py",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"scripts\u002Fyoutube_quiz.py",2349,"https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002Fhermes-sovereign-unified-v13.6\u002Fblob\u002Fmain\u002Fhermes-agent\u002Foptional-skills\u002Fproductivity\u002Fmemento-flashcards\u002Fscripts\u002Fyoutube_quiz.py",[78,109,141,161,175,200],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":89,"publishedAt":39},"01M6DY3X97YDSKHCCZG9KMASHA","zapier-make-patterns","No-code automation democratizes workflow building. Zapier and Make (formerly Integromat) let non-developers automate business processes without writing code. But no-code doesn't mean no-complexity - these platforms have their own patterns, pitfalls, and breaking points.  This skill covers when to use which platform, how to build reliable automations, and when to graduate to code-based solutions. Key insight: Zapier optimizes for simplicity and integrations (7000+ apps), Make optimizes for power","https:\u002F\u002Fgithub.com\u002FEthanSheehan\u002FGrid-Sentinel\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fzapier-make-patterns\u002FSKILL.md",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[90,24,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108],"zapier make patterns","workflow","integrations","how to","apps","platform","but","build","complexity","power","simplicity","use","business","automate","how","apache","code","automation","writing",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":121,"publishedAt":39},"01M6DY3SVP128ZZPF2478H9JYZ","Cross-Site Scripting and HTML Injection Testing","This skill should be used when the user asks to \"test for XSS vulnerabilities\", \"perform cross-site scripting attacks\", \"identify HTML injection flaws\", \"exploit client-side injection vulnerabilities\", \"steal cookies via XSS\", or \"bypass content security policies\". It provides comprehensive techniques for detecting, exploiting, and understanding XSS and HTML injection attack vectors in web applications.","https:\u002F\u002Fgithub.com\u002FEthanSheehan\u002FGrid-Sentinel\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fxss-html-injection\u002FSKILL.md",[115,118],{"categoryNo":116,"categoryName":117,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":119,"categoryName":120,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000009","前端开发",[122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,32,140],"html injection testing","Cross Site Scripting and HTML Injection Testing","injection","scripting","site","html","testing","exploit","user","applications","xss","cookies","content","web","test","vectors","via","steal","vulnerabilities",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":156,"publishedAt":39},"01M6DY3D694G80Y5N79CD1J575","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002FEthanSheehan\u002FGrid-Sentinel\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[147,148,151],{"categoryNo":116,"categoryName":117,"taxonomyType":87,"taxonomyTypeDesc":88},{"categoryNo":149,"categoryName":150,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":152,"categoryName":153,"taxonomyType":154,"taxonomyTypeDesc":155},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[108,157,158,101,159,160],"writing skills","deployment","editing","work",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":169,"publishedAt":39},"01M6DY3A7BM31W5Q2QARW00JHS","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002FEthanSheehan\u002FGrid-Sentinel\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[167,168],{"categoryNo":149,"categoryName":150,"taxonomyType":87,"taxonomyTypeDesc":88},{"categoryNo":152,"categoryName":153,"taxonomyType":154,"taxonomyTypeDesc":155},[170,108,171,172,173,101,106,174],"writing plans","plans","requirements","task","spec",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":182,"publishedAt":39},"01M6DY36NSATM95HR7HMVZJYB3","workflow-automation","Workflow automation is the infrastructure that makes AI agents reliable. Without durable execution, a network hiccup during a 10-step payment flow means lost money and angry customers. With it, workflows resume exactly where they left off.  This skill covers the platforms (n8n, Temporal, Inngest) and patterns (sequential, parallel, orchestrator-worker) that turn brittle scripts into production-grade automation.  Key insight: The platforms make different tradeoffs. n8n optimizes for accessibility","https:\u002F\u002Fgithub.com\u002FEthanSheehan\u002FGrid-Sentinel\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fworkflow-automation\u002FSKILL.md",[181],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},[183,107,91,184,185,186,105,187,188,189,190,191,192,193,194,195,196,197,198,199],"Workflow Automation","Production","flow","network","workflows","accessibility","ai agents","execution","scripts","worker","payment","n8n","money","resume","orchestrator","parallel","inngest",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":207,"publishedAt":39},"01M6DY32QTGD80MQHJ8TPDH53H","WordPress Penetration Testing","This skill should be used when the user asks to \"pentest WordPress sites\", \"scan WordPress for vulnerabilities\", \"enumerate WordPress users, themes, or plugins\", \"exploit WordPress vulnerabilities\", or \"use WPScan\". It provides comprehensive WordPress security assessment methodologies.","https:\u002F\u002Fgithub.com\u002FEthanSheehan\u002FGrid-Sentinel\u002Fblob\u002Fmain\u002F.agent\u002Fskills\u002Fwordpress-penetration-testing\u002FSKILL.md",[206],{"categoryNo":116,"categoryName":117,"taxonomyType":87,"taxonomyTypeDesc":88},[128,202,208,209,210,211,212,213,129,101,130,214,215,140,32],"penetration testing","wordpress","security assessment","sites","scan","pentest","plugins","assessment"]