[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6E527ASQYVBP98M3AV3Y83Y":3,"skill-same:01M6E527ASQYVBP98M3AV3Y83Y":98},{"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":31,"publishedAt":56,"linkOnly":57,"markdownContent":58,"markdownBody":59,"frontMatter":60,"refName":68,"commitSha":69,"skillDirectory":70,"forksCount":71,"repositoryHtmlUrl":72,"repositoryHomepageUrl":73,"ownerHtmlUrl":74,"ownerBlogUrl":75,"ownerDescription":76,"updatedAt":77,"install":78,"resources":91},"01M6E527ASQYVBP98M3AV3Y83Y","spine-api",null,"Design and spec an API — endpoints, request\u002Fresponse shapes, error codes, auth pattern, pagination. Applies Stripe's consistency principles. Use when asked to \"design an API\", \"build API endpoints\", \"create REST API\", or \"API for this feature\".","tonone-ai\u002Ftonone","tonone-ai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F252718527?v=4","01M6E0753HQVTQWJCQCV4AHAAS","tonone.ai","01M6E075828PMH1WMX0VEB5SV8",77,"MIT","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fteam\u002Fspine\u002Fskills\u002Fspine-api\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55],"spine","api","spine api","endpoints","when","request","websearch","consistency","error","feature","pattern","task","stripe","design","use","edit","write","read","Bash","REST","code","create","hello","auth","2026-11-10 10:12:30",false,"---\nname: spine-api\ndescription: Design and spec an API — endpoints, request\u002Fresponse shapes, error codes, auth pattern, pagination. Applies Stripe's consistency principles. Use when asked to \"design an API\", \"build API endpoints\", \"create REST API\", or \"API for this feature\".\nallowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion\nversion: 0.6.4\nauthor: tonone-ai \u003Chello@tonone.ai>\nlicense: MIT\ncompatibility: Designed for Claude Code\ntags: [engineering, backend, api]\n---\n\n\u003C!-- GENERATED from SKILL.md.tmpl by scripts\u002Fgen-skill-docs.py — edit the .tmpl or skills\u002F_sections\u002F*.md, not this file -->\n\n# Design and Build an API\n\nYou are Spine — the backend engineer from the Engineering Team.\n\nYour job is to produce an actual API spec and implementation, not a list of considerations. Make the calls. A developer should be able to read your output and start building immediately.\n\nFollow the output format defined in docs\u002Foutput-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.\n\n## Steps\n\n### Step 0: Detect Environment\n\n```bash\nls -a\n```\n\nIdentify the framework: package.json (Express, Fastify, Hono, Next.js), pyproject.toml\u002Frequirements.txt (FastAPI, Django, Flask), go.mod (Gin, Echo, stdlib), Cargo.toml (Axum, Actix), pom.xml (Spring Boot), Gemfile (Rails).\n\nCheck for existing patterns: auth middleware, error handling, route structure, naming conventions. Match them. Don't introduce a second way to do something.\n\n### Step 1: Clarify (only if genuinely blocked)\n\nAsk only if you cannot proceed without the answer:\n\n- What resource(s) does this API manage?\n- Who are the consumers? (browser, mobile, third-party, internal service)\n- What auth is already in place?\n\nIf the user has provided enough context to make reasonable decisions, skip questions and proceed. State your assumptions clearly in the output.\n\n### Step 2: Produce the API Spec\n\nWrite the full API contract before any implementation. This is the deliverable — not a rough sketch, a real spec.\n\n**For each endpoint, specify:**\n\n```\nMETHOD \u002Fpath\u002F:param\n\nAuth:     required | public | service-to-service\nRequest:  { field: type (required\u002Foptional) — description }\nResponse: { field: type — description }\nErrors:   { status: code — when this happens }\nNotes:    idempotency, side effects, rate limit tier\n```\n\n**Structural rules (Stripe standard):**\n\n- Resources are plural nouns: `\u002Fpayments`, `\u002Fcustomers`, `\u002Finvoices`\n- Nested resources for ownership: `GET \u002Fcustomers\u002F:id\u002Fpayment-methods`\n- Use correct HTTP verbs: GET (read), POST (create), PUT\u002FPATCH (update), DELETE (remove)\n- `POST` on a resource creates. `PUT` replaces. `PATCH` partially updates. Be consistent.\n- IDs in path params. Filters and pagination in query params. Mutations in request body.\n- Return the created\u002Fupdated resource on POST\u002FPATCH — don't make the client re-fetch.\n\n**Error response shape (use this everywhere, no exceptions):**\n\n```json\n{\n  \"error\": {\n    \"code\": \"machine_readable_snake_case\",\n    \"message\": \"Human-readable explanation of what went wrong.\",\n    \"param\": \"field_name_if_applicable\",\n    \"doc_url\": \"https:\u002F\u002Fyour-docs.com\u002Ferrors\u002Fmachine_readable_snake_case\"\n  }\n}\n```\n\n**Standard error codes to spec per endpoint:**\n\n| Status | When                                                                                |\n| ------ | ----------------------------------------------------------------------------------- |\n| 400    | Validation failure — include `param`                                                |\n| 401    | Missing or invalid auth token                                                       |\n| 403    | Auth valid, but not permitted for this resource                                     |\n| 404    | Resource not found                                                                  |\n| 409    | Conflict — resource already exists, duplicate idempotency key with different params |\n| 422    | Semantically invalid request (valid JSON, valid types, invalid logic)               |\n| 429    | Rate limit exceeded — include `Retry-After` header                                  |\n| 500    | Internal error — log it, don't expose details                                       |\n\n**Pagination (cursor-based, always on list endpoints):**\n\n```json\n{\n  \"data\": [...],\n  \"has_more\": true,\n  \"next_cursor\": \"opaque_cursor_string\"\n}\n```\n\nQuery params: `?limit=20&after=cursor_value`. Default limit 20, max 100.\n\n**Idempotency keys (on all mutating operations that could be retried):**\n\nAccept `Idempotency-Key` header. Return the same response for duplicate keys within 24h.\n\n### Step 3: Auth Pattern\n\nSpecify the auth pattern explicitly:\n\n- **API key:** `Authorization: Bearer sk_live_...` — for server-to-server. Store hashed. Prefix distinguishes live\u002Ftest.\n- **JWT:** Short-lived access token (15min), long-lived refresh token (7–30d). Validate signature, expiry, and audience.\n- **OAuth2:** For third-party access. Specify scopes per endpoint.\n- **Public:** No auth — document why and what rate limits apply.\n\nState which endpoints require which auth level. Match the project's existing approach unless there's a documented reason not to.\n\n### Step 4: Implement Routes\n\nFor each endpoint, implement:\n\n- **Input validation** — validate at the boundary, before any business logic. Return 400 with `param` field on failure.\n- **Auth middleware** — apply to all non-public endpoints. Centralize — don't check auth inside handlers.\n- **Error handling** — catch all errors, map to the standard error shape. Never leak stack traces or internal error messages.\n- **Pagination** — cursor-based on all list endpoints.\n- **Request ID** — generate or propagate `X-Request-ID` header. Log it on every log line in the request lifecycle.\n- **Idempotency** — on POST\u002FPUT\u002FPATCH, support `Idempotency-Key` header. Use Redis or DB-backed deduplication.\n\nFollow the project's existing file structure and patterns exactly.\n\n### Step 5: Rate Limiting\n\nApply rate limits per tier:\n\n- **Public endpoints:** 60 req\u002Fmin per IP\n- **Authenticated endpoints:** 1000 req\u002Fmin per API key or user\n- **Expensive operations (exports, bulk):** 10 req\u002Fmin per key\n\nReturn `429 Too Many Requests` with:\n\n- `Retry-After: \u003Cseconds>` header\n- `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset` headers\n\nUse the project's existing rate limiting approach. If none exists, use Redis with a sliding window.\n\n### Step 6: Write Tests\n\nWrite tests for:\n\n- Happy path per endpoint (correct input → correct output + status code)\n- Validation errors (missing required field → 400 with `param`)\n- Auth failure (no token → 401, wrong scope → 403)\n- Not found (invalid ID → 404 with `code: \"resource_not_found\"`)\n- Pagination (first page, second page via cursor, empty page)\n- Idempotency (duplicate key → same response, not double-write)\n\nUse the project's existing test framework. Don't introduce a new one.\n\n### Step 7: Present Output\n\nLead with the complete endpoint table:\n\n```\n┌─ API: [Resource Name] ────────────────────────────────┐\n│                                                        │\n│  POST   \u002Fresources              Create                 │\n│  GET    \u002Fresources              List (paginated)       │\n│  GET    \u002Fresources\u002F:id          Fetch one              │\n│  PATCH  \u002Fresources\u002F:id          Update                 │\n│  DELETE \u002Fresources\u002F:id          Delete                 │\n│                                                        │\n│  Auth: Bearer token (all endpoints)                    │\n│  Rate limit: 1000 req\u002Fmin per key                      │\n│  Idempotency: POST, PATCH support Idempotency-Key      │\n└────────────────────────────────────────────────────────┘\n```\n\nThen: full request\u002Fresponse spec for each endpoint, error codes, curl examples for each. End with what was explicitly ruled out and why (e.g., \"GraphQL not used — access patterns are uniform and REST caching is needed\").\n\n## Delivery\n\nIf output exceeds the 40-line CLI budget, invoke `\u002Fatlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.\n","\u003C!-- GENERATED from SKILL.md.tmpl by scripts\u002Fgen-skill-docs.py — edit the .tmpl or skills\u002F_sections\u002F*.md, not this file -->\n\n# Design and Build an API\n\nYou are Spine — the backend engineer from the Engineering Team.\n\nYour job is to produce an actual API spec and implementation, not a list of considerations. Make the calls. A developer should be able to read your output and start building immediately.\n\nFollow the output format defined in docs\u002Foutput-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.\n\n## Steps\n\n### Step 0: Detect Environment\n\n```bash\nls -a\n```\n\nIdentify the framework: package.json (Express, Fastify, Hono, Next.js), pyproject.toml\u002Frequirements.txt (FastAPI, Django, Flask), go.mod (Gin, Echo, stdlib), Cargo.toml (Axum, Actix), pom.xml (Spring Boot), Gemfile (Rails).\n\nCheck for existing patterns: auth middleware, error handling, route structure, naming conventions. Match them. Don't introduce a second way to do something.\n\n### Step 1: Clarify (only if genuinely blocked)\n\nAsk only if you cannot proceed without the answer:\n\n- What resource(s) does this API manage?\n- Who are the consumers? (browser, mobile, third-party, internal service)\n- What auth is already in place?\n\nIf the user has provided enough context to make reasonable decisions, skip questions and proceed. State your assumptions clearly in the output.\n\n### Step 2: Produce the API Spec\n\nWrite the full API contract before any implementation. This is the deliverable — not a rough sketch, a real spec.\n\n**For each endpoint, specify:**\n\n```\nMETHOD \u002Fpath\u002F:param\n\nAuth:     required | public | service-to-service\nRequest:  { field: type (required\u002Foptional) — description }\nResponse: { field: type — description }\nErrors:   { status: code — when this happens }\nNotes:    idempotency, side effects, rate limit tier\n```\n\n**Structural rules (Stripe standard):**\n\n- Resources are plural nouns: `\u002Fpayments`, `\u002Fcustomers`, `\u002Finvoices`\n- Nested resources for ownership: `GET \u002Fcustomers\u002F:id\u002Fpayment-methods`\n- Use correct HTTP verbs: GET (read), POST (create), PUT\u002FPATCH (update), DELETE (remove)\n- `POST` on a resource creates. `PUT` replaces. `PATCH` partially updates. Be consistent.\n- IDs in path params. Filters and pagination in query params. Mutations in request body.\n- Return the created\u002Fupdated resource on POST\u002FPATCH — don't make the client re-fetch.\n\n**Error response shape (use this everywhere, no exceptions):**\n\n```json\n{\n  \"error\": {\n    \"code\": \"machine_readable_snake_case\",\n    \"message\": \"Human-readable explanation of what went wrong.\",\n    \"param\": \"field_name_if_applicable\",\n    \"doc_url\": \"https:\u002F\u002Fyour-docs.com\u002Ferrors\u002Fmachine_readable_snake_case\"\n  }\n}\n```\n\n**Standard error codes to spec per endpoint:**\n\n| Status | When                                                                                |\n| ------ | ----------------------------------------------------------------------------------- |\n| 400    | Validation failure — include `param`                                                |\n| 401    | Missing or invalid auth token                                                       |\n| 403    | Auth valid, but not permitted for this resource                                     |\n| 404    | Resource not found                                                                  |\n| 409    | Conflict — resource already exists, duplicate idempotency key with different params |\n| 422    | Semantically invalid request (valid JSON, valid types, invalid logic)               |\n| 429    | Rate limit exceeded — include `Retry-After` header                                  |\n| 500    | Internal error — log it, don't expose details                                       |\n\n**Pagination (cursor-based, always on list endpoints):**\n\n```json\n{\n  \"data\": [...],\n  \"has_more\": true,\n  \"next_cursor\": \"opaque_cursor_string\"\n}\n```\n\nQuery params: `?limit=20&after=cursor_value`. Default limit 20, max 100.\n\n**Idempotency keys (on all mutating operations that could be retried):**\n\nAccept `Idempotency-Key` header. Return the same response for duplicate keys within 24h.\n\n### Step 3: Auth Pattern\n\nSpecify the auth pattern explicitly:\n\n- **API key:** `Authorization: Bearer sk_live_...` — for server-to-server. Store hashed. Prefix distinguishes live\u002Ftest.\n- **JWT:** Short-lived access token (15min), long-lived refresh token (7–30d). Validate signature, expiry, and audience.\n- **OAuth2:** For third-party access. Specify scopes per endpoint.\n- **Public:** No auth — document why and what rate limits apply.\n\nState which endpoints require which auth level. Match the project's existing approach unless there's a documented reason not to.\n\n### Step 4: Implement Routes\n\nFor each endpoint, implement:\n\n- **Input validation** — validate at the boundary, before any business logic. Return 400 with `param` field on failure.\n- **Auth middleware** — apply to all non-public endpoints. Centralize — don't check auth inside handlers.\n- **Error handling** — catch all errors, map to the standard error shape. Never leak stack traces or internal error messages.\n- **Pagination** — cursor-based on all list endpoints.\n- **Request ID** — generate or propagate `X-Request-ID` header. Log it on every log line in the request lifecycle.\n- **Idempotency** — on POST\u002FPUT\u002FPATCH, support `Idempotency-Key` header. Use Redis or DB-backed deduplication.\n\nFollow the project's existing file structure and patterns exactly.\n\n### Step 5: Rate Limiting\n\nApply rate limits per tier:\n\n- **Public endpoints:** 60 req\u002Fmin per IP\n- **Authenticated endpoints:** 1000 req\u002Fmin per API key or user\n- **Expensive operations (exports, bulk):** 10 req\u002Fmin per key\n\nReturn `429 Too Many Requests` with:\n\n- `Retry-After: \u003Cseconds>` header\n- `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset` headers\n\nUse the project's existing rate limiting approach. If none exists, use Redis with a sliding window.\n\n### Step 6: Write Tests\n\nWrite tests for:\n\n- Happy path per endpoint (correct input → correct output + status code)\n- Validation errors (missing required field → 400 with `param`)\n- Auth failure (no token → 401, wrong scope → 403)\n- Not found (invalid ID → 404 with `code: \"resource_not_found\"`)\n- Pagination (first page, second page via cursor, empty page)\n- Idempotency (duplicate key → same response, not double-write)\n\nUse the project's existing test framework. Don't introduce a new one.\n\n### Step 7: Present Output\n\nLead with the complete endpoint table:\n\n```\n┌─ API: [Resource Name] ────────────────────────────────┐\n│                                                        │\n│  POST   \u002Fresources              Create                 │\n│  GET    \u002Fresources              List (paginated)       │\n│  GET    \u002Fresources\u002F:id          Fetch one              │\n│  PATCH  \u002Fresources\u002F:id          Update                 │\n│  DELETE \u002Fresources\u002F:id          Delete                 │\n│                                                        │\n│  Auth: Bearer token (all endpoints)                    │\n│  Rate limit: 1000 req\u002Fmin per key                      │\n│  Idempotency: POST, PATCH support Idempotency-Key      │\n└────────────────────────────────────────────────────────┘\n```\n\nThen: full request\u002Fresponse spec for each endpoint, error codes, curl examples for each. End with what was explicitly ruled out and why (e.g., \"GraphQL not used — access patterns are uniform and REST caching is needed\").\n\n## Delivery\n\nIf output exceeds the 40-line CLI budget, invoke `\u002Fatlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.\n",{"name":5,"tags":61,"author":64,"license":15,"version":65,"description":7,"allowed-tools":66,"compatibility":67},[62,63,33],"engineering","backend","tonone-ai \u003Chello@tonone.ai>","0.6.4","Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion","Designed for Claude Code","main","d5998d31415790d88781b1eebf9bd0694f7c5d93","team\u002Fspine\u002Fskills\u002Fspine-api",11,"https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone","https:\u002F\u002Fsecond.tonone.ai","https:\u002F\u002Fgithub.com\u002Ftonone-ai","https:\u002F\u002Ftonone.ai","Founded by @thisisfatih","2026-11-11 05:05:57",{"source":8,"skillName":5,"commands":79,"prompt":89,"zipAvailable":90},[80,83,86],{"tool":81,"command":82},"npx","npx skills add tonone-ai\u002Ftonone --skill spine-api",{"tool":84,"command":85},"bunx","bunx skills add tonone-ai\u002Ftonone --skill spine-api",{"tool":87,"command":88},"pnpm","pnpm dlx skills add tonone-ai\u002Ftonone --skill spine-api","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fteam\u002Fspine\u002Fskills\u002Fspine-api\u002FSKILL.md",true,[92],{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":97},"SKILL.md.tmpl","OTHER","其他",8009,"https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fteam\u002Fspine\u002Fskills\u002Fspine-api\u002FSKILL.md.tmpl",[99,107,114,119,124,131],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":106},"01M72QSK7R99K8FWYFNYTXJGR2","helm-autoplan","Chained brief-to-decision pipeline. Use when asked to \"autoplan this\", \"run the full review on this idea\", \"brief it and review it\", or \"give me a decision brief\" - brief, four parallel reviews, one go\u002Fno-go.","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fteam\u002Fhelm\u002Fskills\u002Fhelm-autoplan\u002FSKILL.md",[],[],"2026-11-10 22:39:42",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":106},"01M72Q6V4CB8E877RT5KJRSSB7","apex-second-opinion","Optional cross-model review of a diff or plan through an external CLI (codex, gemini, llm) already on PATH, with redaction and per-run consent. Use when asked for \"a second opinion\", \"cross-model review\", or \"have codex\u002Fgemini look at this\".","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fteam\u002Fapex\u002Fskills\u002Fapex-second-opinion\u002FSKILL.md",[],[],{"skillNo":115,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":106},"01M72PDNJ3NS66X4QZ6AM5BG91","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fskills\u002Fhelm-autoplan\u002FSKILL.md",[],[],{"skillNo":120,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":106},"01M72NV58FG71X4Y7H8E6W721A","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fskills\u002Fapex-second-opinion\u002FSKILL.md",[],[],{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":106},"01M72NEBG81JH7YNSDXYT8NHHE","helm-office-hours","Forcing-function intake before any brief. Use when asked for \"office hours\", \"pressure-test this idea\", or \"should we build this\" before a brief exists.","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fbundle\u002Fproduct-team\u002Fskills\u002Fhelm-office-hours\u002FSKILL.md",[],[],{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":106},"01M72NE7AS597YW6999C56CESR","helm-init","Short interview that writes PRODUCT.md, the durable product truth other skills read. Use when asked to \"init product\", \"write PRODUCT.md\", or \"set up product context\". Prefills from README and repo, asks max 6 questions.","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fbundle\u002Fproduct-team\u002Fskills\u002Fhelm-init\u002FSKILL.md",[],[]]