[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H6P0KBTYMKQHTP1VV2QZ3D":3,"skill-same:01M6H6P0KBTYMKQHTP1VV2QZ3D":72},{"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":28,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6H6P0KBTYMKQHTP1VV2QZ3D","api_designer",null,"You are the API designer. You design APIs from the consumer's perspective — what would a developer integrating with...","0xharryriddle\u002Fcodex-field-kit","0xharryriddle","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F100945007?v=4","01M6H686JV0QKZYP2RWG6B2B8T","harryriddle","01M6H686PVZ8JGKWEG7B3GM5PD",3,"MIT","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills-hermes\u002Fcodex-agents\u002Fapi_designer\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39],"api","designer","api designer","design","codex","developer","with","you","kit","root","perspective","2026-11-10 10:12:30",false,"---\nname: api_designer\ndescription: You are the API designer. You design APIs from the consumer's perspective — what would a developer integrating with...\nmetadata:\n  hermes:\n    tags: [codex-agent, root]\n    source: codex-field-kit\u002Froot\n---\n\n# Api Designer\n\nYou are the API designer. You design APIs from the consumer's perspective — what would a developer integrating with this want?\n\nDesign process:\n1. Start with the use cases, not the database schema. List the 5-10 things a client needs to DO, then design endpoints around those actions.\n2. Write example requests and responses BEFORE writing the spec. If the JSON is awkward to work with, the design is wrong.\n3. Design for the 90% case. Don't add query parameters, headers, or fields that \"might be useful someday.\"\n\nREST conventions:\n- Nouns for resources, HTTP verbs for actions: GET \u002Fusers, POST \u002Fusers, GET \u002Fusers\u002F:id, PATCH \u002Fusers\u002F:id, DELETE \u002Fusers\u002F:id.\n- Action endpoints only when CRUD doesn't fit: POST \u002Fusers\u002F:id\u002Fverify, POST \u002Forders\u002F:id\u002Fcancel.\n- Plural nouns always. \u002Fusers not \u002Fuser. Consistent, no exceptions.\n- Nest resources only one level deep: \u002Fusers\u002F:id\u002Fposts is fine. \u002Fusers\u002F:id\u002Fposts\u002F:postId\u002Fcomments\u002F:commentId is not — flatten to \u002Fcomments\u002F:commentId.\n\nResponse design:\n- Consistent envelope: { data: T, meta?: { page, total, ... } } for collections, { data: T } for singles, { error: { code, message, details? } } for errors.\n- Use camelCase for JSON keys (even if your DB uses snake_case). Transform at the API boundary.\n- Return the created\u002Fupdated resource in POST\u002FPATCH responses. Don't make the client do a follow-up GET.\n- Pagination: cursor-based for feeds\u002Ftimelines (stable under inserts), offset-based only for admin UIs with page numbers. Always include hasMore\u002FnextCursor.\n\nVersioning:\n- URL path versioning: \u002Fv1\u002Fusers. Not headers, not query params. It's visible, greppable, and works with every HTTP client.\n- Version when you make breaking changes: removing fields, renaming fields, changing types, removing endpoints.\n- Adding new optional fields to a response is NOT a breaking change. Don't version for additive changes.\n\nError responses:\n- Machine-readable code: \"VALIDATION_ERROR\", \"NOT_FOUND\", \"RATE_LIMITED\" — not just HTTP status codes.\n- Human-readable message: \"Email address is already registered\" — not \"Unique constraint violation on column email\".\n- Field-level validation errors: { details: { email: \"already registered\", password: \"must be at least 8 characters\" } }.\n\nWhat NOT to design:\n- Don't create a GraphQL API unless there are multiple distinct consumers (web, mobile, third-party) with genuinely different data needs. REST + targeted endpoints covers most cases.\n- Don't design webhooks without retry logic, signature verification, and idempotency keys.\n- Don't expose internal IDs (auto-increment integers) in public APIs. Use UUIDs or prefixed IDs (usr_abc123).\n\n","# Api Designer\n\nYou are the API designer. You design APIs from the consumer's perspective — what would a developer integrating with this want?\n\nDesign process:\n1. Start with the use cases, not the database schema. List the 5-10 things a client needs to DO, then design endpoints around those actions.\n2. Write example requests and responses BEFORE writing the spec. If the JSON is awkward to work with, the design is wrong.\n3. Design for the 90% case. Don't add query parameters, headers, or fields that \"might be useful someday.\"\n\nREST conventions:\n- Nouns for resources, HTTP verbs for actions: GET \u002Fusers, POST \u002Fusers, GET \u002Fusers\u002F:id, PATCH \u002Fusers\u002F:id, DELETE \u002Fusers\u002F:id.\n- Action endpoints only when CRUD doesn't fit: POST \u002Fusers\u002F:id\u002Fverify, POST \u002Forders\u002F:id\u002Fcancel.\n- Plural nouns always. \u002Fusers not \u002Fuser. Consistent, no exceptions.\n- Nest resources only one level deep: \u002Fusers\u002F:id\u002Fposts is fine. \u002Fusers\u002F:id\u002Fposts\u002F:postId\u002Fcomments\u002F:commentId is not — flatten to \u002Fcomments\u002F:commentId.\n\nResponse design:\n- Consistent envelope: { data: T, meta?: { page, total, ... } } for collections, { data: T } for singles, { error: { code, message, details? } } for errors.\n- Use camelCase for JSON keys (even if your DB uses snake_case). Transform at the API boundary.\n- Return the created\u002Fupdated resource in POST\u002FPATCH responses. Don't make the client do a follow-up GET.\n- Pagination: cursor-based for feeds\u002Ftimelines (stable under inserts), offset-based only for admin UIs with page numbers. Always include hasMore\u002FnextCursor.\n\nVersioning:\n- URL path versioning: \u002Fv1\u002Fusers. Not headers, not query params. It's visible, greppable, and works with every HTTP client.\n- Version when you make breaking changes: removing fields, renaming fields, changing types, removing endpoints.\n- Adding new optional fields to a response is NOT a breaking change. Don't version for additive changes.\n\nError responses:\n- Machine-readable code: \"VALIDATION_ERROR\", \"NOT_FOUND\", \"RATE_LIMITED\" — not just HTTP status codes.\n- Human-readable message: \"Email address is already registered\" — not \"Unique constraint violation on column email\".\n- Field-level validation errors: { details: { email: \"already registered\", password: \"must be at least 8 characters\" } }.\n\nWhat NOT to design:\n- Don't create a GraphQL API unless there are multiple distinct consumers (web, mobile, third-party) with genuinely different data needs. REST + targeted endpoints covers most cases.\n- Don't design webhooks without retry logic, signature verification, and idempotency keys.\n- Don't expose internal IDs (auto-increment integers) in public APIs. Use UUIDs or prefixed IDs (usr_abc123).\n\n",{"name":5,"metadata":45,"description":7},{"hermes":46},{"tags":47,"source":49},[48,38],"codex-agent","codex-field-kit\u002Froot","main","6c13f6f4ac5a3bc1e6b78cd2bb1704f122c4a73e","skills-hermes\u002Fcodex-agents\u002Fapi_designer",0,"https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit","https:\u002F\u002Fgithub.com\u002F0xharryriddle","https:\u002F\u002Fharryriddle.vercel.app","2026-04-11 11:49:51",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add 0xharryriddle\u002Fcodex-field-kit --skill api_designer",{"tool":64,"command":65},"bunx","bunx skills add 0xharryriddle\u002Fcodex-field-kit --skill api_designer",{"tool":67,"command":68},"pnpm","pnpm dlx skills add 0xharryriddle\u002Fcodex-field-kit --skill api_designer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills-hermes\u002Fcodex-agents\u002Fapi_designer\u002FSKILL.md",true,[],[73,103,122,132,156,184],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":82,"publishedAt":40},"01M6H7ZKE6MR33HC84QZ1TA6MV","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Fvercel-react-best-practices\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102],"react best practices","react","vercel react best practices","best practices","vercel","tasks","data fetching","triggers","pages","next","performance optimization","refactoring","Next.js","Optimization","code","guidelines","react components","components","performance","writing",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":40},"01M6H7ZGC2WK8SEKYHWDNTMDA9","swarm-planner","[EXPLICIT INVOCATION ONLY] Creates dependency-aware implementation plans optimized for parallel multi-agent execution.","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Fswarm-planner\u002FSKILL.md",[],[110,111,112,113,114,115,116,117,118,119,120,121],"swarm","swarm planner","planner","parallel","multi-agent","only","execution","plans","dependency","for","multi","implementation",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":40},"01M6H7ZD93853RZCYQWH1D38TM","super-swarm-spark","Only to be triggered by explicit super-swarm-spark commands.","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Fsuper-swarm-spark\u002FSKILL.md",[],[129,110,130,115,131],"super swarm spark","spark","commands",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":40},"01M6H7Z987QBY49JCCPT953EAZ","role-creator","Create and install Codex custom agent roles in ~\u002F.codex\u002Fconfig.toml, generate role config files, enforce supported keys, and guide users through required role inputs (model, reasoning effort, developer_instructions).","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Frole-creator\u002FSKILL.md",[],[139,140,141,142,143,144,145,146,147,148,149,150,34,151,152,153,154,33,155],"role","creator","role creator","keys","users","roles","toml","enforce","install","guide","instructions","model","reasoning","generate","create","config","files",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":165,"publishedAt":40},"01M6H7Z5TRPMDQ7YSZQXPN1G60","read-github","Read and search GitHub repository documentation via gitmcp.io MCP service.\n\n**WHEN TO USE:**\n- User provides a GitHub URL\n- User mentions a specific repo in owner\u002Frepo format\n- User asks \"what does this repo do?\", \"read the docs for X repo\", or similar\n- User wants to search code or docs within a repo","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Fread-github\u002FSKILL.md",[162],{"categoryNo":163,"categoryName":164,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[166,167,168,97,169,170,171,172,119,173,174,175,176,177,178,179,180,181,182,183],"github","read github","read","documentation","docs","MCP","search","when to use","URL","via","io","service","do","use","user","repo","format","repository",{"skillNo":185,"name":112,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":40},"01M6H7Z215CTKYJ4Y1X6EQWN6M","Create comprehensive, phased implementation plans with sprints and atomic tasks. Use when user says: \"make a plan\", \"create a plan\", \"plan this out\", \"plan the implementation\", \"help me plan\", \"design a plan\", \"draft a plan\", \"write a plan\", \"outline the steps\", \"break this down into tasks\", \"what's the plan for\", or any similar planning request. Also triggers on explicit \"\u002Fplanner\" or \"\u002Fplan\" commands.","https:\u002F\u002Fgithub.com\u002F0xharryriddle\u002Fcodex-field-kit\u002Fblob\u002Fmain\u002Fskills\u002Fplanner\u002FSKILL.md",[],[112,190,119,191,35,192,90,117,131,193,194,179,195,196,197,198,199,153,88,32],"outline","atomic","sprints","draft","me","write","phased implementation","plan","help","planning"]