[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H889PSQM2E1ATS2JC10QRV":3,"skill-same:01M6H889PSQM2E1ATS2JC10QRV":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":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":14,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":73},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap",null,"Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"to roadmap","roadmap","ticket","when","features","true","re","about","now","tickets","card","via","doc","as","feature","ideas","self","next","later","never","board","plan","2026-11-10 10:12:30",false,"---\nname: to-roadmap\ndescription: >\n  Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a\n  self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes\n  several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in\n  .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach\n  doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it\n  never re-litigates what was decided.\ndisable-model-invocation: true\n---\n\n## Overview\n\nTurn the features you have settled on into a visual product roadmap: a standalone HTML\nkanban with three columns (Now \u002F Next \u002F Later) where each card is a **feature**, not a ticket — a\nthing to be built, which the spine later breaks down into several tickets.\n\n## Where this sits\n\n```\nPORTFOLIO — many features        ideate  or  chat-to-approach\n                                        ↓\n                            .\u002Fdocs\u002Fapproach.md  →  .\u002Fideas\u002Froadmap.html\n                                                    ^^^^^^^^^^^^ you are here\n                                                        ↓  pick ONE card\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → ticket-tracker\n                                 non-code work: to-prd → to-tickets\n```\n\n**Portfolio → feature is a fan-out, not a step.** This skill is portfolio-level: it prioritises many\nfeatures at once. Crossing to the spine means picking one card — six cards means six independent\nruns of `to-prd → to-plan → to-tickets`, each producing its own several tickets.\n\n**Never send the user backwards.** A missing upstream artifact is written inline or offered, never a\nreason to stop and run another skill first. The one hard gate is an approved plan.\n\nBoard from `.\u002Fdocs\u002Fapproach.md`, from `## Accepted ideas` in `.\u002Fideas\u002FCONTEXT.md`, or from a short\nlist the user gives you. The one thing this skill will not do\nis build a roadmap by parsing a raw conversation — `chat-to-approach` owns that (see Phase 0).\n\nSolo\u002Findie-builder scale throughout: no assignees, no story points, no sprints, no stakeholder\nmatrices.\n\n---\n\n## Phase 0 — Load the source\n\nTwo sources, in priority order. Run `artifact-scan` as a preflight if it's installed rather than\nreimplementing its file checks.\n\n**1. `.\u002Fdocs\u002Fapproach.md`** — the alignment doc, and the richer source. Read it and extract,\ntreating every item as already agreed:\n\n- All features (Name, Problem, Value, Dependencies) → cards\n- Constraints → a note below the board, not cards\n- Principles → use to inform tier suggestions (e.g. \"ship weekly\" → fewer Now items)\n- Open questions → carry forward verbatim into the Open Questions section\n\n**2. `## Accepted ideas` in `.\u002Fideas\u002FCONTEXT.md`** — the ideas the user has decided to build,\nwhether `ideate` promoted them or they were hand-added. One line each, one card each. Accepting is\nthe selection, so board the whole section rather than asking which of them to include.\n\nDo not modify either file.\n\n**If both exist**, the approach doc wins: it has been grilled, and it carries the constraints,\nprinciples and open questions a bare idea list doesn't.\n\n**If neither exists**, ask the user for the features to board — a short list, one line each — and\nmention that `ideate` or `chat-to-approach` leaves a durable source next time. What you must not do\nis build the board by parsing a pasted conversation: `chat-to-approach` owns conversation →\nstructure, including the grilling that resolves ambiguity before anything is committed. Two skills\nparsing transcripts differently is how a board ends up built on ungrilled assumptions.\n\nA feature too vague to tier is not a licence to re-litigate it. Say so, and either ask the user for\na tier directly or point them back at the source to sharpen it.\n\n---\n\n## Phase 1 — Prioritise\n\nAssign each feature a tier. Offer a suggested tier per feature — biasing dependency-blocking\nfeatures toward Now and anything speculative toward Later — and let the user confirm or override in\none pass.\n\n**Now** — Committed, ready to start, essential for current momentum. If the user isn't working on\nit this week or next, it's not Now.\n\n**Next** — Decided but intentionally deferred. Depends on Now items finishing first, or deliberately\nheld back to maintain focus.\n\n**Later** — Someday \u002F low urgency \u002F speculative. Worth keeping visible so nothing falls through the\ncracks, but not near-term.\n\n**Why this ordering — the prioritisation lens.** A tier is a decision, not a guess. When a feature's\ntier is unclear, reason it out against four levers:\n\n- **Value** — how much user pain it removes or upside it unlocks. High value pulls toward Now.\n- **Effort** — rough size. High value + low effort is the classic Now; high effort earns Next\u002FLater\n  unless it's blocking.\n- **Dependency** — does other work need this first? A blocker for several features earns Now even if\n  its own value is modest; something that depends on unfinished work can't be Now.\n- **Risk** — uncertainty or the cost of getting it wrong. De-risk early when a wrong call is\n  expensive to unwind; defer speculative bets to Later.\n\nState the *why* in one clause when you suggest a tier (e.g. \"Now — blocks capture and auth\"), so the\nordering is auditable rather than arbitrary.\n\nDefault to fewer Now items. A solo builder can realistically focus on 2–4 things at once. If\neverything looks like Now, something is wrong — push back and ask.\n\n---\n\n## Phase 2 — Generate the board\n\nWrite a complete, self-contained HTML file to `.\u002Fideas\u002Froadmap.html` in the current working directory.\nRun `mkdir -p .\u002Fideas` first — the directory may not exist yet. It shares a home with the ideate\nreports so a project only has one path to gitignore.\n\n**Always write the file.** Other skills detect this stage with `test -f .\u002Fideas\u002Froadmap.html`, so a board\nthat only ever existed as a chat artifact leaves the repo looking like no roadmap was made. Render\nit as an artifact too if the interface supports it, but the file is the deliverable, not the copy.\n\nUse `assets\u002Froadmap-template.html` as the starting point — inline CSS, no external dependencies, no\nJavaScript. Replace its placeholder comments with the actual cards and questions.\n\n### Card format\n\nEach card represents a **feature** and shows:\n\n- A short noun-phrase title naming the feature (e.g. \"User authentication\", \"Onboarding flow\")\n- One sentence describing the user problem it solves or the value it delivers\n- A dependency line only if it blocks or is blocked by another feature on the board\n\nNothing else — no assignees, no tags, no dates, no story points, no implementation tasks.\n\n### Open questions format\n\nBelow the board, list each open question from the approach doc as a numbered item: the question\nconcisely, plus a one-line note on why it matters or what's blocked on it.\n\n```\nNow (amber)  |  Next (blue)  |  Later (slate)\n─────────────────────────────────────────────\n[ Card ]       [ Card ]        [ Card ]\n[ Card ]       [ Card ]\n[ Card ]\n\nOpen Questions\n──────────────\n1. Should auth use JWT or sessions? — blocks mobile client work.\n2. Is the pricing page in scope for v1?\n```\n\n---\n\n## Finishing Up\n\nAfter writing the file, a brief summary (3–5 lines max). It's a receipt, not a re-explanation —\ndon't repeat the roadmap verbatim.\n\n- How many features are on the board and how they're distributed (N Now \u002F N Next \u002F N Later)\n- How many open questions were flagged\n- Which source was used, left unmodified — to change what's on the board, edit the source\n  (`chat-to-approach` for the approach doc, or the `## Accepted ideas` list directly) and re-run\n- The next step: pick one card and run `to-prd` on it. Each card is its own pass down the spine.\n\nWhen finished, ask: 'Would you like to log feedback? (yes\u002Fno)'. If yes, invoke skill-feedback-collector passing this skill's name and path.\n","## Overview\n\nTurn the features you have settled on into a visual product roadmap: a standalone HTML\nkanban with three columns (Now \u002F Next \u002F Later) where each card is a **feature**, not a ticket — a\nthing to be built, which the spine later breaks down into several tickets.\n\n## Where this sits\n\n```\nPORTFOLIO — many features        ideate  or  chat-to-approach\n                                        ↓\n                            .\u002Fdocs\u002Fapproach.md  →  .\u002Fideas\u002Froadmap.html\n                                                    ^^^^^^^^^^^^ you are here\n                                                        ↓  pick ONE card\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → ticket-tracker\n                                 non-code work: to-prd → to-tickets\n```\n\n**Portfolio → feature is a fan-out, not a step.** This skill is portfolio-level: it prioritises many\nfeatures at once. Crossing to the spine means picking one card — six cards means six independent\nruns of `to-prd → to-plan → to-tickets`, each producing its own several tickets.\n\n**Never send the user backwards.** A missing upstream artifact is written inline or offered, never a\nreason to stop and run another skill first. The one hard gate is an approved plan.\n\nBoard from `.\u002Fdocs\u002Fapproach.md`, from `## Accepted ideas` in `.\u002Fideas\u002FCONTEXT.md`, or from a short\nlist the user gives you. The one thing this skill will not do\nis build a roadmap by parsing a raw conversation — `chat-to-approach` owns that (see Phase 0).\n\nSolo\u002Findie-builder scale throughout: no assignees, no story points, no sprints, no stakeholder\nmatrices.\n\n---\n\n## Phase 0 — Load the source\n\nTwo sources, in priority order. Run `artifact-scan` as a preflight if it's installed rather than\nreimplementing its file checks.\n\n**1. `.\u002Fdocs\u002Fapproach.md`** — the alignment doc, and the richer source. Read it and extract,\ntreating every item as already agreed:\n\n- All features (Name, Problem, Value, Dependencies) → cards\n- Constraints → a note below the board, not cards\n- Principles → use to inform tier suggestions (e.g. \"ship weekly\" → fewer Now items)\n- Open questions → carry forward verbatim into the Open Questions section\n\n**2. `## Accepted ideas` in `.\u002Fideas\u002FCONTEXT.md`** — the ideas the user has decided to build,\nwhether `ideate` promoted them or they were hand-added. One line each, one card each. Accepting is\nthe selection, so board the whole section rather than asking which of them to include.\n\nDo not modify either file.\n\n**If both exist**, the approach doc wins: it has been grilled, and it carries the constraints,\nprinciples and open questions a bare idea list doesn't.\n\n**If neither exists**, ask the user for the features to board — a short list, one line each — and\nmention that `ideate` or `chat-to-approach` leaves a durable source next time. What you must not do\nis build the board by parsing a pasted conversation: `chat-to-approach` owns conversation →\nstructure, including the grilling that resolves ambiguity before anything is committed. Two skills\nparsing transcripts differently is how a board ends up built on ungrilled assumptions.\n\nA feature too vague to tier is not a licence to re-litigate it. Say so, and either ask the user for\na tier directly or point them back at the source to sharpen it.\n\n---\n\n## Phase 1 — Prioritise\n\nAssign each feature a tier. Offer a suggested tier per feature — biasing dependency-blocking\nfeatures toward Now and anything speculative toward Later — and let the user confirm or override in\none pass.\n\n**Now** — Committed, ready to start, essential for current momentum. If the user isn't working on\nit this week or next, it's not Now.\n\n**Next** — Decided but intentionally deferred. Depends on Now items finishing first, or deliberately\nheld back to maintain focus.\n\n**Later** — Someday \u002F low urgency \u002F speculative. Worth keeping visible so nothing falls through the\ncracks, but not near-term.\n\n**Why this ordering — the prioritisation lens.** A tier is a decision, not a guess. When a feature's\ntier is unclear, reason it out against four levers:\n\n- **Value** — how much user pain it removes or upside it unlocks. High value pulls toward Now.\n- **Effort** — rough size. High value + low effort is the classic Now; high effort earns Next\u002FLater\n  unless it's blocking.\n- **Dependency** — does other work need this first? A blocker for several features earns Now even if\n  its own value is modest; something that depends on unfinished work can't be Now.\n- **Risk** — uncertainty or the cost of getting it wrong. De-risk early when a wrong call is\n  expensive to unwind; defer speculative bets to Later.\n\nState the *why* in one clause when you suggest a tier (e.g. \"Now — blocks capture and auth\"), so the\nordering is auditable rather than arbitrary.\n\nDefault to fewer Now items. A solo builder can realistically focus on 2–4 things at once. If\neverything looks like Now, something is wrong — push back and ask.\n\n---\n\n## Phase 2 — Generate the board\n\nWrite a complete, self-contained HTML file to `.\u002Fideas\u002Froadmap.html` in the current working directory.\nRun `mkdir -p .\u002Fideas` first — the directory may not exist yet. It shares a home with the ideate\nreports so a project only has one path to gitignore.\n\n**Always write the file.** Other skills detect this stage with `test -f .\u002Fideas\u002Froadmap.html`, so a board\nthat only ever existed as a chat artifact leaves the repo looking like no roadmap was made. Render\nit as an artifact too if the interface supports it, but the file is the deliverable, not the copy.\n\nUse `assets\u002Froadmap-template.html` as the starting point — inline CSS, no external dependencies, no\nJavaScript. Replace its placeholder comments with the actual cards and questions.\n\n### Card format\n\nEach card represents a **feature** and shows:\n\n- A short noun-phrase title naming the feature (e.g. \"User authentication\", \"Onboarding flow\")\n- One sentence describing the user problem it solves or the value it delivers\n- A dependency line only if it blocks or is blocked by another feature on the board\n\nNothing else — no assignees, no tags, no dates, no story points, no implementation tasks.\n\n### Open questions format\n\nBelow the board, list each open question from the approach doc as a numbered item: the question\nconcisely, plus a one-line note on why it matters or what's blocked on it.\n\n```\nNow (amber)  |  Next (blue)  |  Later (slate)\n─────────────────────────────────────────────\n[ Card ]       [ Card ]        [ Card ]\n[ Card ]       [ Card ]\n[ Card ]\n\nOpen Questions\n──────────────\n1. Should auth use JWT or sessions? — blocks mobile client work.\n2. Is the pricing page in scope for v1?\n```\n\n---\n\n## Finishing Up\n\nAfter writing the file, a brief summary (3–5 lines max). It's a receipt, not a re-explanation —\ndon't repeat the roadmap verbatim.\n\n- How many features are on the board and how they're distributed (N Now \u002F N Next \u002F N Later)\n- How many open questions were flagged\n- Which source was used, left unmodified — to change what's on the board, edit the source\n  (`chat-to-approach` for the approach doc, or the `## Accepted ideas` list directly) and re-run\n- The next step: pick one card and run `to-prd` on it. Each card is its own pass down the spine.\n\nWhen finished, ask: 'Would you like to log feedback? (yes\u002Fno)'. If yes, invoke skill-feedback-collector passing this skill's name and path.\n",{"name":5,"description":51,"disable-model-invocation":52},"Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.\n",true,"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Fto-roadmap","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997","https:\u002F\u002Fpersonal-portfolio-v2-phi.vercel.app","Go & TypeScript developer building tooling for AI-assisted development: git worktree workflows, Claude Code skills and agent orchestration.","2026-11-11 22:26:34",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":52},[63,66,69],{"tool":64,"command":65},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-roadmap",{"tool":67,"command":68},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-roadmap",{"tool":70,"command":71},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-roadmap","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[74,80],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"assets\u002Froadmap-template.html","ASSET","资产文件",3710,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002Fassets\u002Froadmap-template.html",{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"evals\u002Fevals.json","REFERENCE","参考文档",5257,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002Fevals\u002Fevals.json",[87,95,102,124,153,175],{"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},"01M745F5J4Z2W32G4QXESCN5PM","vault-recall","Answer the user's conceptual or technical question using their Obsidian vault as well as general knowledge. Use when the user asks a question (not a task) whose topic appears in the vault MOC digest from session start. Not for task instructions, not mid-task, and not for writing to the vault (that is to-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fvault-recall\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"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},"01M745EW5W0A7K9016Z54A4KG2","ingest","Ingest one external source (an article, course lesson, doc, PDF or URL) into the user's Obsidian vault: save the original to raw\u002F, then build wiki\u002F pages per the vault's § Ingest. Use when the user types \u002Fingest, or says \"ingest this\", \"add this source to my wiki\", \"put this article\u002Flesson in the vault as a wiki page\". Works from any repo. Routing rule: someone else's words go to wiki\u002F (this skill); the user's own learnings and decisions go to notes\u002F (\u002Fto-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fingest\u002FSKILL.md",[],[],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":46},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets","Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[],[33,109,110,111,112,45,113,114,115,116,117,29,26,118,119,120,38,37,121,122,123],"to tickets","new","signatures","github","batch","task","code","manifest","plans","command","repo","for","run","worktrees","cut",{"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":135,"publishedAt":46},"01M6H88E98X9KGGYBGSVDS1E8H","to-seams","Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — \"record a seam for X\", \"we agreed on this schema, seam it\", \"add a seam so Y can build against Z's new field\". Halts for approval before writing either file.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-seams\u002FSKILL.md",[130],{"categoryNo":131,"categoryName":132,"taxonomyType":133,"taxonomyTypeDesc":134},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[136,137,110,138,139,140,141,142,143,144,145,27,146,29,147,148,149,119,120,150,151,152,37,118],"to seams","schema","neither","it","but","file","prompt","either","use","writing","interface","repos","block","records","build","can","record",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":160,"publishedAt":46},"01M6H885QAK839Q771ZBKBK1KA","to-prd","Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[159],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[161,162,37,45,163,164,165,166,167,33,168,169,170,171,172,29,30,38,173,174],"prd","to prd","interviews","codebase","report","line","delivery","spine","say","state","multi","ask","problem","which",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":46},"01M6H881QEEP49HPBMDYDFJQP9","to-plan","Turns one feature's PRD into a skimmable plan in docs\u002Fplans\u002F\u003Cfeature>.md: a short overview, then per phase a glossary, the journeys it satisfies, and its new and modified definitions (types, enums, ports, schema), with the project:\u003Cslug> label. No code, branch or PR; the user's review of the file is the gate. Use for \"plan this feature\", \"write the contract\", \"what are the types\". One feature per run. Slash-only.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-plan\u002FSKILL.md",[],[182,45,183,110,184,115,141,185,144,137,186,187,117,29,188,189,120,38,190,191,192,193],"to plan","overview","\u003Cslug>","glossary","only","contract","short","project","types","pr","branch","ports"]