[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MN76PCWHJD6YZAXZ8FJZBS":3,"skill-same:01M6MN76PCWHJD6YZAXZ8FJZBS":70},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6MN76PCWHJD6YZAXZ8FJZBS","create-slide",null,"Use this skill when the user wants to create, draft, author, or generate new slides \u002F a presentation in this open-slide repo. Triggers on phrases like \"make slides about X\", \"create a presentation\", \"draft slides for\", \"new slide\", or when the user asks to add content under `slides\u002F`. Do NOT use for editing the framework itself — only for authoring content inside `slides\u002F\u003Cid>\u002F`.","arkhe-genesis\u002FArkhe-OS","arkhe-genesis","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272629719?v=4","01M6KJDTSTJD2AD5RFPVZNGYCP","Rafael Oliveira","01M6KJDTXSTA997KDK184EA55A",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Fcreate-slide\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"create slide","create","draft","author","open-slide","for","about","add","id","triggers","authoring","do","only","use","repo","editing","slides","open","content","generate","2026-11-10 10:12:30",false,"---\nname: create-slide\ndescription: Use this skill when the user wants to create, draft, author, or generate new slides \u002F a presentation in this open-slide repo. Triggers on phrases like \"make slides about X\", \"create a presentation\", \"draft slides for\", \"new slide\", or when the user asks to add content under `slides\u002F`. Do NOT use for editing the framework itself — only for authoring content inside `slides\u002F\u003Cid>\u002F`.\n---\n\n# Create a slide in open-slide\n\nThis skill owns the **workflow** for drafting a new deck. The technical reference — file contract, 1920×1080 canvas, type scale, palette, layout, assets — lives in the **`slide-authoring`** skill. Read that skill whenever you need details on *how* a page is structured. This skill assumes you'll consult it before writing code.\n\nYou only write files under `slides\u002F\u003Cid>\u002F`. Never modify `package.json`, `open-slide.config.ts`, or existing slides.\n\n## Step 1 — Pick a theme\n\nList files under `themes\u002F`. If any theme markdown files exist (anything other than `README.md`), call `AskUserQuestion` with each theme id as an option plus a final **\"no theme — design from scratch\"** option.\n\n- If the user picks a theme: read `themes\u002F\u003Cid>.md` end-to-end. The theme's palette, typography, layout, and Title\u002FFooter components are now authoritative — copy them directly into the slide. In Step 2, skip the **aesthetic direction** question (the theme already commits to one direction); you still need the topic itself, so confirm it before moving on. Page count, text density, and motion are independent of theme — ask those normally.\n- If the user picks \"no theme\", or `themes\u002F` is empty (or contains only `README.md`): proceed to Step 2 unchanged.\n\nIf you skip the aesthetic question because a theme was picked, restate the theme name in Step 2 so the user can correct course before you start writing.\n\n## Step 2 — Clarify requirements (MUST ask before writing code)\n\n**Before writing any code, lock in the four key style decisions below via `AskUserQuestion`.** They shape every downstream choice (layout, type scale, asset needs, motion code), so locking them in up front avoids rework. Only skip a question when the user's original message already gave an unambiguous answer for it — and if you skip, restate your assumption so they can correct it.\n\n**Topic comes first.** A meaningful aesthetic recommendation requires knowing what the deck is about. If the user's initial request is thin (\"make me a deck\", \"draft some slides\"), make a *separate* `AskUserQuestion` call first to gather topic, audience, and any draft outline. Skip this only if the topic is already clear from the user's message — in which case restate your reading of the topic in the next call so they can correct course.\n\nThen ask these four in a single `AskUserQuestion` call (multi-question form):\n\n1. **Aesthetic direction** — propose 3 visual directions tailored to *this* topic. Do **not** pull from a fixed preset list. Each option must combine a vibe word + a concrete visual cue (palette, typography, motif) so the user can picture it; bare labels like \"minimal\" or \"corporate\" alone are too vague. The three options should feel meaningfully different from each other — not three flavors of the same idea.\n\n   How options should shift with topic:\n   - *\"Intro to Rust for backend engineers\"* → **rust-orange technical editorial** (warm rust\u002Fcharcoal, mono headings, code-grid layout) · **blueprint dev-doc** (cyan grid on near-black, monospace, schematic feel) · **brutalist terminal** (lime-on-black, ASCII rules, no-nonsense)\n   - *\"Q2 product roadmap for stakeholders\"* → **calm corporate clean** (off-white, single accent, generous whitespace) · **confident editorial** (large display serif, tight grid, one bold accent) · **data-forward dashboard** (charts as hero, muted neutrals + status colors)\n   - *\"Kindergarten parent night\"* → **playful crayon** (paper texture, hand-drawn accents, primary colors) · **soft pastel storybook** (peach\u002Fmint, rounded type, illustrated icons) · **warm photo-led** (full-bleed kid photos, simple captions)\n\n   Mark the option that best fits the topic and audience as \"(Recommended)\" so the user has a sensible default. (`AskUserQuestion` already auto-adds \"Other\" — don't add a generic catch-all yourself.)\n\n2. **Page count** — rough length. Offer brackets: 3–5 (short), 6–10 (standard), 11–20 (deep dive), custom.\n3. **Text density per page** — how much copy lives on each page? Offer: minimal (one line \u002F big number), light (heading + 2–3 bullets), standard (heading + 4–5 bullets or short paragraph), dense (multi-column \u002F detailed). This directly drives type scale and layout.\n4. **Motion** — does the user want CSS\u002FReact animations and transitions, or a fully static deck? Offer: static (no motion), subtle (fades \u002F entrance only), rich (keyframes, staggered reveals, looping visuals). If animated, plan to use CSS `@keyframes` \u002F inline `style` + `useEffect`; no extra libraries.\n\nAfter those four, ask follow-ups **only if still unclear**: brand colors, required assets. Don't pad the conversation with questions already answered.\n\n## Step 3 — Pick a slide id\n\nUse **kebab-case**, short, descriptive. Examples: `rust-intro`, `q2-roadmap`, `team-offsite-2026`. Check `slides\u002F` to avoid collisions.\n\n## Step 4 — Plan the structure\n\nSketch the slide as a list of page roles before writing code. Common page types:\n\n| Role             | Purpose                                       |\n| ---------------- | --------------------------------------------- |\n| Cover            | Title + subtitle, strong visual               |\n| Agenda           | What's coming (3–5 items)                     |\n| Section divider  | Big label between chapters                    |\n| Content          | Heading + 2–5 bullets OR heading + one visual |\n| Big number       | One statistic the size of the canvas          |\n| Quote            | Pull-quote with attribution                   |\n| Comparison       | Two-column before\u002Fafter or A vs B             |\n| Closing          | CTA, thanks, contact                          |\n\n**Rule of thumb**: one idea per page. If you're tempted to put two, split them.\n\nIf the deck topic naturally calls for specific real images the user must supply (product screenshots, team photos, customer dashboards), plan where those go and use `\u003CImagePlaceholder>` from `@open-slide\u002Fcore` — see the **Image placeholders** section in `slide-authoring`. Default is **no placeholders**: only insert one when a real image is genuinely required.\n\n## Step 5 — Commit to a visual direction\n\nPick one coherent palette \u002F type scale \u002F aesthetic and hold it across every page. The full set of constraints (palette structure, type scale, padding, aesthetic options) lives in `slide-authoring` — apply it.\n\n**Default: declare a top-level `export const design: DesignSystem = { … }`** at the top of `index.tsx` (after imports) using the chosen palette \u002F type scale, and reference the values via `var(--osd-X)` from inline styles. This keeps the slide tweakable from the Design panel after generation, which is what the user almost always wants. Only skip the `design` const for a one-off slide whose palette is intentionally locked and not meant to be re-themed — in that case, fall back to the local `palette` constants pattern. The \"Design system\" section of `slide-authoring` covers the format and available tokens.\n\nConsult the `frontend-design` skill for deeper aesthetic guidance if the user wants something bold.\n\n## Step 6 — Write `slides\u002F\u003Cid>\u002Findex.tsx`\n\nRead the **`slide-authoring`** skill before writing — it covers the file contract, canvas rules, type scale, spacing, and asset imports, and it includes a starter template you can copy. Don't duplicate that knowledge here; use it.\n\n## Step 7 — Self-review\n\nRun the checklist in `slide-authoring` (\"Self-review before finishing\"). It covers structural correctness, layout discipline, and asset existence.\n\n## Step 8 — Hand off to the user\n\nTell the user:\n\n- The slide id and file path you created.\n- That the dev server will hot-reload — they can open `http:\u002F\u002Flocalhost:5173\u002Fs\u002F\u003Cid>` (or refresh the home page).\n- If dev isn't running: `pnpm dev` from the repo root.\n\nDon't run the dev server yourself unless asked.\n","# Create a slide in open-slide\n\nThis skill owns the **workflow** for drafting a new deck. The technical reference — file contract, 1920×1080 canvas, type scale, palette, layout, assets — lives in the **`slide-authoring`** skill. Read that skill whenever you need details on *how* a page is structured. This skill assumes you'll consult it before writing code.\n\nYou only write files under `slides\u002F\u003Cid>\u002F`. Never modify `package.json`, `open-slide.config.ts`, or existing slides.\n\n## Step 1 — Pick a theme\n\nList files under `themes\u002F`. If any theme markdown files exist (anything other than `README.md`), call `AskUserQuestion` with each theme id as an option plus a final **\"no theme — design from scratch\"** option.\n\n- If the user picks a theme: read `themes\u002F\u003Cid>.md` end-to-end. The theme's palette, typography, layout, and Title\u002FFooter components are now authoritative — copy them directly into the slide. In Step 2, skip the **aesthetic direction** question (the theme already commits to one direction); you still need the topic itself, so confirm it before moving on. Page count, text density, and motion are independent of theme — ask those normally.\n- If the user picks \"no theme\", or `themes\u002F` is empty (or contains only `README.md`): proceed to Step 2 unchanged.\n\nIf you skip the aesthetic question because a theme was picked, restate the theme name in Step 2 so the user can correct course before you start writing.\n\n## Step 2 — Clarify requirements (MUST ask before writing code)\n\n**Before writing any code, lock in the four key style decisions below via `AskUserQuestion`.** They shape every downstream choice (layout, type scale, asset needs, motion code), so locking them in up front avoids rework. Only skip a question when the user's original message already gave an unambiguous answer for it — and if you skip, restate your assumption so they can correct it.\n\n**Topic comes first.** A meaningful aesthetic recommendation requires knowing what the deck is about. If the user's initial request is thin (\"make me a deck\", \"draft some slides\"), make a *separate* `AskUserQuestion` call first to gather topic, audience, and any draft outline. Skip this only if the topic is already clear from the user's message — in which case restate your reading of the topic in the next call so they can correct course.\n\nThen ask these four in a single `AskUserQuestion` call (multi-question form):\n\n1. **Aesthetic direction** — propose 3 visual directions tailored to *this* topic. Do **not** pull from a fixed preset list. Each option must combine a vibe word + a concrete visual cue (palette, typography, motif) so the user can picture it; bare labels like \"minimal\" or \"corporate\" alone are too vague. The three options should feel meaningfully different from each other — not three flavors of the same idea.\n\n   How options should shift with topic:\n   - *\"Intro to Rust for backend engineers\"* → **rust-orange technical editorial** (warm rust\u002Fcharcoal, mono headings, code-grid layout) · **blueprint dev-doc** (cyan grid on near-black, monospace, schematic feel) · **brutalist terminal** (lime-on-black, ASCII rules, no-nonsense)\n   - *\"Q2 product roadmap for stakeholders\"* → **calm corporate clean** (off-white, single accent, generous whitespace) · **confident editorial** (large display serif, tight grid, one bold accent) · **data-forward dashboard** (charts as hero, muted neutrals + status colors)\n   - *\"Kindergarten parent night\"* → **playful crayon** (paper texture, hand-drawn accents, primary colors) · **soft pastel storybook** (peach\u002Fmint, rounded type, illustrated icons) · **warm photo-led** (full-bleed kid photos, simple captions)\n\n   Mark the option that best fits the topic and audience as \"(Recommended)\" so the user has a sensible default. (`AskUserQuestion` already auto-adds \"Other\" — don't add a generic catch-all yourself.)\n\n2. **Page count** — rough length. Offer brackets: 3–5 (short), 6–10 (standard), 11–20 (deep dive), custom.\n3. **Text density per page** — how much copy lives on each page? Offer: minimal (one line \u002F big number), light (heading + 2–3 bullets), standard (heading + 4–5 bullets or short paragraph), dense (multi-column \u002F detailed). This directly drives type scale and layout.\n4. **Motion** — does the user want CSS\u002FReact animations and transitions, or a fully static deck? Offer: static (no motion), subtle (fades \u002F entrance only), rich (keyframes, staggered reveals, looping visuals). If animated, plan to use CSS `@keyframes` \u002F inline `style` + `useEffect`; no extra libraries.\n\nAfter those four, ask follow-ups **only if still unclear**: brand colors, required assets. Don't pad the conversation with questions already answered.\n\n## Step 3 — Pick a slide id\n\nUse **kebab-case**, short, descriptive. Examples: `rust-intro`, `q2-roadmap`, `team-offsite-2026`. Check `slides\u002F` to avoid collisions.\n\n## Step 4 — Plan the structure\n\nSketch the slide as a list of page roles before writing code. Common page types:\n\n| Role             | Purpose                                       |\n| ---------------- | --------------------------------------------- |\n| Cover            | Title + subtitle, strong visual               |\n| Agenda           | What's coming (3–5 items)                     |\n| Section divider  | Big label between chapters                    |\n| Content          | Heading + 2–5 bullets OR heading + one visual |\n| Big number       | One statistic the size of the canvas          |\n| Quote            | Pull-quote with attribution                   |\n| Comparison       | Two-column before\u002Fafter or A vs B             |\n| Closing          | CTA, thanks, contact                          |\n\n**Rule of thumb**: one idea per page. If you're tempted to put two, split them.\n\nIf the deck topic naturally calls for specific real images the user must supply (product screenshots, team photos, customer dashboards), plan where those go and use `\u003CImagePlaceholder>` from `@open-slide\u002Fcore` — see the **Image placeholders** section in `slide-authoring`. Default is **no placeholders**: only insert one when a real image is genuinely required.\n\n## Step 5 — Commit to a visual direction\n\nPick one coherent palette \u002F type scale \u002F aesthetic and hold it across every page. The full set of constraints (palette structure, type scale, padding, aesthetic options) lives in `slide-authoring` — apply it.\n\n**Default: declare a top-level `export const design: DesignSystem = { … }`** at the top of `index.tsx` (after imports) using the chosen palette \u002F type scale, and reference the values via `var(--osd-X)` from inline styles. This keeps the slide tweakable from the Design panel after generation, which is what the user almost always wants. Only skip the `design` const for a one-off slide whose palette is intentionally locked and not meant to be re-themed — in that case, fall back to the local `palette` constants pattern. The \"Design system\" section of `slide-authoring` covers the format and available tokens.\n\nConsult the `frontend-design` skill for deeper aesthetic guidance if the user wants something bold.\n\n## Step 6 — Write `slides\u002F\u003Cid>\u002Findex.tsx`\n\nRead the **`slide-authoring`** skill before writing — it covers the file contract, canvas rules, type scale, spacing, and asset imports, and it includes a starter template you can copy. Don't duplicate that knowledge here; use it.\n\n## Step 7 — Self-review\n\nRun the checklist in `slide-authoring` (\"Self-review before finishing\"). It covers structural correctness, layout discipline, and asset existence.\n\n## Step 8 — Hand off to the user\n\nTell the user:\n\n- The slide id and file path you created.\n- That the dev server will hot-reload — they can open `http:\u002F\u002Flocalhost:5173\u002Fs\u002F\u003Cid>` (or refresh the home page).\n- If dev isn't running: `pnpm dev` from the repo root.\n\nDon't run the dev server yourself unless asked.\n",{"name":5,"description":7},"main","74cd3c4137064fdcde71ed9fe5c4bff58921d899","tools\u002F.agents\u002Fskills\u002Fcreate-slide",0,"https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS","https:\u002F\u002Fgithub.com\u002Farkhe-genesis","2026-11-08 09:08:55",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add arkhe-genesis\u002FArkhe-OS --skill create-slide",{"tool":62,"command":63},"bunx","bunx skills add arkhe-genesis\u002FArkhe-OS --skill create-slide",{"tool":65,"command":66},"pnpm","pnpm dlx skills add arkhe-genesis\u002FArkhe-OS --skill create-slide","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Fcreate-slide\u002FSKILL.md",true,[],[71,93,111,130,154,173],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":44},"01M6MN97RPP1Q9BG489WHW70R8","career-ops","AI job search command center -- evaluate offers, generate CVs, scan portals, track applications","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.ai-integrations\u002Fvscode\u002F.claude\u002Fskills\u002Fcareer-ops\u002FSKILL.md",[],[78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,43],"ops","career","career ops","track","applications","evaluate","mode","true","command center","cvs","scan","command","offers","Job Search","search",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":44},"01M6MN93GFX8W9J1PCKDKZVD3N","zoom-out","Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Fzoom-out\u002FSKILL.md",[],[100,101,37,102,103,104,105,106,85,107,108,109,110],"zoom out","zoom","how","context","code","it","perspective","re","you","with","understand",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":120,"publishedAt":44},"01M6MN8Y2ETBC91BGREF4D39JH","write-a-skill","Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill.","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Fwrite-a-skill\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[121,122,123,109,124,125,126,127,128,37,129,25],"write","write a skill","progressive disclosure","resources","new agent","structure","new skill","build","user",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":137,"publishedAt":44},"01M6MN8RWE2V2PPFVPD0G8FHKF","triage","Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Ftriage\u002FSKILL.md",[136],{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},[132,138,139,25,140,141,142,143,144,145,146,37,147,148,29,149,150,151,152,153],"bugs","state machine","requests","machine","feature","roles","issue workflow","manage","issue","issues","state","feature requests","prepare","triage issues","workflow","review",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":165,"publishedAt":44},"01M6MN8KVDBD28672WMER7HPXM","to-prd","Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Fto-prd\u002FSKILL.md",[160],{"categoryNo":161,"categoryName":162,"taxonomyType":163,"taxonomyTypeDesc":164},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[166,167,37,129,103,168,25,146,169,105,170,171,172],"to prd","prd","publish","issue tracker","project","conversation","tracker",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":44},"01M6MN8E9CGYVWVDDR0NJEFDBB","to-issues","Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.","https:\u002F\u002Fgithub.com\u002Farkhe-genesis\u002FArkhe-OS\u002Fblob\u002Fmain\u002Ftools\u002F.agents\u002Fskills\u002Fto-issues\u002FSKILL.md",[],[147,180,181,170,182,183,169,184,185,172,146,186,37,129,187,188,189,167,25],"to issues","spec","down","break","break down","tickets","implementation","work","convert","plan"]