[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H881QEEP49HPBMDYDFJQP9":3,"skill-same:01M6H881QEEP49HPBMDYDFJQP9":83},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":14,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":68},"01M6H881QEEP49HPBMDYDFJQP9","to-plan",null,"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.","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-plan\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"plan","to plan","only","new","\u003Cslug>","for","true","types","plans","feature","contract","project","pr","schema","use","overview","short","branch","glossary","ports","file","code","2026-11-10 10:12:30",false,"---\nname: to-plan\ndescription: >\n  Turns one feature's PRD into a skimmable plan in docs\u002Fplans\u002F\u003Cfeature>.md: a short overview, then\n  per phase a glossary, the journeys it satisfies, and its new and modified definitions (types,\n  enums, ports, schema), with the project:\u003Cslug> label. No code, branch or PR; the user's review\n  of the file is the gate. Use for \"plan this feature\", \"write the contract\", \"what are the\n  types\". One feature per run. Slash-only.\ndisable-model-invocation: true\n---\n\n# To Plan\n\n```\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → fleet\n                                          ^^^^^^^ you are here\n```\n\nWrite the technical design as definitions, not code. The user skims the types, enums, ports and\nschema to check that the product maps onto the domain; the implementer reads the same definitions\nfor the detail. Anything that follows a pattern the repo already has (how a type is fetched,\nqueried, mocked or routed) is left to the implementer, who knows the pattern; writing it out buries\nthe design.\n\nJudge every boundary with the `codebase-design` vocabulary.\n\n## Process\n\n### 1. Locate the input\n\nRead `docs\u002Fprds\u002F\u003Cfeature>.md`. If the user names a feature, use that file. If more than one PRD\nexists and the target is not obvious, ask which one before starting; never plan several features in\none run. If no PRD exists, write the core inline (below) and carry on, rather than sending the user\nto `\u002Fto-prd`.\n\n`\u003Cfeature>` is the PRD's filename without `.md`; `\u003Cslug>` below is the same string.\n\n**No PRD: write the core.** Ask a short interview, one question at a time and skipping what the\nconversation already answers: the problem in one line, the journeys (each with a surface, 2 to 5\nsteps and a `→ \u003Cobservable state>` final line), then the delivery slices. Write it to\n`docs\u002Fprds\u002F\u003Cfeature>.md` (kebab-case, creating `docs\u002Fprds\u002F` if missing) in `to-prd`'s core format\n(its `references\u002Fproject-doc.md`): `### Problem`, numbered `### J1.` journeys, and numbered delivery\nslices each naming what is usable after it and its `Journeys: J…`. Every journey sits in exactly one\nslice. Show it to the user, confirm, then continue with step 2. Skip the optional layer.\n\n### 2. Explore the codebase\n\nRead the existing architecture, patterns, naming, the `CONTEXT.md` glossary if present, and the\ntypes the feature will have to change. Write nothing outside `docs\u002F` in this skill: no stubs, no\nbranch, no build.\n\n**PRD drift.** When exploration shows a PRD decision won't hold (a cost model, an ownership rule, a\nplace the logic can't live), list each one and ask the user: edit the PRD now, or record it under\n`PRD drift` in the plan's Notes. Never leave a changed decision only in the plan without asking,\nor the PRD goes stale while still looking authoritative.\n\n### 3. Design through usage, privately\n\nFor each journey, sketch the code a caller would write, in your own reasoning only. An awkward\nsketch means the interface is wrong; change it now, while it costs nothing. The sketches never go\nin the plan: the user reviews definitions, and call sites are pattern the implementer already knows.\n\n### 4. Derive the definitions per phase\n\nA phase is one PRD delivery slice, in the PRD's order, each building on the ones before. Place each\ndefinition in the first phase that needs it, and cut any that no journey in its phase needs.\n\n- **Definitions only.** Domain types, enums, DTO and wire shapes, port interfaces between modules,\n  and the schema as table definitions. Never call sites, query or mutation wiring, fetch functions,\n  hooks, mocks, fakes, route bindings or migrations: each follows a repo pattern, and the schema's\n  end state is what the user reviews. Write them in the repo's own languages.\n- **New and Modified.** `New` holds definitions that don't exist yet. `Modified` shows an existing\n  definition's final shape (the whole type or table, or the part that matters), stated flatly. Never\n  write \"adds X\" or \"was Y\": the reader needs the end state, and git holds the delta.\n- **Nothing points forward.** Whatever a phase needs is defined in that phase or an earlier one.\n  Tickets are built in parallel with no compiled stubs, so a forward reference is a phase that\n  cannot start.\n- **Glossary.** Open each phase with one line per new domain term: what it is and what it relates\n  to. Name things in the domain's words, matching `CONTEXT.md` where it defines the term.\n\nJudge each boundary with `codebase-design`: prefer deep modules, and put a port only where behaviour\nmust vary or be tested in isolation.\n\n### 5. Quiz the user\n\nPresent the module boundaries and the phases as a numbered list, each named as the PRD names its\nslice with its journey numbers; split one only if the user agrees, keeping the parts under its name.\nFor each phase show what is usable after it in product terms. Ask whether the granularity and\nboundaries feel right. Iterate until approved. Phases are vertical: each is demoable on its own.\n\n### 6. Settle the feature branch and label\n\nThe feature branch is the one the user names, else the branch checked out when the run started.\nIf that is the default branch, propose `feature\u002F\u003Cslug>` and ask; tickets never build on the default\nbranch. The plan records the name only; this skill creates no branch.\n\n```bash\ngh label list --search \"project:\u003Cslug>\" --json name -q '.[].name' | grep -qx \"project:\u003Cslug>\" || \\\n  gh label create \"project:\u003Cslug>\" -d \"\u003CFeature> (docs\u002Fplans\u002F\u003Cslug>.md)\" -c \"\u003Cany unused hex>\"\n```\n\n### 7. Write the plan\n\nWrite `docs\u002Fplans\u002F\u003Cfeature>.md` in the format in [references\u002Fplan-format.md](references\u002Fplan-format.md),\nmatching the density of [references\u002Fexample-plan.md](references\u002Fexample-plan.md).\nIf the file already exists, show what would change and ask before overwriting: it may hold an\napproved plan that tickets were already cut from.\n\nBefore writing, check:\n\n- **Coverage.** Every definition appears in exactly one phase, and every phase heading matches a\n  PRD delivery slice.\n- **Skim test.** A reader gets each phase from its glossary and headings alone, and each phase fits\n  about one screen. If it doesn't, cut detail (fields that follow a pattern, prose), not definitions.\n\nRun `git check-ignore -q docs\u002Fplans\u002F\u003Cfeature>.md` and say in the closing message whether the plan is\nlocal-only or will be committed.\n\nClose by naming the plan path, the label and the feature branch, and ask the user to review the file:\ntheir approval is the gate `\u002Fto-tickets` waits on.\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","# To Plan\n\n```\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → fleet\n                                          ^^^^^^^ you are here\n```\n\nWrite the technical design as definitions, not code. The user skims the types, enums, ports and\nschema to check that the product maps onto the domain; the implementer reads the same definitions\nfor the detail. Anything that follows a pattern the repo already has (how a type is fetched,\nqueried, mocked or routed) is left to the implementer, who knows the pattern; writing it out buries\nthe design.\n\nJudge every boundary with the `codebase-design` vocabulary.\n\n## Process\n\n### 1. Locate the input\n\nRead `docs\u002Fprds\u002F\u003Cfeature>.md`. If the user names a feature, use that file. If more than one PRD\nexists and the target is not obvious, ask which one before starting; never plan several features in\none run. If no PRD exists, write the core inline (below) and carry on, rather than sending the user\nto `\u002Fto-prd`.\n\n`\u003Cfeature>` is the PRD's filename without `.md`; `\u003Cslug>` below is the same string.\n\n**No PRD: write the core.** Ask a short interview, one question at a time and skipping what the\nconversation already answers: the problem in one line, the journeys (each with a surface, 2 to 5\nsteps and a `→ \u003Cobservable state>` final line), then the delivery slices. Write it to\n`docs\u002Fprds\u002F\u003Cfeature>.md` (kebab-case, creating `docs\u002Fprds\u002F` if missing) in `to-prd`'s core format\n(its `references\u002Fproject-doc.md`): `### Problem`, numbered `### J1.` journeys, and numbered delivery\nslices each naming what is usable after it and its `Journeys: J…`. Every journey sits in exactly one\nslice. Show it to the user, confirm, then continue with step 2. Skip the optional layer.\n\n### 2. Explore the codebase\n\nRead the existing architecture, patterns, naming, the `CONTEXT.md` glossary if present, and the\ntypes the feature will have to change. Write nothing outside `docs\u002F` in this skill: no stubs, no\nbranch, no build.\n\n**PRD drift.** When exploration shows a PRD decision won't hold (a cost model, an ownership rule, a\nplace the logic can't live), list each one and ask the user: edit the PRD now, or record it under\n`PRD drift` in the plan's Notes. Never leave a changed decision only in the plan without asking,\nor the PRD goes stale while still looking authoritative.\n\n### 3. Design through usage, privately\n\nFor each journey, sketch the code a caller would write, in your own reasoning only. An awkward\nsketch means the interface is wrong; change it now, while it costs nothing. The sketches never go\nin the plan: the user reviews definitions, and call sites are pattern the implementer already knows.\n\n### 4. Derive the definitions per phase\n\nA phase is one PRD delivery slice, in the PRD's order, each building on the ones before. Place each\ndefinition in the first phase that needs it, and cut any that no journey in its phase needs.\n\n- **Definitions only.** Domain types, enums, DTO and wire shapes, port interfaces between modules,\n  and the schema as table definitions. Never call sites, query or mutation wiring, fetch functions,\n  hooks, mocks, fakes, route bindings or migrations: each follows a repo pattern, and the schema's\n  end state is what the user reviews. Write them in the repo's own languages.\n- **New and Modified.** `New` holds definitions that don't exist yet. `Modified` shows an existing\n  definition's final shape (the whole type or table, or the part that matters), stated flatly. Never\n  write \"adds X\" or \"was Y\": the reader needs the end state, and git holds the delta.\n- **Nothing points forward.** Whatever a phase needs is defined in that phase or an earlier one.\n  Tickets are built in parallel with no compiled stubs, so a forward reference is a phase that\n  cannot start.\n- **Glossary.** Open each phase with one line per new domain term: what it is and what it relates\n  to. Name things in the domain's words, matching `CONTEXT.md` where it defines the term.\n\nJudge each boundary with `codebase-design`: prefer deep modules, and put a port only where behaviour\nmust vary or be tested in isolation.\n\n### 5. Quiz the user\n\nPresent the module boundaries and the phases as a numbered list, each named as the PRD names its\nslice with its journey numbers; split one only if the user agrees, keeping the parts under its name.\nFor each phase show what is usable after it in product terms. Ask whether the granularity and\nboundaries feel right. Iterate until approved. Phases are vertical: each is demoable on its own.\n\n### 6. Settle the feature branch and label\n\nThe feature branch is the one the user names, else the branch checked out when the run started.\nIf that is the default branch, propose `feature\u002F\u003Cslug>` and ask; tickets never build on the default\nbranch. The plan records the name only; this skill creates no branch.\n\n```bash\ngh label list --search \"project:\u003Cslug>\" --json name -q '.[].name' | grep -qx \"project:\u003Cslug>\" || \\\n  gh label create \"project:\u003Cslug>\" -d \"\u003CFeature> (docs\u002Fplans\u002F\u003Cslug>.md)\" -c \"\u003Cany unused hex>\"\n```\n\n### 7. Write the plan\n\nWrite `docs\u002Fplans\u002F\u003Cfeature>.md` in the format in [references\u002Fplan-format.md](references\u002Fplan-format.md),\nmatching the density of [references\u002Fexample-plan.md](references\u002Fexample-plan.md).\nIf the file already exists, show what would change and ask before overwriting: it may hold an\napproved plan that tickets were already cut from.\n\nBefore writing, check:\n\n- **Coverage.** Every definition appears in exactly one phase, and every phase heading matches a\n  PRD delivery slice.\n- **Skim test.** A reader gets each phase from its glossary and headings alone, and each phase fits\n  about one screen. If it doesn't, cut detail (fields that follow a pattern, prose), not definitions.\n\nRun `git check-ignore -q docs\u002Fplans\u002F\u003Cfeature>.md` and say in the closing message whether the plan is\nlocal-only or will be committed.\n\nClose by naming the plan path, the label and the feature branch, and ask the user to review the file:\ntheir approval is the gate `\u002Fto-tickets` waits on.\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":46,"disable-model-invocation":47},"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.\n",true,"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Fto-plan","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":57,"prompt":67,"zipAvailable":47},[58,61,64],{"tool":59,"command":60},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-plan",{"tool":62,"command":63},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-plan",{"tool":65,"command":66},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-plan\u002FSKILL.md",[69,75,79],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"evals\u002Fevals.json","REFERENCE","参考文档",1900,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-plan\u002Fevals\u002Fevals.json",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fexample-plan.md",3146,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-plan\u002Freferences\u002Fexample-plan.md",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fplan-format.md",1775,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-plan\u002Freferences\u002Fplan-format.md",[84,92,99,120,147,174],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":91},"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":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":91},"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":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":41},"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",[],[106,107,22,108,109,19,110,111,40,112,27,25,113,114,115,24,28,116,117,118,119],"tickets","to tickets","signatures","github","batch","task","manifest","ticket","command","repo","run","worktrees","as","cut",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":131,"publishedAt":41},"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",[126],{"categoryNo":127,"categoryName":128,"taxonomyType":129,"taxonomyTypeDesc":130},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[132,32,22,133,134,135,39,136,137,33,138,139,140,25,141,142,143,115,24,144,145,146,118,114],"to seams","neither","it","but","prompt","either","writing","when","interface","repos","block","records","build","can","record",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":158,"publishedAt":41},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap","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.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[153],{"categoryNo":154,"categoryName":155,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[159,160,161,118,28,162,163,139,164,165,166,106,167,168,19,169,170,25,113,171,172,173],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":181,"publishedAt":41},"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",[180],{"categoryNo":154,"categoryName":155,"taxonomyType":156,"taxonomyTypeDesc":157},[182,183,184,185,186,187,188,189,106,190,19,191,192,193,25,172,28,194,195,118],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]