[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H885QAK839Q771ZBKBK1KA":3,"skill-same:01M6H885QAK839Q771ZBKBK1KA":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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":71},"01M6H885QAK839Q771ZBKBK1KA","to-prd",null,"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).","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-prd\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],"prd","to prd","line","codebase","which","true","re","interviews","multi","spine","tickets","problem","as","feature","delivery","say","ask","plan","state","report","2026-11-10 10:12:30",false,"---\nname: to-prd\ndescription: >\n  Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in\n  an observable state) and delivery slices that say what is usable after each. Interviews, explores\n  the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a\n  multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it\n  doesn't re-ask what's settled, but needs none. Starts the per-feature spine\n  (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).\ndisable-model-invocation: true\n---\n\n## Where this sits\n\n```\nPORTFOLIO — many features        ideate  or  chat-to-approach\n                                        ↓\n                            .\u002Fdocs\u002Fapproach.md  →  .\u002Fideas\u002Froadmap.html\n                                                        ↓  pick ONE card\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → ticket-tracker\n                                 ^^^^^^ you are here\n                                 non-code work: to-prd → to-tickets\n```\n\n**Portfolio → feature is a fan-out, not a step.** A roadmap card is a *feature*. Six cards means six\nPRDs, never one covering a whole roadmap or approach doc.\n\n**Never send the user backwards.** A missing upstream artifact is never a reason to stop.\n\n## What a PRD is\n\nEvery PRD has a **core**: a one-line problem, journeys, and delivery slices. A small change is the\ncore and nothing else. Journeys and slices are defined in\n[references\u002Fproject-doc.md](references\u002Fproject-doc.md); read it before writing.\n\nBuild order, tracer bullets, module boundaries and per-file design stay out: they are\n`to-plan`'s and `to-tickets`' job.\n\n## Priors\n\nBefore asking a question, skip it if one of these already answers it:\n\n1. **The conversation.**\n2. **On-disk priors** — `.\u002Fdocs\u002Fapproach.md` and `.\u002Fideas\u002Freports\u002F*-ideate.md` (use `artifact-scan`\n   to locate them if installed, else `ls`). Confirm and grill deltas only.\n\nPriors are accelerants, not prerequisites: with none, run the full interview. They are portfolio\nlevel; if one holds several features and the target isn't obvious, ask which one this PRD is for.\n\n## Process\n\nSkip steps that aren't necessary.\n\n### 1. Get the problem in the user's words\n\nAsk for a long, detailed description of the problem and any ideas for solutions.\n\n### 2. Explore the repo\n\nVerify their assertions and learn the current state. Note what already half-exists, so the journeys\nbuild on it rather than reading as all-net-new.\n\n### 3. Grill for scope and behaviour\n\nRun the `grilling` skill; it owns the loop. Focus on who does what and what they see, not build order.\n\n### 4. Write the journeys\n\nFor each way a user gets value, draft a journey in the reference's format. Check the set with the\nuser: does it cover the problem, and does every journey end somewhere you could point at? If a\nprototype would help, the `prototype` skill builds one.\n\n### 5. Cut delivery slices\n\nAsk for the smallest release that delivers the core outcome, then what follows. Sequence by user\nvalue, not technical dependency.\n\n### 6. Offer the optional layer\n\nFor a bigger feature, offer to add why, goal, concepts, out of scope and open questions. Skip it for\na small change.\n\nThe format of this layer is the user's call and not fixed by this skill. If they want it, ask:\n\"How should the optional layer look: prose sections, a table, bullets, or something else?\" Use their\nanswer; do not choose for them.\n\n### 7. Save it\n\n1. Create `docs\u002Fprds\u002F` if missing. Write the PRD to `docs\u002Fprds\u002F\u003Cfeature>.md`, kebab-cased.\n2. Show it to the user and confirm.\n3. Print the file path. `to-plan` and `to-tickets` read it from there.\n\nFiling a GitHub issue is opt-in, only when the user asks, and from the file so the copies don't drift:\n\n```bash\ngh issue create --title \"[PRD] \u003CFeature Name>\" --body-file docs\u002Fprds\u002F\u003Cfeature>.md\n```\n\nThen hand off: `\u002Fto-plan` for code work; `\u002Fto-tickets` straight from the PRD for non-code work.\n\nWhen finished, ask: 'Would you like to log feedback? (yes\u002Fno)'. If yes, invoke\nskill-feedback-collector passing this skill's name and path.\n","## Where this sits\n\n```\nPORTFOLIO — many features        ideate  or  chat-to-approach\n                                        ↓\n                            .\u002Fdocs\u002Fapproach.md  →  .\u002Fideas\u002Froadmap.html\n                                                        ↓  pick ONE card\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → ticket-tracker\n                                 ^^^^^^ you are here\n                                 non-code work: to-prd → to-tickets\n```\n\n**Portfolio → feature is a fan-out, not a step.** A roadmap card is a *feature*. Six cards means six\nPRDs, never one covering a whole roadmap or approach doc.\n\n**Never send the user backwards.** A missing upstream artifact is never a reason to stop.\n\n## What a PRD is\n\nEvery PRD has a **core**: a one-line problem, journeys, and delivery slices. A small change is the\ncore and nothing else. Journeys and slices are defined in\n[references\u002Fproject-doc.md](references\u002Fproject-doc.md); read it before writing.\n\nBuild order, tracer bullets, module boundaries and per-file design stay out: they are\n`to-plan`'s and `to-tickets`' job.\n\n## Priors\n\nBefore asking a question, skip it if one of these already answers it:\n\n1. **The conversation.**\n2. **On-disk priors** — `.\u002Fdocs\u002Fapproach.md` and `.\u002Fideas\u002Freports\u002F*-ideate.md` (use `artifact-scan`\n   to locate them if installed, else `ls`). Confirm and grill deltas only.\n\nPriors are accelerants, not prerequisites: with none, run the full interview. They are portfolio\nlevel; if one holds several features and the target isn't obvious, ask which one this PRD is for.\n\n## Process\n\nSkip steps that aren't necessary.\n\n### 1. Get the problem in the user's words\n\nAsk for a long, detailed description of the problem and any ideas for solutions.\n\n### 2. Explore the repo\n\nVerify their assertions and learn the current state. Note what already half-exists, so the journeys\nbuild on it rather than reading as all-net-new.\n\n### 3. Grill for scope and behaviour\n\nRun the `grilling` skill; it owns the loop. Focus on who does what and what they see, not build order.\n\n### 4. Write the journeys\n\nFor each way a user gets value, draft a journey in the reference's format. Check the set with the\nuser: does it cover the problem, and does every journey end somewhere you could point at? If a\nprototype would help, the `prototype` skill builds one.\n\n### 5. Cut delivery slices\n\nAsk for the smallest release that delivers the core outcome, then what follows. Sequence by user\nvalue, not technical dependency.\n\n### 6. Offer the optional layer\n\nFor a bigger feature, offer to add why, goal, concepts, out of scope and open questions. Skip it for\na small change.\n\nThe format of this layer is the user's call and not fixed by this skill. If they want it, ask:\n\"How should the optional layer look: prose sections, a table, bullets, or something else?\" Use their\nanswer; do not choose for them.\n\n### 7. Save it\n\n1. Create `docs\u002Fprds\u002F` if missing. Write the PRD to `docs\u002Fprds\u002F\u003Cfeature>.md`, kebab-cased.\n2. Show it to the user and confirm.\n3. Print the file path. `to-plan` and `to-tickets` read it from there.\n\nFiling a GitHub issue is opt-in, only when the user asks, and from the file so the copies don't drift:\n\n```bash\ngh issue create --title \"[PRD] \u003CFeature Name>\" --body-file docs\u002Fprds\u002F\u003Cfeature>.md\n```\n\nThen hand off: `\u002Fto-plan` for code work; `\u002Fto-tickets` straight from the PRD for non-code work.\n\nWhen finished, ask: 'Would you like to log feedback? (yes\u002Fno)'. If yes, invoke\nskill-feedback-collector passing this skill's name and path.\n",{"name":5,"description":49,"disable-model-invocation":50},"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).\n",true,"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Fto-prd","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":60,"prompt":70,"zipAvailable":50},[61,64,67],{"tool":62,"command":63},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-prd",{"tool":65,"command":66},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-prd",{"tool":68,"command":69},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill to-prd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[72,78,82],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"evals\u002Fevals.json","REFERENCE","参考文档",1767,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002Fevals\u002Fevals.json",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fproject-doc.md",1675,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002Freferences\u002Fproject-doc.md",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"skill-feedback-ledger.md",1954,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002Fskill-feedback-ledger.md",[87,95,102,125,155,177],{"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":44},"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",[],[109,34,110,111,112,113,114,115,116,41,117,118,119,120,29,121,122,123,124,37,36],"to tickets","code","new","cut","worktrees","run","command","github","batch","task","manifest","plans","ticket","signatures","repo","for",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":136,"publishedAt":44},"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",[131],{"categoryNo":132,"categoryName":133,"taxonomyType":134,"taxonomyTypeDesc":135},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[137,138,139,140,111,141,142,143,144,145,146,147,148,149,29,150,151,152,123,124,153,115,154,36],"to seams","use","can","when","neither","it","but","file","prompt","either","writing","schema","interface","repos","block","records","build","record",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":44},"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",[161],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[163,164,37,165,36,166,167,168,140,169,170,171,34,172,173,41,174,175,29,121,176,30],"to roadmap","roadmap","never","ideas","next","features","doc","board","about","via","later","self","now","card",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":44},"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",[],[184,41,185,138,186,187,111,188,110,144,189,148,190,191,120,192,29,193,194,124,195,37],"to plan","ports","pr","types","\u003Cslug>","glossary","only","contract","overview","short","project","branch"]