[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H858CJJQEFTDFM1W6MCHFN":3,"skill-same:01M6H858CJJQEFTDFM1W6MCHFN":77},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":14,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":66},"01M6H858CJJQEFTDFM1W6MCHFN","feedback",null,"Turns the user's unstructured feedback about how a product or system behaves into verified, agent-ready GitHub issues. Splits a complaint into points, checks each against the code and recorded intent (ADRs, CONTEXT.md, git history), plays back what it found until the user agrees, then files one ticket per agreed finding under a shared label for \u002Fimplement or \u002Ffleet dispatch. Use when the user says \"\u002Ffeedback\", \"I don't like how X works\", \"this isn't usable because…\", \"X feels wrong\", \"this behaviour is annoying\", \"push back on how Y behaves\", or otherwise complains about the repo's behaviour or UX without a concrete bug report or spec. Also takes a jam.dev screen recording with the points as bullets. Not for feedback on a skill (use skill-feedback-collector), a single well-understood bug (triage-issue) or a ready-to-file follow-up (file-issue).","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\u002Fproduct\u002Ffeedback\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"bug","when","fleet","recording","ticket","screen","shared","back","intent","files","issue","bug report","up","ready","how","ux","product","issues","git","code","2026-11-10 10:12:30",false,"---\nname: feedback\ndescription: >\n  Turns the user's unstructured feedback about how a product or system behaves into verified,\n  agent-ready GitHub issues. Splits a complaint into points, checks each against the code and\n  recorded intent (ADRs, CONTEXT.md, git history), plays back what it found until the user\n  agrees, then files one ticket per agreed finding under a shared label for \u002Fimplement or\n  \u002Ffleet dispatch. Use when the user says \"\u002Ffeedback\", \"I don't like how X works\", \"this isn't\n  usable because…\", \"X feels wrong\", \"this behaviour is annoying\", \"push back on how Y\n  behaves\", or otherwise complains about the repo's behaviour or UX without a concrete bug\n  report or spec. Also takes a jam.dev screen recording with the points as bullets. Not for feedback on a skill (use skill-feedback-collector), a single\n  well-understood bug (triage-issue) or a ready-to-file follow-up (file-issue).\ndisable-model-invocation: true\n---\n\n# Feedback\n\nThe user's feedback is a claim about the system, not an instruction. Your job is to find out\nwhat the system actually does and why, agree with the user on what is really wrong, and only\nthen file work an agent can pick up cold. Three stages: **verify**, **clarify**, **file**.\n\n## Shape the input\n\nFeedback arrives loose: \"onboarding isn't usable because the form resets, errors are vague and\nit's too slow\". Scoping it is the user's job; splitting it is yours.\n\n- Name the **area** in a short slug (`onboarding`). It becomes the label in stage 3.\n- Number the **points** (P1, P2, P3), keeping the user's own words for each.\n- A `jam.dev\u002Fc\u002F…` link is a **recording** of the points. Read it before verifying and tie each\n  point to its moment, following [references\u002Frecordings.md](references\u002Frecordings.md).\n\nDon't ask the user to restructure anything. If something is too vague to verify, that is a\nstage 1 result, not a reason to stop.\n\n## 1. Verify\n\nExplore the area once, then judge each point against what you found. For anything broader\nthan a couple of lookups, use an Explore subagent and take its summary. Brief it with the area\nand every point, and ask for:\n\n- the code paths behind each point, as files and symbols\n- recorded intent: ADRs in `docs\u002Fadr\u002F`, `CONTEXT.md`, README, and `git log` on the files\n  involved, for why the behaviour is the way it is\n- existing or in-flight work: open issues (`gh issue list --search`) and code that already\n  does what the user wants, searched by concept, not by the user's wording\n\nGive each point one verdict:\n\n| Verdict | Meaning | Carries |\n|---|---|---|\n| Confirmed | The system does what the user says | code path; the recorded reason, if any |\n| Intended | It does, deliberately | the ADR, doc or commit that decided it |\n| Already handled | Built, or an open issue covers it | where, or the issue number |\n| Unverified | Can't establish it from here | what's missing |\n\nPoints can merge (\"P2 and P3 share one cause\") or split (\"P1 is two problems\"). Do the regrouping\nnow and show it in the play-back.\n\nLabel every fact by source: **User** (what they said) or **Code** (what you found, with a\npath), plus **Jam** and **Prod** when there is a recording. An assumption is labelled as one. This stops an inference being filed as a finding.\n\nYou may disagree. If the evidence says the behaviour is right, say so and show why. Agreeing to\nbe agreeable files tickets that the next agent will rightly push back on.\n\n## 2. Clarify\n\nPlay back **every point at once**, in one message:\n\n```markdown\n## Feedback: \u003Carea>\n\n**P1 — \u003Cuser's words>** · Confirmed\n- Code: `path\u002Ffile.ts` `fn` does …\n- Why: no recorded reason \u002F ADR-0004 chose this because …\n- Your objection, as I read it: …\n- Proposed finding: \u003Cwhat should change, one line>\n\n**P2 + P3 — merged** · …\n\nCorrect anything I've got wrong. Anything you don't mention, I'll take as agreed.\n```\n\nThe user replies once, about everything they disagree with. **Silence on a point means they\naccept your reading and reasoning**, including any pushback. Never ask about points one at a\ntime, and never re-ask about a point they let stand.\n\nIf the reply has corrections, re-verify **all** of them together in one pass, then play back\nonly the changed points plus a one-line list of what's settled. Repeat until a reply carries\nno corrections. A reply like \"fine\" or \"go\" settles everything.\n\n## 3. File\n\nEach agreed finding becomes one GitHub issue. Points the user dropped, or Intended points they\naccepted, are not filed; list them in the final report with a one-line reason.\n\n**Route each finding:**\n\n- **A clear change** → `status:ready`.\n- **Reverses a recorded decision**, with the new direction settled in stage 2 → run\n  `record-decision` for the superseding ADR first, then file the ticket linking it, `status:ready`.\n- **Too big, or the direction is still open** → `needs-design` and no `status:*` label, so fleet\n  leaves it alone until someone designs it.\n- **Intended, accepted, but the reason was written nowhere** → one small docs ticket to record\n  it, so the next person doesn't raise the same feedback.\n\n**Ticket body**, `file-issue`'s format plus the evidence from stage 1, so the implementing agent\nstarts from verified facts instead of re-investigating:\n\n```markdown\n## Context\n\n\u003C1–3 sentences: what's wrong and why it matters, in the user's terms.>\n\n## Evidence\n\n- Code: `path\u002Ffile.ts` `fn` — \u003Cwhat it does today>\n- Intent: \u003CADR\u002Fcommit\u002Fdoc, or \"none recorded\">\n- Jam: \u003Clink> at \u003Cm:ss> — \u003Cwhat the recording shows>   (recording only)\n- Prod: `request_id \u003Cid>` — \u003Cwhat the server logged>    (recording only)\n- Agreed in feedback session: \u003Cthe settled reading, one line>\n\n## Where to look\n\n- `path\u002Fto\u002Ffile.ts` — `Symbol`: \u003Cwhat's relevant>\n\n## Acceptance criteria\n\n- [ ] \u003Cobservable outcome, checkable without reading the diff>\n\n## Blocked by\n\n- #\u003Cn> — needs \u003Cnamed type, file or function> from it\n```\n\nOmit \"Blocked by\" unless a finding needs a nameable artifact from another. Being in the same\narea, or the order the user listed them, is not a dependency.\n\n**Labels.** Every ticket gets `feedback:\u003Carea>` plus its route label. Create missing labels first:\n\n```bash\ngh label create \"feedback:\u003Carea>\" -c \"#5319e7\" -d \"Feedback session on \u003Carea>\"\ngh issue create --title \"\u003Cimperative outcome>\" --body-file \u003Ctmpfile> \\\n  --label \"feedback:\u003Carea>\" --label \"status:ready\"\n```\n\nFile blockers before the tickets they block, so the `#\u003Cn>` exists. A blocked ticket gets\n`status:backlog`, not `status:ready`.\n\n## Report\n\nEnd with the ticket URLs, one per line, each with its route; the dropped or accepted points with\ntheir reason; and the one command that starts the work:\n\n- one ready ticket → `\u002Fimplement \u003Cn>`\n- several → `\u002Ffleet dispatch feedback:\u003Carea>`\n\nWith a recording, first comment each ticket's URL on the Jam at its point's moment\n(`jam create comment \u003Cid> \"\u003Curl>\" --at \u003Cms>`), so the recording shows what it became.\n","# Feedback\n\nThe user's feedback is a claim about the system, not an instruction. Your job is to find out\nwhat the system actually does and why, agree with the user on what is really wrong, and only\nthen file work an agent can pick up cold. Three stages: **verify**, **clarify**, **file**.\n\n## Shape the input\n\nFeedback arrives loose: \"onboarding isn't usable because the form resets, errors are vague and\nit's too slow\". Scoping it is the user's job; splitting it is yours.\n\n- Name the **area** in a short slug (`onboarding`). It becomes the label in stage 3.\n- Number the **points** (P1, P2, P3), keeping the user's own words for each.\n- A `jam.dev\u002Fc\u002F…` link is a **recording** of the points. Read it before verifying and tie each\n  point to its moment, following [references\u002Frecordings.md](references\u002Frecordings.md).\n\nDon't ask the user to restructure anything. If something is too vague to verify, that is a\nstage 1 result, not a reason to stop.\n\n## 1. Verify\n\nExplore the area once, then judge each point against what you found. For anything broader\nthan a couple of lookups, use an Explore subagent and take its summary. Brief it with the area\nand every point, and ask for:\n\n- the code paths behind each point, as files and symbols\n- recorded intent: ADRs in `docs\u002Fadr\u002F`, `CONTEXT.md`, README, and `git log` on the files\n  involved, for why the behaviour is the way it is\n- existing or in-flight work: open issues (`gh issue list --search`) and code that already\n  does what the user wants, searched by concept, not by the user's wording\n\nGive each point one verdict:\n\n| Verdict | Meaning | Carries |\n|---|---|---|\n| Confirmed | The system does what the user says | code path; the recorded reason, if any |\n| Intended | It does, deliberately | the ADR, doc or commit that decided it |\n| Already handled | Built, or an open issue covers it | where, or the issue number |\n| Unverified | Can't establish it from here | what's missing |\n\nPoints can merge (\"P2 and P3 share one cause\") or split (\"P1 is two problems\"). Do the regrouping\nnow and show it in the play-back.\n\nLabel every fact by source: **User** (what they said) or **Code** (what you found, with a\npath), plus **Jam** and **Prod** when there is a recording. An assumption is labelled as one. This stops an inference being filed as a finding.\n\nYou may disagree. If the evidence says the behaviour is right, say so and show why. Agreeing to\nbe agreeable files tickets that the next agent will rightly push back on.\n\n## 2. Clarify\n\nPlay back **every point at once**, in one message:\n\n```markdown\n## Feedback: \u003Carea>\n\n**P1 — \u003Cuser's words>** · Confirmed\n- Code: `path\u002Ffile.ts` `fn` does …\n- Why: no recorded reason \u002F ADR-0004 chose this because …\n- Your objection, as I read it: …\n- Proposed finding: \u003Cwhat should change, one line>\n\n**P2 + P3 — merged** · …\n\nCorrect anything I've got wrong. Anything you don't mention, I'll take as agreed.\n```\n\nThe user replies once, about everything they disagree with. **Silence on a point means they\naccept your reading and reasoning**, including any pushback. Never ask about points one at a\ntime, and never re-ask about a point they let stand.\n\nIf the reply has corrections, re-verify **all** of them together in one pass, then play back\nonly the changed points plus a one-line list of what's settled. Repeat until a reply carries\nno corrections. A reply like \"fine\" or \"go\" settles everything.\n\n## 3. File\n\nEach agreed finding becomes one GitHub issue. Points the user dropped, or Intended points they\naccepted, are not filed; list them in the final report with a one-line reason.\n\n**Route each finding:**\n\n- **A clear change** → `status:ready`.\n- **Reverses a recorded decision**, with the new direction settled in stage 2 → run\n  `record-decision` for the superseding ADR first, then file the ticket linking it, `status:ready`.\n- **Too big, or the direction is still open** → `needs-design` and no `status:*` label, so fleet\n  leaves it alone until someone designs it.\n- **Intended, accepted, but the reason was written nowhere** → one small docs ticket to record\n  it, so the next person doesn't raise the same feedback.\n\n**Ticket body**, `file-issue`'s format plus the evidence from stage 1, so the implementing agent\nstarts from verified facts instead of re-investigating:\n\n```markdown\n## Context\n\n\u003C1–3 sentences: what's wrong and why it matters, in the user's terms.>\n\n## Evidence\n\n- Code: `path\u002Ffile.ts` `fn` — \u003Cwhat it does today>\n- Intent: \u003CADR\u002Fcommit\u002Fdoc, or \"none recorded\">\n- Jam: \u003Clink> at \u003Cm:ss> — \u003Cwhat the recording shows>   (recording only)\n- Prod: `request_id \u003Cid>` — \u003Cwhat the server logged>    (recording only)\n- Agreed in feedback session: \u003Cthe settled reading, one line>\n\n## Where to look\n\n- `path\u002Fto\u002Ffile.ts` — `Symbol`: \u003Cwhat's relevant>\n\n## Acceptance criteria\n\n- [ ] \u003Cobservable outcome, checkable without reading the diff>\n\n## Blocked by\n\n- #\u003Cn> — needs \u003Cnamed type, file or function> from it\n```\n\nOmit \"Blocked by\" unless a finding needs a nameable artifact from another. Being in the same\narea, or the order the user listed them, is not a dependency.\n\n**Labels.** Every ticket gets `feedback:\u003Carea>` plus its route label. Create missing labels first:\n\n```bash\ngh label create \"feedback:\u003Carea>\" -c \"#5319e7\" -d \"Feedback session on \u003Carea>\"\ngh issue create --title \"\u003Cimperative outcome>\" --body-file \u003Ctmpfile> \\\n  --label \"feedback:\u003Carea>\" --label \"status:ready\"\n```\n\nFile blockers before the tickets they block, so the `#\u003Cn>` exists. A blocked ticket gets\n`status:backlog`, not `status:ready`.\n\n## Report\n\nEnd with the ticket URLs, one per line, each with its route; the dropped or accepted points with\ntheir reason; and the one command that starts the work:\n\n- one ready ticket → `\u002Fimplement \u003Cn>`\n- several → `\u002Ffleet dispatch feedback:\u003Carea>`\n\nWith a recording, first comment each ticket's URL on the Jam at its point's moment\n(`jam create comment \u003Cid> \"\u003Curl>\" --at \u003Cms>`), so the recording shows what it became.\n",{"name":5,"description":44,"disable-model-invocation":45},"Turns the user's unstructured feedback about how a product or system behaves into verified, agent-ready GitHub issues. Splits a complaint into points, checks each against the code and recorded intent (ADRs, CONTEXT.md, git history), plays back what it found until the user agrees, then files one ticket per agreed finding under a shared label for \u002Fimplement or \u002Ffleet dispatch. Use when the user says \"\u002Ffeedback\", \"I don't like how X works\", \"this isn't usable because…\", \"X feels wrong\", \"this behaviour is annoying\", \"push back on how Y behaves\", or otherwise complains about the repo's behaviour or UX without a concrete bug report or spec. Also takes a jam.dev screen recording with the points as bullets. Not for feedback on a skill (use skill-feedback-collector), a single well-understood bug (triage-issue) or a ready-to-file follow-up (file-issue).\n",true,"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fproduct\u002Ffeedback","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":55,"prompt":65,"zipAvailable":45},[56,59,62],{"tool":57,"command":58},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill feedback",{"tool":60,"command":61},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill feedback",{"tool":63,"command":64},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill feedback","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Ffeedback\u002FSKILL.md",[67,73],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"evals\u002Fevals.json","REFERENCE","参考文档",849,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Ffeedback\u002Fevals\u002Fevals.json",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Frecordings.md",2733,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Ffeedback\u002Freferences\u002Frecordings.md",[78,86,93,119,148,175],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":85},"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":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":85},"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":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":39},"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",[],[100,101,102,103,104,105,106,107,38,108,109,110,23,111,112,113,114,115,116,117,118],"tickets","to tickets","new","signatures","github","plan","batch","task","manifest","plans","true","command","repo","for","feature","run","worktrees","as","cut",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":130,"publishedAt":39},"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",[125],{"categoryNo":126,"categoryName":127,"taxonomyType":128,"taxonomyTypeDesc":129},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[131,132,102,133,134,135,136,137,138,139,140,20,141,110,142,143,144,112,113,145,146,147,117,111],"to seams","schema","neither","it","but","file","prompt","either","use","writing","interface","repos","block","records","build","can","record",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":159,"publishedAt":39},"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",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[160,161,162,117,114,163,164,20,165,166,167,100,168,169,105,170,171,110,23,172,173,174],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"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":182,"publishedAt":39},"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",[181],{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},[183,184,185,186,187,188,189,190,100,191,105,192,193,194,110,173,114,195,196,117],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]