[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M72NDAV23E9S8F3EH50AR1KD":3,"skill-same:01M72NDAV23E9S8F3EH50AR1KD":57},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":36,"repositoryHtmlUrl":37,"repositoryHomepageUrl":38,"ownerHtmlUrl":39,"ownerBlogUrl":40,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M72NDAV23E9S8F3EH50AR1KD","form-document",null,"Derive or refresh DESIGN.md from shipped code and tokens, not intentions. Use when asked to \"document the design system\", \"write DESIGN.md\", or \"refresh DESIGN.md\". Frequency-ranks real values, flags one-offs as drift, diffs instead of overwriting.","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\u002Fbundle\u002Fproduct-team\u002Fskills\u002Fform-document\u002FSKILL.md",[],[],"2026-11-10 22:39:42",false,"---\nname: form-document\ndescription: Derive or refresh DESIGN.md from shipped code and tokens, not intentions. Use when asked to \"document the design system\", \"write DESIGN.md\", or \"refresh DESIGN.md\". Frequency-ranks real values, flags one-offs as drift, diffs instead of overwriting.\nallowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion\nversion: 0.1.0\nauthor: tonone-ai \u003Chello@tonone.ai>\nlicense: MIT\ncompatibility: Designed for Claude Code\ntags: [product, design, design-system, documentation]\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# form-document — DESIGN.md From Shipped Code\n\nYou are Form — the visual designer on the Product Team. This skill records the design system that actually ships. Code is the source of truth; DESIGN.md is its readable, machine-checkable shadow. Never write a value that is not in code.\n\nFollow the output format defined in docs\u002Foutput-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.\n\nFormat spec: `docs\u002Fdesign-md.md` (the one DESIGN.md format; this skill writes the code-derived sections).\n\nPairs with `PRODUCT.md` (durable product truth, written by `\u002Fhelm-init`): PRODUCT.md says why and for whom, DESIGN.md says how it looks. Read both before judging a design. Consumers of DESIGN.md: `\u002Fform-lint` (design-system-drift rules), `\u002Fform-brief`, `\u002Fform-critique`, `\u002Fform-audit`, `\u002Fprism-ui`, `\u002Fprism-component`.\n\n## Steps\n\n### Step 0: Positioning check\n\nRead `PRODUCT.md` if present. If missing, note it and suggest `\u002Fhelm-init`; do not block. Existing DESIGN.md? Read it fully first. That selects refresh mode (Step 5) over create mode.\n\n### Step 1: Locate token sources\n\nGlob, in priority order. Record every hit; the first that defines a value owns it.\n\n- CSS custom properties: `:root`, `[data-theme]`, `@media (prefers-color-scheme)` blocks in `*.css`, `*.scss`\n- Tailwind v4 `@theme` blocks; Tailwind v3 `tailwind.config.*` (`theme.extend`)\n- Tokens JSON: `tokens.json`, `design-tokens\u002F**`, style-dictionary output\n- Theme files: `theme.ts`, `theme.js`, `styled-system`, MUI\u002FChakra\u002Fvanilla-extract themes\n- Font loading: `@font-face`, `next\u002Ffont`, `\u003Clink>` to font hosts\n\nNo token layer at all? Say so. Fall back to Step 2 raw-value extraction and flag \"no token layer\" as the top finding.\n\n### Step 2: Extract what is actually used\n\nUse Grep over UI source (`.tsx .jsx .vue .svelte .html .css .scss`), skip `node_modules`, build output, and vendored dirs. For each category count occurrences and distinct files:\n\n- Colors: hex, `rgb()`, `hsl()`, `oklch()`, `var(--*)` references. Resolve tokens to values in both modes.\n- Type: font families, sizes, weights, line-heights, letter-spacing.\n- Spacing: padding, margin, gap values; infer the base step.\n- Radius, shadow, border widths.\n- Motion: durations, easings, `@keyframes`.\n\nRank by frequency. A value used once, or only inline and never via a token, is a drift candidate. Group near-duplicates (a color within a few units of a token) as probable drift of that token.\n\n### Step 3: Read the components\n\nRead 3-6 representative files from the component dir (button, input, card, nav, plus the most-reused). Record patterns that repeat: states (hover, focus, disabled), radius per component, elevation or border choice, density. Do not generalize from one file.\n\n### Step 4: Draft DESIGN.md\n\nFixed layout. Frontmatter is the machine-readable token block; body sections follow in this order, omit a section rather than invent content for it.\n\n```\n---\nname: \u003Cproduct>\ndescription: \u003Cone line>\ncolors:                      # key = semantic or existing token name\n  \u003Ctoken>:\n    value: \"\u003Ccss color>\"     # src: path\u002Fto\u002Ffile.css:LINE\ntypography:\n  \u003Crole>: { fontFamily, fontSize, fontWeight, lineHeight, letterSpacing }\nrounded:  { \u003Cstep>: \"\u003Cvalue>\" }\nspacing:  { \u003Cstep>: \"\u003Cvalue>\" }\ncomponents:                  # backgroundColor, textColor, rounded, padding; {colors.x} refs\n  \u003Cname>: { ... }\nelevation: { \u003Cstep>: \"\u003Cbox-shadow>\" }   # optional extension\nmotion:    { \u003Cstep>: \"\u003Cduration easing>\" }  # optional extension\n---\n# Design System: \u003Cproduct>\n## Overview            north star in 2-4 sentences, drawn from PRODUCT.md and the code\n## Colors              Primary \u002F Neutral \u002F Semantic, each value with role and use rule\n## Typography          families, scale, hierarchy\n## Layout              spacing base, grid, breakpoints\n## Elevation & Depth   shadow vocabulary, or \"flat\" if that is what ships\n## Shapes              radius vocabulary\n## Components          one short block per recurring component\n## Do's and Don'ts     only rules the code already obeys, plus confirmed rejections\n## Drift Candidates    one-offs and near-duplicates, with file:line\n```\n\nRules:\n\n- Sections 1-8 match the existing platform `DESIGN.md` order (full spec incl. optional sections 9-11: `docs\u002Fdesign-md.md`). Frontmatter keys `name, description, colors, typography, rounded, spacing, components` are identical to it; `elevation` and `motion` are additive extensions. Do not rename existing keys.\n- Every value carries its source as a trailing `# src: file:line` comment in the frontmatter, or `(file:line)` in prose.\n- Token names stay as the code names them (`ember`, not a renamed `color-accent-1`). Semantic names for new entries only.\n- Hex, px and rem literals in DESIGN.md are the allow-list that `\u002Fform-lint` parses: every `#hex` and every `px`\u002F`rem` number anywhere in the file counts as sanctioned. So drift candidates must never be written as `#hex` or `12px`. Write them without the hash (`f3a21b`) and spell units out (`13 pixels`). Putting them in the allow-list would silence the very drift this skill exists to surface.\n- Use `{colors.x}` token refs inside `components`; primitives never reference primitives.\n- Dark mode: explicit values from the dark block, never inverted light values. Missing dark block: say \"no dark mode shipped\".\n\nQualitative text (Overview, Named Rules, Don'ts) is the one place judgment lives. Draft it from evidence (what the code does consistently), then confirm in one AskUserQuestion round at most. Mark unconfirmed prose `[assumed: ...]`.\n\n### Step 5: Write or refresh\n\n- **No DESIGN.md:** write it at repo root. Show a 10-line summary, not the file.\n- **DESIGN.md exists:** never overwrite. Compute a diff by section: added values, changed values, values in the file no longer in code (stale), drift candidates new since last run. Show the diff, then apply only what the user approves. Preserve hand-written Overview, Named Rules, and Do's and Don'ts verbatim unless code contradicts them; if so, flag, do not rewrite. If the existing file uses the legacy `\u002Fform-brief` headings (Visual Theme & Atmosphere, Color Palette & Roles, Typography Rules, ...), tolerate them when reading and migrate to the unified headings per `docs\u002Fdesign-md.md` as part of the diff you show. Preserve brief-only frontmatter keys (`form_kind`, `visitor_mode`, `mood`, `direction`) and the Design dials block; the lint reads hex\u002Fpx\u002Frem literals regardless of headings.\n- Never invent. If a section has no evidence in code, leave it out or write `[not found in code]`.\n\n### Step 6: Verify\n\nRun the drift lint to confirm the doc and code agree:\n\n```bash\nnode \"${CLAUDE_PLUGIN_ROOT}\u002Fteam\u002Fform\u002Fscripts\u002Fdesign-lint\u002Fdesign-lint.js\" src\u002F --tier all\n```\n\n`design-system-drift` hits are either real drift (fix code via `\u002Fform-polish` or promote the value into DESIGN.md deliberately) or an extraction miss (fix the doc). Optional: skip if no `node`.\n\n## Output\n\nBox header `FORM ── form-document`, one-line verdict (created \u002F refreshed \u002F no change), counts: tokens documented, token sources, drift candidates. Findings: `▲ WARNING` for drift clusters and a missing token layer, `● INFO` for stale values. Next steps: `\u002Fform-lint`, `\u002Fform-critique`. Under 40 lines.\n\nIf output exceeds the 40-line CLI budget, invoke `\u002Fatlas-report` with the full diff and drift list. CLI is the receipt: box header, verdict, top 3 findings, report path.\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# form-document — DESIGN.md From Shipped Code\n\nYou are Form — the visual designer on the Product Team. This skill records the design system that actually ships. Code is the source of truth; DESIGN.md is its readable, machine-checkable shadow. Never write a value that is not in code.\n\nFollow the output format defined in docs\u002Foutput-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.\n\nFormat spec: `docs\u002Fdesign-md.md` (the one DESIGN.md format; this skill writes the code-derived sections).\n\nPairs with `PRODUCT.md` (durable product truth, written by `\u002Fhelm-init`): PRODUCT.md says why and for whom, DESIGN.md says how it looks. Read both before judging a design. Consumers of DESIGN.md: `\u002Fform-lint` (design-system-drift rules), `\u002Fform-brief`, `\u002Fform-critique`, `\u002Fform-audit`, `\u002Fprism-ui`, `\u002Fprism-component`.\n\n## Steps\n\n### Step 0: Positioning check\n\nRead `PRODUCT.md` if present. If missing, note it and suggest `\u002Fhelm-init`; do not block. Existing DESIGN.md? Read it fully first. That selects refresh mode (Step 5) over create mode.\n\n### Step 1: Locate token sources\n\nGlob, in priority order. Record every hit; the first that defines a value owns it.\n\n- CSS custom properties: `:root`, `[data-theme]`, `@media (prefers-color-scheme)` blocks in `*.css`, `*.scss`\n- Tailwind v4 `@theme` blocks; Tailwind v3 `tailwind.config.*` (`theme.extend`)\n- Tokens JSON: `tokens.json`, `design-tokens\u002F**`, style-dictionary output\n- Theme files: `theme.ts`, `theme.js`, `styled-system`, MUI\u002FChakra\u002Fvanilla-extract themes\n- Font loading: `@font-face`, `next\u002Ffont`, `\u003Clink>` to font hosts\n\nNo token layer at all? Say so. Fall back to Step 2 raw-value extraction and flag \"no token layer\" as the top finding.\n\n### Step 2: Extract what is actually used\n\nUse Grep over UI source (`.tsx .jsx .vue .svelte .html .css .scss`), skip `node_modules`, build output, and vendored dirs. For each category count occurrences and distinct files:\n\n- Colors: hex, `rgb()`, `hsl()`, `oklch()`, `var(--*)` references. Resolve tokens to values in both modes.\n- Type: font families, sizes, weights, line-heights, letter-spacing.\n- Spacing: padding, margin, gap values; infer the base step.\n- Radius, shadow, border widths.\n- Motion: durations, easings, `@keyframes`.\n\nRank by frequency. A value used once, or only inline and never via a token, is a drift candidate. Group near-duplicates (a color within a few units of a token) as probable drift of that token.\n\n### Step 3: Read the components\n\nRead 3-6 representative files from the component dir (button, input, card, nav, plus the most-reused). Record patterns that repeat: states (hover, focus, disabled), radius per component, elevation or border choice, density. Do not generalize from one file.\n\n### Step 4: Draft DESIGN.md\n\nFixed layout. Frontmatter is the machine-readable token block; body sections follow in this order, omit a section rather than invent content for it.\n\n```\n---\nname: \u003Cproduct>\ndescription: \u003Cone line>\ncolors:                      # key = semantic or existing token name\n  \u003Ctoken>:\n    value: \"\u003Ccss color>\"     # src: path\u002Fto\u002Ffile.css:LINE\ntypography:\n  \u003Crole>: { fontFamily, fontSize, fontWeight, lineHeight, letterSpacing }\nrounded:  { \u003Cstep>: \"\u003Cvalue>\" }\nspacing:  { \u003Cstep>: \"\u003Cvalue>\" }\ncomponents:                  # backgroundColor, textColor, rounded, padding; {colors.x} refs\n  \u003Cname>: { ... }\nelevation: { \u003Cstep>: \"\u003Cbox-shadow>\" }   # optional extension\nmotion:    { \u003Cstep>: \"\u003Cduration easing>\" }  # optional extension\n---\n# Design System: \u003Cproduct>\n## Overview            north star in 2-4 sentences, drawn from PRODUCT.md and the code\n## Colors              Primary \u002F Neutral \u002F Semantic, each value with role and use rule\n## Typography          families, scale, hierarchy\n## Layout              spacing base, grid, breakpoints\n## Elevation & Depth   shadow vocabulary, or \"flat\" if that is what ships\n## Shapes              radius vocabulary\n## Components          one short block per recurring component\n## Do's and Don'ts     only rules the code already obeys, plus confirmed rejections\n## Drift Candidates    one-offs and near-duplicates, with file:line\n```\n\nRules:\n\n- Sections 1-8 match the existing platform `DESIGN.md` order (full spec incl. optional sections 9-11: `docs\u002Fdesign-md.md`). Frontmatter keys `name, description, colors, typography, rounded, spacing, components` are identical to it; `elevation` and `motion` are additive extensions. Do not rename existing keys.\n- Every value carries its source as a trailing `# src: file:line` comment in the frontmatter, or `(file:line)` in prose.\n- Token names stay as the code names them (`ember`, not a renamed `color-accent-1`). Semantic names for new entries only.\n- Hex, px and rem literals in DESIGN.md are the allow-list that `\u002Fform-lint` parses: every `#hex` and every `px`\u002F`rem` number anywhere in the file counts as sanctioned. So drift candidates must never be written as `#hex` or `12px`. Write them without the hash (`f3a21b`) and spell units out (`13 pixels`). Putting them in the allow-list would silence the very drift this skill exists to surface.\n- Use `{colors.x}` token refs inside `components`; primitives never reference primitives.\n- Dark mode: explicit values from the dark block, never inverted light values. Missing dark block: say \"no dark mode shipped\".\n\nQualitative text (Overview, Named Rules, Don'ts) is the one place judgment lives. Draft it from evidence (what the code does consistently), then confirm in one AskUserQuestion round at most. Mark unconfirmed prose `[assumed: ...]`.\n\n### Step 5: Write or refresh\n\n- **No DESIGN.md:** write it at repo root. Show a 10-line summary, not the file.\n- **DESIGN.md exists:** never overwrite. Compute a diff by section: added values, changed values, values in the file no longer in code (stale), drift candidates new since last run. Show the diff, then apply only what the user approves. Preserve hand-written Overview, Named Rules, and Do's and Don'ts verbatim unless code contradicts them; if so, flag, do not rewrite. If the existing file uses the legacy `\u002Fform-brief` headings (Visual Theme & Atmosphere, Color Palette & Roles, Typography Rules, ...), tolerate them when reading and migrate to the unified headings per `docs\u002Fdesign-md.md` as part of the diff you show. Preserve brief-only frontmatter keys (`form_kind`, `visitor_mode`, `mood`, `direction`) and the Design dials block; the lint reads hex\u002Fpx\u002Frem literals regardless of headings.\n- Never invent. If a section has no evidence in code, leave it out or write `[not found in code]`.\n\n### Step 6: Verify\n\nRun the drift lint to confirm the doc and code agree:\n\n```bash\nnode \"${CLAUDE_PLUGIN_ROOT}\u002Fteam\u002Fform\u002Fscripts\u002Fdesign-lint\u002Fdesign-lint.js\" src\u002F --tier all\n```\n\n`design-system-drift` hits are either real drift (fix code via `\u002Fform-polish` or promote the value into DESIGN.md deliberately) or an extraction miss (fix the doc). Optional: skip if no `node`.\n\n## Output\n\nBox header `FORM ── form-document`, one-line verdict (created \u002F refreshed \u002F no change), counts: tokens documented, token sources, drift candidates. Findings: `▲ WARNING` for drift clusters and a missing token layer, `● INFO` for stale values. Next steps: `\u002Fform-lint`, `\u002Fform-critique`. Under 40 lines.\n\nIf output exceeds the 40-line CLI budget, invoke `\u002Fatlas-report` with the full diff and drift list. CLI is the receipt: box header, verdict, top 3 findings, report path.\n",{"name":5,"tags":24,"author":29,"license":15,"version":30,"description":7,"allowed-tools":31,"compatibility":32},[25,26,27,28],"product","design","design-system","documentation","tonone-ai \u003Chello@tonone.ai>","0.1.0","Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion","Designed for Claude Code","main","117b48ffd82ffc8429954da42f2bf062e84e1b26","bundle\u002Fproduct-team\u002Fskills\u002Fform-document",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":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add tonone-ai\u002Ftonone --skill form-document",{"tool":49,"command":50},"bunx","bunx skills add tonone-ai\u002Ftonone --skill form-document",{"tool":52,"command":53},"pnpm","pnpm dlx skills add tonone-ai\u002Ftonone --skill form-document","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fbundle\u002Fproduct-team\u002Fskills\u002Fform-document\u002FSKILL.md",true,[],[58,65,72,77,82,89],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"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",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"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":73,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M72PDNJ3NS66X4QZ6AM5BG91","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fskills\u002Fhelm-autoplan\u002FSKILL.md",[],[],{"skillNo":78,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M72NV58FG71X4Y7H8E6W721A","https:\u002F\u002Fgithub.com\u002Ftonone-ai\u002Ftonone\u002Fblob\u002Fmain\u002Fskills\u002Fapex-second-opinion\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"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":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":19},"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",[],[]]