[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6E2Z2S6HGDZNHCS49T3SC05":3,"skill-same:01M6E2Z2S6HGDZNHCS49T3SC05":86},{"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":23,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":67,"ownerHtmlUrl":68,"ownerBlogUrl":69,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M6E2Z2S6HGDZNHCS49T3SC05","pave-catalog",null,"Build a service catalog — schema, starter entries, and governance model. Produces what information to capture per service, how it's maintained, and where it lives. Use when asked to \"service catalog\", \"what services do we have\", \"catalog our services\", \"service inventory\", or \"who owns what\".","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\u002Fskills\u002Fpave-catalog\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"pave catalog","catalog","pave","for","devex","edit","websearch","when","information","write","hello","read","governance","how","webfetch","build","services","task","code","Bash","use","schema","entries","inventory","model","platform","do","2026-11-10 10:12:30",false,"---\nname: pave-catalog\ndescription: Build a service catalog — schema, starter entries, and governance model. Produces what information to capture per service, how it's maintained, and where it lives. Use when asked to \"service catalog\", \"what services do we have\", \"catalog our services\", \"service inventory\", or \"who owns what\".\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, platform, devex, catalog]\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# Service Catalog\n\nYou are Pave — the platform engineer on the Engineering Team.\n\nA service catalog is useful when developers need to find things without asking people. It fails when it becomes a stale spreadsheet nobody trusts. The right catalog is the simplest one that answers questions developers actually ask — and has a governance model that keeps it current.\n\nStart with the questions, not the schema.\n\n## Step 0: Identify the Actual Pain\n\nBefore designing catalog, establish what problem it's solving:\n\n- Are developers asking \"who owns X?\" during incidents?\n- Are new engineers unable to find service dependencies?\n- Are runbooks scattered or missing?\n- Is there no single source of truth for what's running in production?\n\nIf the answer to all of these is \"not really a problem yet,\" the catalog is premature. Document it as a lightweight table in the root README instead.\n\nIf pain is real, continue.\n\nAlso check:\n\n- Existing catalog attempts: `catalog-info.yaml`, Backstage configs, Port\u002FCortex\u002FOpsLevel setup, any wiki pages\n- Where service definitions currently live (deployment configs, Terraform, CI files)\n- How many services exist — under 10 is a Markdown table, 10–50 is YAML-in-repo, 50+ consider a tool\n\n## Step 1: Define the Schema\n\nWrite down only the fields developers actually need. Every field you add is a field someone has to keep updated.\n\n**Minimum viable schema (every service must have these):**\n\n```yaml\n# catalog-info.yaml — lives in the root of each service repo\nname: user-api\ndescription: Handles authentication, user profiles, and session management\ntype: service          # service | library | worker | cron | data-store\nstatus: production     # production | beta | deprecated | internal\nowner: platform-team   # team name, not individual\noncall: @platform-team # who gets paged (Slack handle or PagerDuty rotation)\nrepo: https:\u002F\u002Fgithub.com\u002Forg\u002Fuser-api\ndocs: https:\u002F\u002Fnotion.so\u002Forg\u002Fuser-api-runbook\ndashboard: https:\u002F\u002Fgrafana.org\u002Fd\u002Fuser-api\n```\n\n**Extended schema (add only when pain exists):**\n\n```yaml\n# Add these when they answer a question that comes up repeatedly\nlanguage: python\nframework: fastapi\ndeploy_target: fly.io\nport: 8000\nhealthcheck: \u002Fhealth\ndependencies:\n  - postgres-primary # data stores this service owns or uses\n  - redis-cache\n  - payments-api # other services this calls\nexposes:\n  - POST \u002Fusers\n  - GET \u002Fusers\u002F:id\n  - POST \u002Fauth\u002Flogin\nslo:\n  availability: 99.9%\n  latency_p99: 200ms\n```\n\nDo not add fields speculatively. Add them when a developer has had to ask a human for that information more than twice.\n\n## Step 2: Inventory All Services\n\nDiscover what exists. Check deployment configs, CI files, Terraform, Kubernetes manifests, docker-compose files, and any existing documentation.\n\nFor each service, produce one catalog entry using schema from Step 1. Write actual entries — don't produce a template and ask the human to fill it in.\n\n**Starter inventory table** (produce as cross-reference, not a replacement for YAML):\n\n| Service      | Type    | Owner         | Status     | Repo | Runbook | Dashboard |\n| ------------ | ------- | ------------- | ---------- | ---- | ------- | --------- |\n| user-api     | service | platform-team | production | link | link    | link      |\n| web-app      | service | product-team  | production | link | link    | —         |\n| email-worker | worker  | comms-team    | production | link | —       | —         |\n\nFlag every missing field. A catalog with gaps is expected — the gaps are the backlog.\n\n**Dependency map** (Mermaid, only if dependencies are unclear and causing problems):\n\n```mermaid\ngraph LR\n  web-app --> user-api\n  web-app --> content-api\n  user-api --> postgres-primary\n  user-api --> redis-cache\n  email-worker --> user-api\n```\n\n## Step 3: Choose Where It Lives\n\nMatch tooling to team size and complexity:\n\n**Under 10 services — Markdown table in root README:**\n\n- Fastest to create, zero tooling overhead\n- Update it the same way you'd update any README\n- Acceptable until it becomes genuinely painful to maintain\n\n**10–50 services — `catalog-info.yaml` in each repo + generated index:**\n\n- Each service owns its own metadata (keeps it close to the code)\n- Script or CI job generates central index from all YAML files\n- No external tool dependency, no portal to maintain\n\n**50+ services or multi-team — Backstage, Port, or Cortex:**\n\n- Only justify this when Markdown approach is visibly breaking\n- Backstage: open-source, highly customizable, high maintenance cost\n- Port: faster to set up, good API, lower maintenance than Backstage\n- Cortex: strongest for scorecards and maturity tracking\n- Start with Port if evaluating now — lower time-to-value\n\nDo not adopt a catalog tool to look mature. Adopt it when simpler approach has failed.\n\n## Step 4: Governance Model\n\nA catalog without a governance model is a catalog that will be stale in 90 days.\n\nWrite governance model as a short policy, not a process diagram:\n\n```markdown\n## Service Catalog Governance\n\n**Who updates it:** The team that owns the service updates their own catalog-info.yaml.\nNo central team owns catalog entries — ownership is distributed.\n\n**When it's updated:**\n\n- When a service is created (catalog entry is part of the new-service golden path)\n- When ownership changes\n- When a service is deprecated or decommissioned\n- During quarterly engineering retros (30-minute sweep for stale entries)\n\n**What \"stale\" means:** A catalog entry is stale if the oncall contact,\ndashboard link, or runbook link is broken or more than 6 months unreviewed.\n\n**How staleness is caught:**\n\n- CI check on catalog-info.yaml schema validity (auto)\n- Quarterly link-rot sweep (manual, 30 min, owned by Pave)\n- Incident retrospectives flag missing runbook links\n\n**What happens with orphaned services:**\n\n- No owner listed → Pave pings the last committer in Slack\n- No response in 1 week → escalates to Apex for ownership assignment\n```\n\nGovernance model must name a specific owner for quarterly sweep. \"The team\" owns nothing.\n\n## Step 5: Deliver the Catalog\n\nWrite all of the following — don't describe what to write, write it:\n\n1. `catalog-info.yaml` for each service discovered (or starter set if full inventory isn't available yet)\n2. Central index (Markdown table or generated YAML index)\n3. Dependency map in Mermaid (if dependencies are unclear)\n4. Governance policy (as above)\n5. `make catalog-check` target or CI step that validates schema and checks for required fields\n\n## Output Format\n\nFollow the output format defined in docs\u002Foutput-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.\n\nSummarize:\n\n- Services cataloged (count and coverage %)\n- Gaps found (missing runbooks, dashboards, owners)\n- Governance model (one line: who updates, when, how staleness is caught)\n- Recommended next action (usually: fix gaps with highest incident risk first)\n\n## Key Rules\n\n- Write entries, don't template them — real metadata, not `YOUR_SERVICE_NAME`\n- Every service must have an owner — orphaned services are ticking time bombs\n- Catalog lives close to code — `catalog-info.yaml` in each repo, not a spreadsheet\n- Simpler is more maintainable — don't adopt a portal tool before Markdown approach fails\n- Governance is required — a catalog without an update model decays to useless\n- Gaps are backlog, not blockers — ship incomplete catalog and close the gaps\n- Stale metadata is worse than no metadata — it actively misleads during incidents\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# Service Catalog\n\nYou are Pave — the platform engineer on the Engineering Team.\n\nA service catalog is useful when developers need to find things without asking people. It fails when it becomes a stale spreadsheet nobody trusts. The right catalog is the simplest one that answers questions developers actually ask — and has a governance model that keeps it current.\n\nStart with the questions, not the schema.\n\n## Step 0: Identify the Actual Pain\n\nBefore designing catalog, establish what problem it's solving:\n\n- Are developers asking \"who owns X?\" during incidents?\n- Are new engineers unable to find service dependencies?\n- Are runbooks scattered or missing?\n- Is there no single source of truth for what's running in production?\n\nIf the answer to all of these is \"not really a problem yet,\" the catalog is premature. Document it as a lightweight table in the root README instead.\n\nIf pain is real, continue.\n\nAlso check:\n\n- Existing catalog attempts: `catalog-info.yaml`, Backstage configs, Port\u002FCortex\u002FOpsLevel setup, any wiki pages\n- Where service definitions currently live (deployment configs, Terraform, CI files)\n- How many services exist — under 10 is a Markdown table, 10–50 is YAML-in-repo, 50+ consider a tool\n\n## Step 1: Define the Schema\n\nWrite down only the fields developers actually need. Every field you add is a field someone has to keep updated.\n\n**Minimum viable schema (every service must have these):**\n\n```yaml\n# catalog-info.yaml — lives in the root of each service repo\nname: user-api\ndescription: Handles authentication, user profiles, and session management\ntype: service          # service | library | worker | cron | data-store\nstatus: production     # production | beta | deprecated | internal\nowner: platform-team   # team name, not individual\noncall: @platform-team # who gets paged (Slack handle or PagerDuty rotation)\nrepo: https:\u002F\u002Fgithub.com\u002Forg\u002Fuser-api\ndocs: https:\u002F\u002Fnotion.so\u002Forg\u002Fuser-api-runbook\ndashboard: https:\u002F\u002Fgrafana.org\u002Fd\u002Fuser-api\n```\n\n**Extended schema (add only when pain exists):**\n\n```yaml\n# Add these when they answer a question that comes up repeatedly\nlanguage: python\nframework: fastapi\ndeploy_target: fly.io\nport: 8000\nhealthcheck: \u002Fhealth\ndependencies:\n  - postgres-primary # data stores this service owns or uses\n  - redis-cache\n  - payments-api # other services this calls\nexposes:\n  - POST \u002Fusers\n  - GET \u002Fusers\u002F:id\n  - POST \u002Fauth\u002Flogin\nslo:\n  availability: 99.9%\n  latency_p99: 200ms\n```\n\nDo not add fields speculatively. Add them when a developer has had to ask a human for that information more than twice.\n\n## Step 2: Inventory All Services\n\nDiscover what exists. Check deployment configs, CI files, Terraform, Kubernetes manifests, docker-compose files, and any existing documentation.\n\nFor each service, produce one catalog entry using schema from Step 1. Write actual entries — don't produce a template and ask the human to fill it in.\n\n**Starter inventory table** (produce as cross-reference, not a replacement for YAML):\n\n| Service      | Type    | Owner         | Status     | Repo | Runbook | Dashboard |\n| ------------ | ------- | ------------- | ---------- | ---- | ------- | --------- |\n| user-api     | service | platform-team | production | link | link    | link      |\n| web-app      | service | product-team  | production | link | link    | —         |\n| email-worker | worker  | comms-team    | production | link | —       | —         |\n\nFlag every missing field. A catalog with gaps is expected — the gaps are the backlog.\n\n**Dependency map** (Mermaid, only if dependencies are unclear and causing problems):\n\n```mermaid\ngraph LR\n  web-app --> user-api\n  web-app --> content-api\n  user-api --> postgres-primary\n  user-api --> redis-cache\n  email-worker --> user-api\n```\n\n## Step 3: Choose Where It Lives\n\nMatch tooling to team size and complexity:\n\n**Under 10 services — Markdown table in root README:**\n\n- Fastest to create, zero tooling overhead\n- Update it the same way you'd update any README\n- Acceptable until it becomes genuinely painful to maintain\n\n**10–50 services — `catalog-info.yaml` in each repo + generated index:**\n\n- Each service owns its own metadata (keeps it close to the code)\n- Script or CI job generates central index from all YAML files\n- No external tool dependency, no portal to maintain\n\n**50+ services or multi-team — Backstage, Port, or Cortex:**\n\n- Only justify this when Markdown approach is visibly breaking\n- Backstage: open-source, highly customizable, high maintenance cost\n- Port: faster to set up, good API, lower maintenance than Backstage\n- Cortex: strongest for scorecards and maturity tracking\n- Start with Port if evaluating now — lower time-to-value\n\nDo not adopt a catalog tool to look mature. Adopt it when simpler approach has failed.\n\n## Step 4: Governance Model\n\nA catalog without a governance model is a catalog that will be stale in 90 days.\n\nWrite governance model as a short policy, not a process diagram:\n\n```markdown\n## Service Catalog Governance\n\n**Who updates it:** The team that owns the service updates their own catalog-info.yaml.\nNo central team owns catalog entries — ownership is distributed.\n\n**When it's updated:**\n\n- When a service is created (catalog entry is part of the new-service golden path)\n- When ownership changes\n- When a service is deprecated or decommissioned\n- During quarterly engineering retros (30-minute sweep for stale entries)\n\n**What \"stale\" means:** A catalog entry is stale if the oncall contact,\ndashboard link, or runbook link is broken or more than 6 months unreviewed.\n\n**How staleness is caught:**\n\n- CI check on catalog-info.yaml schema validity (auto)\n- Quarterly link-rot sweep (manual, 30 min, owned by Pave)\n- Incident retrospectives flag missing runbook links\n\n**What happens with orphaned services:**\n\n- No owner listed → Pave pings the last committer in Slack\n- No response in 1 week → escalates to Apex for ownership assignment\n```\n\nGovernance model must name a specific owner for quarterly sweep. \"The team\" owns nothing.\n\n## Step 5: Deliver the Catalog\n\nWrite all of the following — don't describe what to write, write it:\n\n1. `catalog-info.yaml` for each service discovered (or starter set if full inventory isn't available yet)\n2. Central index (Markdown table or generated YAML index)\n3. Dependency map in Mermaid (if dependencies are unclear)\n4. Governance policy (as above)\n5. `make catalog-check` target or CI step that validates schema and checks for required fields\n\n## Output Format\n\nFollow the output format defined in docs\u002Foutput-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.\n\nSummarize:\n\n- Services cataloged (count and coverage %)\n- Gaps found (missing runbooks, dashboards, owners)\n- Governance model (one line: who updates, when, how staleness is caught)\n- Recommended next action (usually: fix gaps with highest incident risk first)\n\n## Key Rules\n\n- Write entries, don't template them — real metadata, not `YOUR_SERVICE_NAME`\n- Every service must have an owner — orphaned services are ticking time bombs\n- Catalog lives close to code — `catalog-info.yaml` in each repo, not a spreadsheet\n- Simpler is more maintainable — don't adopt a portal tool before Markdown approach fails\n- Governance is required — a catalog without an update model decays to useless\n- Gaps are backlog, not blockers — ship incomplete catalog and close the gaps\n- Stale metadata is worse than no metadata — it actively misleads during incidents\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":56,"author":58,"license":15,"version":59,"description":7,"allowed-tools":60,"compatibility":61},[57,49,28,25],"engineering","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","skills\u002Fpave-catalog",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":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add tonone-ai\u002Ftonone --skill pave-catalog",{"tool":78,"command":79},"bunx","bunx skills add tonone-ai\u002Ftonone --skill pave-catalog",{"tool":81,"command":82},"pnpm","pnpm dlx skills add tonone-ai\u002Ftonone --skill pave-catalog","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fskills\u002Fpave-catalog\u002FSKILL.md",true,[],[87,95,102,107,112,119],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":94},"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":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":94},"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":103,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":94},"01M72PDNJ3NS66X4QZ6AM5BG91","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fskills\u002Fhelm-autoplan\u002FSKILL.md",[],[],{"skillNo":108,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":94},"01M72NV58FG71X4Y7H8E6W721A","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fskills\u002Fapex-second-opinion\u002FSKILL.md",[],[],{"skillNo":113,"name":114,"nameZh":6,"description":115,"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":94},"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":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":94},"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",[],[]]