[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H87CF4KFWPVPYMY6ZN7XSB":3,"skill-same:01M6H87CF4KFWPVPYMY6ZN7XSB":110},{"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":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6H87CF4KFWPVPYMY6ZN7XSB","ideate",null,"Use whenever the user asks what to build next in this project: \"what should I build next?\", \"any ideas for this project?\", \"what's missing?\", \"help me find gaps\", \"where could this go?\", \"what are competitors doing?\", \"where could we differentiate?\", \"how do I grow this?\". Trigger for roadmap ideation, product discovery, gap analysis and competitive positioning in a codebase, even when the user never says \"ideate\". Inventories what the code already does, scans the real market, and produces a portfolio of 6–10 evidence-backed ideas (mostly deepening what exists, some net-new), each of which later runs \u002Fto-prd on its own. For \"which skill should I run next?\" use artifact-scan.","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\u002Fideate\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"later","new","when","which","grow","project","artifact","positioning","next","me","competitive positioning","go","roadmap","never","portfolio","product discovery","how","analysis","product","code","run","2026-11-10 10:12:30",false,"---\nname: ideate\ndescription: >\n  Use whenever the user asks what to build next in this project: \"what should I build next?\",\n  \"any ideas for this project?\", \"what's missing?\", \"help me find gaps\", \"where could this go?\",\n  \"what are competitors doing?\", \"where could we differentiate?\", \"how do I grow this?\". Trigger for\n  roadmap ideation, product discovery, gap analysis and competitive positioning in a codebase, even\n  when the user never says \"ideate\". Inventories what the code already does, scans the real market,\n  and produces a portfolio of 6–10 evidence-backed ideas (mostly deepening what exists, some\n  net-new), each of which later runs \u002Fto-prd on its own. For \"which skill should I run next?\" use\n  artifact-scan.\n---\n\n# Ideate\n\nProduce a **portfolio** of what to build next in this codebase. The whole run is built on an\ninventory of what the code already does, checked against a market matrix, with every claim tied to\nevidence. It is not a single-idea design session. Each shortlisted idea later becomes its own\n`to-prd` run. Never send the user backwards: a user who already knows what they want goes straight to\n`to-prd`.\n\n## Hard rules\n\n- **Code before questions.** Never ask the user something the repo can answer. Ask nothing until\n  the inventory exists and has been shown.\n- **At most 3 `AskUserQuestion` calls before the report.** Options offered are about *process*\n  (\"looks right, carry on\" \u002F \"go deeper on X area\"), never about idea *content*. Anything left\n  unasked becomes a labelled assumption in the report.\n- **A focus re-weights, never deletes.** If the user names a focus (`\u002Fideate alerts`), rank ideas\n  inside it higher. At least 2 shortlisted ideas still sit outside it, marked `outside focus`.\n- **Firewall.** Market findings decide what to ask and what to compare. They are never evidence\n  about this codebase. The inventory is never evidence about the market.\n- **Generate everything before cutting anything.** Cuts are visible with a reason. Leftovers are\n  parked, not deleted.\n- **No pre-selected default** at the final pick. \"None\" is a valid answer.\n- **Tone:** curious, specific, calibrated. No hype. \"Nothing surprising this run\" is a normal result.\n\n## Phase 1: Load memory\n\nIf `.\u002Fideas\u002FCONTEXT.md` exists, read it in full (`references\u002Fcontext-template.md` describes its\nsections). Use its `## Capability inventory` and `## Market matrix` as the baseline and update\nonly what changed: `git diff --stat \u003Cpinned-commit>..HEAD` tells you which inventory rows to\nre-check, and matrix entries older than 3 months get refreshed. Collect every title under\nImplemented, Accepted and Rejected. Those are never re-proposed, including under a new name. A\nProposed idea may come back only if labelled `iteration on: \u003Ctitle>`. Do not ask the user to\nconfirm the file.\n\nAn older CONTEXT.md may lack the inventory, matrix or Rejected sections. Treat those as empty and\nadd them when writing back.\n\nCreate a run-local work dir (`WORK=$(mktemp -d -t ideate)`). Keep the inventory, matrix, raw\ncandidates and critic inputs there, and pass subagents file paths rather than pasted text. A\nfixed scratch path collides with any other ideate run going on at the same time.\n\n## Phase 2: Capability inventory\n\nFollow `references\u002Finventory.md`. The output is a table of capabilities in the repo's own domain\nterms. Each has a status of COMPLETE, PARTIAL, ORPHAN or GAP, `file:line` citations, the search\nthat proves every absence, a job-map overlay, and a pinned commit hash.\n\nAs soon as the capability rows exist, launch the market scan (Phase 4) in the background so it\nruns while the user reads.\n\n## Phase 3: Show, then ask\n\nShow the inventory summary: the capability rows, their status, and the 3–5 sharpest signals.\nThen ask what's wrong, missing, or more important than the summary suggests. Use at most 3\nquestions, each about something only the user knows: who else uses it, what they actually do day\nto day, what they've tried and abandoned. A focus given with the invocation counts as an answer\nalready received, so don't re-ask it.\n\nRecord every answer and every unasked gap in an **assumptions log** (`A1: \u003Cassumption> — basis:\n\u003Ccode | user | none>`). Answers re-weight candidates later. They never remove areas from\ngeneration.\n\n## Phase 4: Market scan (background subagent)\n\nSpawn one `Agent` (general-purpose, `run_in_background: true`) with the contract in\n`references\u002Fmarket-scan.md`, filled in with the product summary, the capability names as matrix\nrows, and any prior matrix from CONTEXT.md. `WebSearch` and `WebFetch` are used only inside this\nsubagent. Wait for it before generating. If it fails or comes back thin, say so in the report and\ncontinue with what you have. Never fill the gap from memory.\n\n## Phase 5: Generate wide\n\nFollow `references\u002Fgenerate.md`. Derive 3–5 axes from the inventory. Spawn **3 generator\nsubagents in one message**, so they can't see each other, each with a different lens set. Aim for\n25–40 raw candidates. Any axis that comes back empty gets one recovery pass. If a parallel spawn\nis refused because of a concurrency limit, spawn the generators one at a time. Each still runs in\nits own context and is given none of the others' output. Never fold them into your own context.\n\n## Phase 6: Converge\n\nStill in `references\u002Fgenerate.md`: merge duplicates explicitly, write the cut table (one reason\nper cut), and pick 6–10 ideas:\n\n- half or more are `deepen` or `extend` ideas on existing inventory rows;\n- at least 2 are `net-new`, from an empty job step or a matrix gap;\n- every idea cites inventory rows;\n- with a focus, at least 2 are outside it.\n\nOrder the shortlist by Kano: must-be gaps, then performance, then at most a few delighters. Write\neach idea with `references\u002Fidea-template.md`. Everything else goes to the Parked appendix.\n\n## Phase 7: Critic\n\nSpawn a fresh `Agent` that saw none of the generation, using the brief in `references\u002Fevidence.md`.\nIt tries to refute each shortlisted idea and every insight claim from code and sources, and writes\na one-line pre-mortem per idea. Act on its verdicts: drop refuted ideas into the cut table and\npromote from Parked to keep 6–10, downgrade strength badges and insight tiers it weakens, and\nrecord its strongest counter-argument against each surviving insight.\n\n## Phase 8: Insight gate\n\nApply the gate in `references\u002Fevidence.md` to every \"the market has this wrong\" claim. Each one\nends as **Insight**, **Hypothesis** (with the cheapest build-and-measure check) or **Watch**.\n\"None this run; conventional wisdom looks sound because …\" is a valid and common outcome.\n\n## Phase 9: Report, memory, selection\n\n1. Resolve the path and write the report with `references\u002Freport-template.md`:\n   ```bash\n   mkdir -p .\u002Fideas\u002Freports\n   BASE=\".\u002Fideas\u002Freports\u002F$(date -u +%Y-%m-%d)-ideate\"; OUT=\"$BASE.md\"; N=2\n   while [ -e \"$OUT\" ]; do OUT=\"$BASE-$N.md\"; N=$((N+1)); done; echo \"$OUT\"\n   ```\n2. Update or create `.\u002Fideas\u002FCONTEXT.md` with `references\u002Fcontext-template.md`. Write back the\n   inventory and matrix, append insights, add the shortlist to `## Proposed ideas (pending)`, and\n   add critic-refuted ideas with load-bearing reasons to `## Rejected ideas (with reason)`. If\n   `git log` since `last_updated` clearly shows an Accepted or Proposed idea shipped, move it to\n   Implemented and note this in the assumptions log. Keep every existing heading. Move lines\n   between sections verbatim: other skills and the user match on that exact text.\n3. Present the shortlist in chat: one line per idea (`n. title · type · appetite · badge`) with\n   the report path. Ask which one, if any, to take forward. Ask in plain text, because the\n   shortlist exceeds `AskUserQuestion`'s four options and trimming it to fit would be a hidden\n   pre-selection. Recommend nothing in the question.\n4. On a pick: fill the report's `## Selection` (title plus first slice), move its line from\n   Proposed to `## Accepted ideas`, and invoke `to-prd` with the idea's first slice as the brief.\n   Ideas the user explicitly rejects go to Rejected with their reason. On \"none\" or no answer,\n   leave everything as proposed. Selection can happen on a later pass.\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","# Ideate\n\nProduce a **portfolio** of what to build next in this codebase. The whole run is built on an\ninventory of what the code already does, checked against a market matrix, with every claim tied to\nevidence. It is not a single-idea design session. Each shortlisted idea later becomes its own\n`to-prd` run. Never send the user backwards: a user who already knows what they want goes straight to\n`to-prd`.\n\n## Hard rules\n\n- **Code before questions.** Never ask the user something the repo can answer. Ask nothing until\n  the inventory exists and has been shown.\n- **At most 3 `AskUserQuestion` calls before the report.** Options offered are about *process*\n  (\"looks right, carry on\" \u002F \"go deeper on X area\"), never about idea *content*. Anything left\n  unasked becomes a labelled assumption in the report.\n- **A focus re-weights, never deletes.** If the user names a focus (`\u002Fideate alerts`), rank ideas\n  inside it higher. At least 2 shortlisted ideas still sit outside it, marked `outside focus`.\n- **Firewall.** Market findings decide what to ask and what to compare. They are never evidence\n  about this codebase. The inventory is never evidence about the market.\n- **Generate everything before cutting anything.** Cuts are visible with a reason. Leftovers are\n  parked, not deleted.\n- **No pre-selected default** at the final pick. \"None\" is a valid answer.\n- **Tone:** curious, specific, calibrated. No hype. \"Nothing surprising this run\" is a normal result.\n\n## Phase 1: Load memory\n\nIf `.\u002Fideas\u002FCONTEXT.md` exists, read it in full (`references\u002Fcontext-template.md` describes its\nsections). Use its `## Capability inventory` and `## Market matrix` as the baseline and update\nonly what changed: `git diff --stat \u003Cpinned-commit>..HEAD` tells you which inventory rows to\nre-check, and matrix entries older than 3 months get refreshed. Collect every title under\nImplemented, Accepted and Rejected. Those are never re-proposed, including under a new name. A\nProposed idea may come back only if labelled `iteration on: \u003Ctitle>`. Do not ask the user to\nconfirm the file.\n\nAn older CONTEXT.md may lack the inventory, matrix or Rejected sections. Treat those as empty and\nadd them when writing back.\n\nCreate a run-local work dir (`WORK=$(mktemp -d -t ideate)`). Keep the inventory, matrix, raw\ncandidates and critic inputs there, and pass subagents file paths rather than pasted text. A\nfixed scratch path collides with any other ideate run going on at the same time.\n\n## Phase 2: Capability inventory\n\nFollow `references\u002Finventory.md`. The output is a table of capabilities in the repo's own domain\nterms. Each has a status of COMPLETE, PARTIAL, ORPHAN or GAP, `file:line` citations, the search\nthat proves every absence, a job-map overlay, and a pinned commit hash.\n\nAs soon as the capability rows exist, launch the market scan (Phase 4) in the background so it\nruns while the user reads.\n\n## Phase 3: Show, then ask\n\nShow the inventory summary: the capability rows, their status, and the 3–5 sharpest signals.\nThen ask what's wrong, missing, or more important than the summary suggests. Use at most 3\nquestions, each about something only the user knows: who else uses it, what they actually do day\nto day, what they've tried and abandoned. A focus given with the invocation counts as an answer\nalready received, so don't re-ask it.\n\nRecord every answer and every unasked gap in an **assumptions log** (`A1: \u003Cassumption> — basis:\n\u003Ccode | user | none>`). Answers re-weight candidates later. They never remove areas from\ngeneration.\n\n## Phase 4: Market scan (background subagent)\n\nSpawn one `Agent` (general-purpose, `run_in_background: true`) with the contract in\n`references\u002Fmarket-scan.md`, filled in with the product summary, the capability names as matrix\nrows, and any prior matrix from CONTEXT.md. `WebSearch` and `WebFetch` are used only inside this\nsubagent. Wait for it before generating. If it fails or comes back thin, say so in the report and\ncontinue with what you have. Never fill the gap from memory.\n\n## Phase 5: Generate wide\n\nFollow `references\u002Fgenerate.md`. Derive 3–5 axes from the inventory. Spawn **3 generator\nsubagents in one message**, so they can't see each other, each with a different lens set. Aim for\n25–40 raw candidates. Any axis that comes back empty gets one recovery pass. If a parallel spawn\nis refused because of a concurrency limit, spawn the generators one at a time. Each still runs in\nits own context and is given none of the others' output. Never fold them into your own context.\n\n## Phase 6: Converge\n\nStill in `references\u002Fgenerate.md`: merge duplicates explicitly, write the cut table (one reason\nper cut), and pick 6–10 ideas:\n\n- half or more are `deepen` or `extend` ideas on existing inventory rows;\n- at least 2 are `net-new`, from an empty job step or a matrix gap;\n- every idea cites inventory rows;\n- with a focus, at least 2 are outside it.\n\nOrder the shortlist by Kano: must-be gaps, then performance, then at most a few delighters. Write\neach idea with `references\u002Fidea-template.md`. Everything else goes to the Parked appendix.\n\n## Phase 7: Critic\n\nSpawn a fresh `Agent` that saw none of the generation, using the brief in `references\u002Fevidence.md`.\nIt tries to refute each shortlisted idea and every insight claim from code and sources, and writes\na one-line pre-mortem per idea. Act on its verdicts: drop refuted ideas into the cut table and\npromote from Parked to keep 6–10, downgrade strength badges and insight tiers it weakens, and\nrecord its strongest counter-argument against each surviving insight.\n\n## Phase 8: Insight gate\n\nApply the gate in `references\u002Fevidence.md` to every \"the market has this wrong\" claim. Each one\nends as **Insight**, **Hypothesis** (with the cheapest build-and-measure check) or **Watch**.\n\"None this run; conventional wisdom looks sound because …\" is a valid and common outcome.\n\n## Phase 9: Report, memory, selection\n\n1. Resolve the path and write the report with `references\u002Freport-template.md`:\n   ```bash\n   mkdir -p .\u002Fideas\u002Freports\n   BASE=\".\u002Fideas\u002Freports\u002F$(date -u +%Y-%m-%d)-ideate\"; OUT=\"$BASE.md\"; N=2\n   while [ -e \"$OUT\" ]; do OUT=\"$BASE-$N.md\"; N=$((N+1)); done; echo \"$OUT\"\n   ```\n2. Update or create `.\u002Fideas\u002FCONTEXT.md` with `references\u002Fcontext-template.md`. Write back the\n   inventory and matrix, append insights, add the shortlist to `## Proposed ideas (pending)`, and\n   add critic-refuted ideas with load-bearing reasons to `## Rejected ideas (with reason)`. If\n   `git log` since `last_updated` clearly shows an Accepted or Proposed idea shipped, move it to\n   Implemented and note this in the assumptions log. Keep every existing heading. Move lines\n   between sections verbatim: other skills and the user match on that exact text.\n3. Present the shortlist in chat: one line per idea (`n. title · type · appetite · badge`) with\n   the report path. Ask which one, if any, to take forward. Ask in plain text, because the\n   shortlist exceeds `AskUserQuestion`'s four options and trimming it to fit would be a hidden\n   pre-selection. Recommend nothing in the question.\n4. On a pick: fill the report's `## Selection` (title plus first slice), move its line from\n   Proposed to `## Accepted ideas`, and invoke `to-prd` with the idea's first slice as the brief.\n   Ideas the user explicitly rejects go to Rejected with their reason. On \"none\" or no answer,\n   leave everything as proposed. Selection can happen on a later pass.\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":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Fideate","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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill ideate",{"tool":64,"command":65},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill ideate",{"tool":67,"command":68},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill ideate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fideate\u002FSKILL.md",true,[72,78,82,86,90,94,98,102,106],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"evals\u002Fevals.json","REFERENCE","参考文档",9490,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fideate\u002Fevals\u002Fevals.json",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"evals\u002FREADME.md",2886,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fideate\u002Fevals\u002FREADME.md",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fcontext-template.md",1781,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fideate\u002Freferences\u002Fcontext-template.md",{"path":87,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fevidence.md",3916,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fideate\u002Freferences\u002Fevidence.md",{"path":91,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fgenerate.md",4768,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fideate\u002Freferences\u002Fgenerate.md",{"path":95,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fidea-template.md",1525,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fideate\u002Freferences\u002Fidea-template.md",{"path":99,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Finventory.md",5175,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fideate\u002Freferences\u002Finventory.md",{"path":103,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fmarket-scan.md",4753,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fideate\u002Freferences\u002Fmarket-scan.md",{"path":107,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Freport-template.md",1882,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fideate\u002Freferences\u002Freport-template.md",[111,119,126,151,180,199],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":118},"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":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":125,"publishedAt":118},"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":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":45},"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",[],[133,134,25,135,136,137,138,139,43,140,141,142,143,144,145,146,147,44,148,149,150],"tickets","to tickets","signatures","github","plan","batch","task","manifest","plans","true","ticket","command","repo","for","feature","worktrees","as","cut",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":162,"publishedAt":45},"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",[157],{"categoryNo":158,"categoryName":159,"taxonomyType":160,"taxonomyTypeDesc":161},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[163,164,25,165,166,167,168,169,170,171,172,26,173,142,174,175,176,145,146,177,178,179,149,144],"to seams","schema","neither","it","but","file","prompt","either","use","writing","interface","repos","block","records","build","can","record",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":187,"publishedAt":45},"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",[186],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[188,36,37,149,147,189,190,26,191,192,193,133,32,24,137,194,195,142,143,196,197,198],"to roadmap","via","features","doc","board","about","self","now","card","re","ideas",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":206,"publishedAt":45},"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",[205],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[207,208,209,210,211,212,213,214,133,215,137,216,217,218,142,197,147,219,27,149],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem"]