[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H80YBD5JV8RGGQ8FCGDSNF":3,"skill-same:01M6H80YBD5JV8RGGQ8FCGDSNF":85},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6H80YBD5JV8RGGQ8FCGDSNF","compare-tools",null,"Use whenever the user needs to *choose* a technology, library or tool for this project: \"which library should I use\", \"help me pick a tool\", \"what's the best X for this\", \"compare these technologies\", \"should I use X or Y\", \"what are my options for Z\". Trigger even when it isn't phrased as a comparison. Explores the codebase, aligns on priorities (community support, maintenance, lock-in, extensibility), researches the market, and writes a report to .\u002Fideas\u002F with every viable option, doc links, a comparison table, and a ranked list scored out of 100 against the user's own priorities.","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\u002Fcode\u002Fcompare-tools\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"Tools","compare tools","compare","me","when","lock","my","which","as","project","priorities","options","support","community","list","pick","option","choose","table","doc","library","2026-11-10 10:12:30",false,"---\nname: compare-tools\ndescription: >\n  Use whenever the user needs to *choose* a technology, library or tool for this project:\n  \"which library should I use\", \"help me pick a tool\", \"what's the best X for this\", \"compare\n  these technologies\", \"should I use X or Y\", \"what are my options for Z\". Trigger even when it\n  isn't phrased as a comparison. Explores the codebase, aligns on priorities (community support,\n  maintenance, lock-in, extensibility), researches the market, and writes a report to .\u002Fideas\u002F\n  with every viable option, doc links, a comparison table, and a ranked list scored out of 100\n  against the user's own priorities.\n---\n\n# Compare Tools\n\nHelp the user pick the right technology for a specific use case. The output is a grounded,\nauditable recommendation — not a generic listicle, but a score derived from *this codebase's*\nshape and *this user's* stated priorities.\n\n## Operating principles\n\n- **Codebase first.** Technology decisions are context-dependent. Understand what's already here\n  before evaluating what might be added.\n- **Priorities are the rubric.** Don't rank tools on your own taste. Derive the ranking from the\n  user's stated priorities weighted against observed options. Show the arithmetic.\n- **Push back when it matters.** If a stated priority contradicts the observed codebase (e.g.\n  \"avoid vendor lock-in\" in a repo already deep in AWS), name that tension and ask them to\n  reconcile. Don't push back reflexively — only when the conflict is real and material.\n- **Research, don't invent.** Don't claim a tool has a feature unless you can verify it. If\n  unsure, say so or omit the claim.\n- **One question at a time.** Use `AskUserQuestion` for every clarification. Never batch\n  questions — each answer may change what you ask next.\n\n---\n\n## Phase 1 — Alignment\n\n### 1a. Explore the codebase\n\nRead the following in order, stopping when you have enough to write a one-paragraph\ncharacterisation:\n\n1. `README.md` and `CLAUDE.md` (or `CLAUDE.local.md`) — project intent and conventions\n2. Top-level `docs\u002F` if it exists\n3. Dependency manifests — whichever of these exist:\n   - `package.json` \u002F `package-lock.json` (Node\u002FTS)\n   - `pyproject.toml` \u002F `requirements.txt` (Python)\n   - `go.mod` (Go)\n   - `Cargo.toml` (Rust)\n   - `Gemfile` (Ruby)\n4. Recent git log: `git log --oneline -20`\n\nCharacterise the codebase in one paragraph: *type of project, primary language\u002Fruntime,\nwhat's already installed, who it's for, what it does.* Surface this so the user can correct\na wrong framing before the research phase.\n\n### 1b. Confirm the use case\n\nState your understanding of what the user wants to choose a tool for and ask them to confirm\nor correct it. If the use case is under-specified — \"I need a database\", \"pick a queue\",\n\"something for caching\" — invoke the `grilling` skill to resolve the decision tree:\nscale, read\u002Fwrite mix, latency, hosting constraints, team familiarity, existing\ninfrastructure, etc. Skip `grilling` if the use case is already crisp.\n\n### 1c. Elicit priorities\n\nPresent a short list of common high-level priorities from `references\u002Fpriority-catalogue.md`\nand ask the user to pick 3–5 that matter most to them, then rank them. Use `AskUserQuestion`\n— one question at a time. Rankings become the rubric weights in Phase 3.\n\nGood default priorities to offer:\n- Community support\n- Maintenance activity\n- Avoiding vendor lock-in\n- Extensibility \u002F composability\n- Ecosystem fit (language + framework)\n- License\n- Performance\n- Learning curve\n- Cost\n- Operational burden\n\n### 1d. Sensible push-back\n\nAfter the priorities are in, check them against what you observed in Phase 1a. If a stated\npriority contradicts the codebase:\n\n- **Real conflict**: \"You said 'avoid vendor lock-in', but the repo already uses AWS Secrets\n  Manager, CloudWatch, and S3. Adding a vendor-neutral queue would be swimming upstream — is\n  that still the goal, or should we score SQS more favorably?\" Ask via `AskUserQuestion`.\n- **No conflict**: say nothing. Don't manufacture friction.\n\n---\n\n## Phase 2 — Research\n\nUse `WebSearch` to survey the market. Aim for **4–7 candidates** covering:\n\n- The mature\u002Fdefault choice (the boring, safe option)\n- 1–2 newer or popular challengers\n- At least one left-field option that could win on the user's specific priorities\n- Any option already in the dependency manifests (it may already be installed)\n\nFor each candidate, record:\n\n| Field | What to capture |\n|-------|----------------|\n| One-liner | What it is in one sentence |\n| Strengths | Primary advantages, typical use cases |\n| Weaknesses | Known pain points, limitations |\n| Maintenance | Last release date, release cadence, # of active maintainers |\n| License | MIT \u002F Apache \u002F GPL \u002F commercial \u002F etc. |\n| Doc URL | Canonical documentation URL |\n\nDon't invent features or claims. If you can't verify something, note \"unverified\" or omit it.\n\n---\n\n## Phase 3 — Output\n\n### Resolve the output path\n\n```bash\nmkdir -p .\u002Fideas\nDATE=$(date -u +%Y-%m-%d)\nSLUG=\"\u003Cshort-kebab-case-topic>\"   # e.g. \"job-queue\", \"vector-db\", \"state-manager\"\nBASE=\".\u002Fideas\u002F${DATE}-tech-${SLUG}\"\nOUT=\"${BASE}.md\"; N=2\nwhile [ -e \"$OUT\" ]; do OUT=\"${BASE}-${N}.md\"; N=$((N+1)); done\necho \"$OUT\"\n```\n\nWrite the report to the echoed path using `references\u002Freport-template.md`.\n\n### Report structure\n\nThe report must contain exactly these five sections in order:\n\n1. **Context** — one paragraph: codebase characterisation + the confirmed use case. If `grilling`\n   ran, summarise the key answers that shaped the shortlist.\n\n2. **Priorities & rubric** — the ranked priorities, their weights (must sum to 100), and scoring\n   anchors for each priority (what 0 \u002F 50 \u002F 100 looks like). See `references\u002Frubric.md` for how\n   to derive weights and write anchors.\n\n3. **Options** — one sub-section per candidate:\n   ```\n   ### [Tool name]\n   [One-liner]\n   - **Strengths**: ...\n   - **Weaknesses**: ...\n   - **License**: ... | **Last release**: ... | **Docs**: [url]\n   ```\n\n4. **Comparison table** — rows = tools, columns = each priority + a final \"Score \u002F100\" column.\n   Show the raw score per priority (0–100), then the weighted total. This lets the user audit\n   your arithmetic.\n\n   | Tool | Priority 1 (W%) | Priority 2 (W%) | ... | Score \u002F100 |\n   |------|----------------|----------------|-----|-----------|\n   | A | 80 | 60 | ... | 72 |\n\n5. **Ranked recommendations** — tools sorted descending by compatibility score. For each:\n   - Score \u002F100\n   - 2–3 sentences tying the score back to observed codebase facts and the aligned priorities\n   - Flag the **top recommendation** prominently\n\n   End with: \"Next step: feed this decision into `to-prd` or open a design doc.\"\n\n---\n\n## Quality bar (self-check before writing)\n\n- [ ] Characterisation is grounded in files actually read, not assumed\n- [ ] Use case was confirmed or clarified (via `grilling` if fuzzy)\n- [ ] Priorities were user-stated, not inferred from your own preferences\n- [ ] Rubric weights sum to 100\n- [ ] All scores are derivable from the stated anchors — no magic numbers\n- [ ] Every option has a verified doc URL\n- [ ] No invented features or unverified claims\n- [ ] Push-back was offered only when a real conflict existed\n- [ ] The report can be scanned in under 5 minutes\n","# Compare Tools\n\nHelp the user pick the right technology for a specific use case. The output is a grounded,\nauditable recommendation — not a generic listicle, but a score derived from *this codebase's*\nshape and *this user's* stated priorities.\n\n## Operating principles\n\n- **Codebase first.** Technology decisions are context-dependent. Understand what's already here\n  before evaluating what might be added.\n- **Priorities are the rubric.** Don't rank tools on your own taste. Derive the ranking from the\n  user's stated priorities weighted against observed options. Show the arithmetic.\n- **Push back when it matters.** If a stated priority contradicts the observed codebase (e.g.\n  \"avoid vendor lock-in\" in a repo already deep in AWS), name that tension and ask them to\n  reconcile. Don't push back reflexively — only when the conflict is real and material.\n- **Research, don't invent.** Don't claim a tool has a feature unless you can verify it. If\n  unsure, say so or omit the claim.\n- **One question at a time.** Use `AskUserQuestion` for every clarification. Never batch\n  questions — each answer may change what you ask next.\n\n---\n\n## Phase 1 — Alignment\n\n### 1a. Explore the codebase\n\nRead the following in order, stopping when you have enough to write a one-paragraph\ncharacterisation:\n\n1. `README.md` and `CLAUDE.md` (or `CLAUDE.local.md`) — project intent and conventions\n2. Top-level `docs\u002F` if it exists\n3. Dependency manifests — whichever of these exist:\n   - `package.json` \u002F `package-lock.json` (Node\u002FTS)\n   - `pyproject.toml` \u002F `requirements.txt` (Python)\n   - `go.mod` (Go)\n   - `Cargo.toml` (Rust)\n   - `Gemfile` (Ruby)\n4. Recent git log: `git log --oneline -20`\n\nCharacterise the codebase in one paragraph: *type of project, primary language\u002Fruntime,\nwhat's already installed, who it's for, what it does.* Surface this so the user can correct\na wrong framing before the research phase.\n\n### 1b. Confirm the use case\n\nState your understanding of what the user wants to choose a tool for and ask them to confirm\nor correct it. If the use case is under-specified — \"I need a database\", \"pick a queue\",\n\"something for caching\" — invoke the `grilling` skill to resolve the decision tree:\nscale, read\u002Fwrite mix, latency, hosting constraints, team familiarity, existing\ninfrastructure, etc. Skip `grilling` if the use case is already crisp.\n\n### 1c. Elicit priorities\n\nPresent a short list of common high-level priorities from `references\u002Fpriority-catalogue.md`\nand ask the user to pick 3–5 that matter most to them, then rank them. Use `AskUserQuestion`\n— one question at a time. Rankings become the rubric weights in Phase 3.\n\nGood default priorities to offer:\n- Community support\n- Maintenance activity\n- Avoiding vendor lock-in\n- Extensibility \u002F composability\n- Ecosystem fit (language + framework)\n- License\n- Performance\n- Learning curve\n- Cost\n- Operational burden\n\n### 1d. Sensible push-back\n\nAfter the priorities are in, check them against what you observed in Phase 1a. If a stated\npriority contradicts the codebase:\n\n- **Real conflict**: \"You said 'avoid vendor lock-in', but the repo already uses AWS Secrets\n  Manager, CloudWatch, and S3. Adding a vendor-neutral queue would be swimming upstream — is\n  that still the goal, or should we score SQS more favorably?\" Ask via `AskUserQuestion`.\n- **No conflict**: say nothing. Don't manufacture friction.\n\n---\n\n## Phase 2 — Research\n\nUse `WebSearch` to survey the market. Aim for **4–7 candidates** covering:\n\n- The mature\u002Fdefault choice (the boring, safe option)\n- 1–2 newer or popular challengers\n- At least one left-field option that could win on the user's specific priorities\n- Any option already in the dependency manifests (it may already be installed)\n\nFor each candidate, record:\n\n| Field | What to capture |\n|-------|----------------|\n| One-liner | What it is in one sentence |\n| Strengths | Primary advantages, typical use cases |\n| Weaknesses | Known pain points, limitations |\n| Maintenance | Last release date, release cadence, # of active maintainers |\n| License | MIT \u002F Apache \u002F GPL \u002F commercial \u002F etc. |\n| Doc URL | Canonical documentation URL |\n\nDon't invent features or claims. If you can't verify something, note \"unverified\" or omit it.\n\n---\n\n## Phase 3 — Output\n\n### Resolve the output path\n\n```bash\nmkdir -p .\u002Fideas\nDATE=$(date -u +%Y-%m-%d)\nSLUG=\"\u003Cshort-kebab-case-topic>\"   # e.g. \"job-queue\", \"vector-db\", \"state-manager\"\nBASE=\".\u002Fideas\u002F${DATE}-tech-${SLUG}\"\nOUT=\"${BASE}.md\"; N=2\nwhile [ -e \"$OUT\" ]; do OUT=\"${BASE}-${N}.md\"; N=$((N+1)); done\necho \"$OUT\"\n```\n\nWrite the report to the echoed path using `references\u002Freport-template.md`.\n\n### Report structure\n\nThe report must contain exactly these five sections in order:\n\n1. **Context** — one paragraph: codebase characterisation + the confirmed use case. If `grilling`\n   ran, summarise the key answers that shaped the shortlist.\n\n2. **Priorities & rubric** — the ranked priorities, their weights (must sum to 100), and scoring\n   anchors for each priority (what 0 \u002F 50 \u002F 100 looks like). See `references\u002Frubric.md` for how\n   to derive weights and write anchors.\n\n3. **Options** — one sub-section per candidate:\n   ```\n   ### [Tool name]\n   [One-liner]\n   - **Strengths**: ...\n   - **Weaknesses**: ...\n   - **License**: ... | **Last release**: ... | **Docs**: [url]\n   ```\n\n4. **Comparison table** — rows = tools, columns = each priority + a final \"Score \u002F100\" column.\n   Show the raw score per priority (0–100), then the weighted total. This lets the user audit\n   your arithmetic.\n\n   | Tool | Priority 1 (W%) | Priority 2 (W%) | ... | Score \u002F100 |\n   |------|----------------|----------------|-----|-----------|\n   | A | 80 | 60 | ... | 72 |\n\n5. **Ranked recommendations** — tools sorted descending by compatibility score. For each:\n   - Score \u002F100\n   - 2–3 sentences tying the score back to observed codebase facts and the aligned priorities\n   - Flag the **top recommendation** prominently\n\n   End with: \"Next step: feed this decision into `to-prd` or open a design doc.\"\n\n---\n\n## Quality bar (self-check before writing)\n\n- [ ] Characterisation is grounded in files actually read, not assumed\n- [ ] Use case was confirmed or clarified (via `grilling` if fuzzy)\n- [ ] Priorities were user-stated, not inferred from your own preferences\n- [ ] Rubric weights sum to 100\n- [ ] All scores are derivable from the stated anchors — no magic numbers\n- [ ] Every option has a verified doc URL\n- [ ] No invented features or unverified claims\n- [ ] Push-back was offered only when a real conflict existed\n- [ ] The report can be scanned in under 5 minutes\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fcode\u002Fcompare-tools","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":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill compare-tools",{"tool":59,"command":60},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill compare-tools",{"tool":62,"command":63},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill compare-tools","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fcompare-tools\u002FSKILL.md",true,[67,73,77,81],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"evals\u002Fevals.json","REFERENCE","参考文档",3342,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fcompare-tools\u002Fevals\u002Fevals.json",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fpriority-catalogue.md",4978,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fcompare-tools\u002Freferences\u002Fpriority-catalogue.md",{"path":78,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Freport-template.md",3348,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fcompare-tools\u002Freferences\u002Freport-template.md",{"path":82,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Frubric.md",6092,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fcompare-tools\u002Freferences\u002Frubric.md",[86,94,101,128,157,183],{"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":93},"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":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":93},"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":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":40},"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",[],[108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,27,127],"tickets","to tickets","new","signatures","github","plan","batch","task","code","manifest","plans","true","ticket","command","repo","for","feature","run","worktrees","cut",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":139,"publishedAt":40},"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",[134],{"categoryNo":135,"categoryName":136,"taxonomyType":137,"taxonomyTypeDesc":138},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[140,141,110,142,143,144,145,146,147,148,149,23,150,119,151,152,153,122,123,154,155,156,27,121],"to seams","schema","neither","it","but","file","prompt","either","use","writing","interface","repos","block","records","build","can","record",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":168,"publishedAt":40},"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",[163],{"categoryNo":164,"categoryName":165,"taxonomyType":166,"taxonomyTypeDesc":167},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[169,170,171,27,124,172,173,23,38,174,175,108,176,177,113,178,179,119,120,180,181,182],"to roadmap","roadmap","never","via","features","board","about","next","later","self","now","card","re","ideas",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":190,"publishedAt":40},"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",[189],{"categoryNo":164,"categoryName":165,"taxonomyType":166,"taxonomyTypeDesc":167},[191,192,193,194,195,196,197,198,108,199,113,200,201,202,119,181,124,203,26,27],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem"]