[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H841JZTFACE7EBCJP9BA1Z":3,"skill-same:01M6H841JZTFACE7EBCJP9BA1Z":67},{"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":46,"commitSha":47,"skillDirectory":48,"forksCount":14,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":66},"01M6H841JZTFACE7EBCJP9BA1Z","review-skills",null,"Audit all skills available in the current project context for conflicts, quality issues, and replicable patterns. Use when user wants to review skills, audit skills, check skill quality, find conflicting or overlapping skills, improve skill descriptions, check what skills are installed, or mentions \"review-skills\". Always use this skill when the user wants to understand the health or completeness of their skill setup.","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\u002Fmeta\u002Freview-skills\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"review skills","review","use","when","for","true","understand","completeness","project","patterns","project context","conflicts","check","find","quality","improve","health","audit","improve skill","issues","setup","2026-11-10 10:12:30",false,"---\nname: review-skills\ndescription: Audit all skills available in the current project context for conflicts, quality issues, and replicable patterns. Use when user wants to review skills, audit skills, check skill quality, find conflicting or overlapping skills, improve skill descriptions, check what skills are installed, or mentions \"review-skills\". Always use this skill when the user wants to understand the health or completeness of their skill setup.\ndisable-model-invocation: true\n---\n\n# Review Skills\n\nAudit every skill available in the current project context and produce a structured report covering conflicts, quality issues, and patterns worth spreading.\n\n## Process\n\n### 1. Discover skills in scope\n\nLocate the installed skills first — **do not assume a location, check which ones exist**. Installed skills live in different places depending on how they were installed, and scanning a single hardcoded path is how this audit silently reports zero skills:\n\n```bash\nfor d in ~\u002F.agents\u002Fskills ~\u002F.claude\u002Fskills \"$PWD\u002F.claude\u002Fskills\"; do\n  [ -d \"$d\" ] && printf '%s: %s skills\\n' \"$d\" \"$(find \"$d\" -maxdepth 2 -name SKILL.md | wc -l)\"\ndone\n```\n\n- `~\u002F.agents\u002Fskills\u002F` — installed via `npx skills add`, flat, one directory per skill. Usually the real set.\n- `~\u002F.claude\u002Fskills\u002F` — global skills\n- `\u003Ccwd>\u002F.claude\u002Fskills\u002F` — project-local skills installed into this project\n- Plugins: read `~\u002F.claude\u002Fsettings.json` for `enabledPlugins`, then find their SKILL.md files under `~\u002F.claude\u002Fplugins\u002Fcache\u002F`\n\nIf `~\u002F.agents\u002F.skill-lock.json` exists, read it. It records each installed skill's `source` and `skillPath` in its origin repo, which lets you spot two problems a directory listing cannot: entries whose `skillPath` no longer exists upstream (the skill was renamed or moved, so `npx skills update` can no longer follow it), and installed copies that have drifted behind their source.\n\nBy default, audit what is **installed** — that is what actually loads. A source repo's `skills\u002F` directory is development-only. But when the user points you at a repo's `skills\u002F` directory, or asks about skills they are authoring, review the source instead and say which you reviewed. If both exist, compare them: a source repo that has renamed or restructured its skills while the installed copies still carry the old names is a real, silent failure — every cross-skill reference in the new generation dangles at runtime.\n\nFor each skill found, record:\n- **Source**: installed (`~\u002F.agents\u002Fskills`), global, project-local, plugin, or source repo\n- **Path**: absolute path to SKILL.md\n- **Name**: from `name` frontmatter field\n- **Description**: from `description` frontmatter field\n- **Body line count**: lines in SKILL.md excluding frontmatter\n- **Bundled resources**: whether references\u002F, scripts\u002F, or assets\u002F exist alongside SKILL.md\n\nRead every SKILL.md in full. Note referenced supporting files but only read them if needed to resolve an ambiguity.\n\n### 2. Check for conflicts and overlaps\n\nCompare all skill pairs. Flag pairs where:\n- Descriptions share trigger phrases or keywords that would make selection ambiguous for an overlapping user prompt\n- Names are similar enough to confuse (e.g. `clean-code` vs `clean-comments`)\n- Both claim the same domain without clear differentiation\n\nFor each flagged pair, describe which user prompts would be ambiguous and suggest how to differentiate the descriptions.\n\n### 3. Evaluate each skill against the quality rubric\n\nFor each skill, check all 15 items below. Record pass\u002Ffail and a one-line note for any failing check. The purpose of these checks is to ensure skills trigger reliably and give the model clear, actionable guidance.\n\n\u003Cquality-rubric>\n**Frontmatter**\n1. `name` field exists and is kebab-case\n2. `name` matches the directory name\n3. `description` field exists\n4. Description follows the two-part pattern: what it does + when to use it (explicit trigger phrases)\n5. Description is under 1024 characters\n6. Description is \"pushy\" — lists specific trigger phrases rather than vague capability summaries (Claude undertriggers skills, so descriptions need to be explicit)\n\n**Size and structure**\n7. Body is under 500 lines\n8. If body exceeds 200 lines, large reference content is split into separate files rather than inlined\n9. Steps use numbered `###` headers rather than walls of prose\n10. No hardcoded absolute paths that break portability (`~` and relative paths are fine)\n\n**Instruction quality**\n11. Uses imperative form (\"Do X\" not \"You should do X\" or \"Claude will X\")\n12. Explains the *why* behind non-obvious instructions, not just *what* to do\n13. Output templates use consistent formatting (XML-style tags or fenced code blocks, not a mix)\n\n**Resources**\n14. Every file referenced by name in SKILL.md actually exists on disk\n15. If references\u002F, scripts\u002F or assets\u002F directories exist, SKILL.md mentions them so the model knows to use them. This applies to **model-facing** resources only — files the skill reads or renders at runtime. `evals\u002F`, `skill-feedback-ledger.md` and similar are development tooling the model never loads; requiring SKILL.md to mention them adds context noise and is not a finding.\n\u003C\u002Fquality-rubric>\n\nAssign severity to each failing check:\n- **Critical**: blocks correct skill usage (missing description, non-existent referenced files)\n- **Major**: meaningfully degrades output quality (vague triggers, missing why, hardcoded paths)\n- **Minor**: polish issues (style inconsistency, slightly verbose)\n\n### 4. Identify replicable good patterns\n\nLook across all skills for patterns worth adopting more broadly. Signal good work, not just problems. Patterns to watch for:\n\n- **Interview-before-action**: skill gathers requirements from the user before producing output — makes output more accurate and reduces rework\n- **GitHub issue as deliverable**: skill creates a structured GH issue — creates a durable record and fits code-review workflows\n- **Progressive disclosure**: SKILL.md is lean, with detailed content in reference files — keeps context window clean\n- **Vertical-slice philosophy**: work broken into thin end-to-end slices rather than layers\n- **Model override for simple tasks**: `model: haiku` in frontmatter for lightweight, mechanical skills — saves tokens and latency\n- **Bundled scripts for deterministic work**: scripts\u002F directory for code the skill always runs — avoids the model reinventing it each time\n\nFor each pattern found, note which skills use it and which other skills could benefit from adopting it, with a brief explanation of why it would help.\n\n### 5. Produce the audit report\n\n\u003Creport-template>\n## Skills Audit Report\n\n**Skills discovered**: [N] total — [N] installed, [N] global, [N] project-local, [N] plugin\n**Scanned**: [which locations existed and were read; say if you audited source rather than installed]\n\n---\n\n### Conflicts & Overlaps\n\n[For each flagged pair:]\n- **[skill-a] vs [skill-b]**: [which user prompts would be ambiguous]\n  - Suggestion: [how to differentiate descriptions]\n\n_If none:_ No conflicts detected.\n\n---\n\n### Quality Issues\n\n#### Critical\n- **[skill-name]**: [rubric check #] — [one-line problem description]\n  - Fix: [specific actionable change]\n\n#### Major\n[same format]\n\n#### Minor\n[same format]\n\n_If none in a category:_ None.\n\n---\n\n### Good Patterns Worth Spreading\n\n- **[pattern name]** — currently used in: [skill-a], [skill-b]\n  - Could benefit: [skill-x], [skill-y] — [brief explanation of how it would help]\n\n---\n\n### Per-Skill Scorecards\n\n**[skill-name]** ([source]) — [N] lines\n- Rubric: [N]\u002F15 checks passed\n- Strengths: [1-2 bullet points]\n- Top fix: [single most impactful improvement, or \"No issues found\"]\n\n[repeat for each skill]\n\u003C\u002Freport-template>\n\nKeep the report factual and concise. Cross-reference rather than repeat the same finding in multiple sections. If a skill passes all checks with no overlaps, say so briefly in its scorecard and move on.\n","# Review Skills\n\nAudit every skill available in the current project context and produce a structured report covering conflicts, quality issues, and patterns worth spreading.\n\n## Process\n\n### 1. Discover skills in scope\n\nLocate the installed skills first — **do not assume a location, check which ones exist**. Installed skills live in different places depending on how they were installed, and scanning a single hardcoded path is how this audit silently reports zero skills:\n\n```bash\nfor d in ~\u002F.agents\u002Fskills ~\u002F.claude\u002Fskills \"$PWD\u002F.claude\u002Fskills\"; do\n  [ -d \"$d\" ] && printf '%s: %s skills\\n' \"$d\" \"$(find \"$d\" -maxdepth 2 -name SKILL.md | wc -l)\"\ndone\n```\n\n- `~\u002F.agents\u002Fskills\u002F` — installed via `npx skills add`, flat, one directory per skill. Usually the real set.\n- `~\u002F.claude\u002Fskills\u002F` — global skills\n- `\u003Ccwd>\u002F.claude\u002Fskills\u002F` — project-local skills installed into this project\n- Plugins: read `~\u002F.claude\u002Fsettings.json` for `enabledPlugins`, then find their SKILL.md files under `~\u002F.claude\u002Fplugins\u002Fcache\u002F`\n\nIf `~\u002F.agents\u002F.skill-lock.json` exists, read it. It records each installed skill's `source` and `skillPath` in its origin repo, which lets you spot two problems a directory listing cannot: entries whose `skillPath` no longer exists upstream (the skill was renamed or moved, so `npx skills update` can no longer follow it), and installed copies that have drifted behind their source.\n\nBy default, audit what is **installed** — that is what actually loads. A source repo's `skills\u002F` directory is development-only. But when the user points you at a repo's `skills\u002F` directory, or asks about skills they are authoring, review the source instead and say which you reviewed. If both exist, compare them: a source repo that has renamed or restructured its skills while the installed copies still carry the old names is a real, silent failure — every cross-skill reference in the new generation dangles at runtime.\n\nFor each skill found, record:\n- **Source**: installed (`~\u002F.agents\u002Fskills`), global, project-local, plugin, or source repo\n- **Path**: absolute path to SKILL.md\n- **Name**: from `name` frontmatter field\n- **Description**: from `description` frontmatter field\n- **Body line count**: lines in SKILL.md excluding frontmatter\n- **Bundled resources**: whether references\u002F, scripts\u002F, or assets\u002F exist alongside SKILL.md\n\nRead every SKILL.md in full. Note referenced supporting files but only read them if needed to resolve an ambiguity.\n\n### 2. Check for conflicts and overlaps\n\nCompare all skill pairs. Flag pairs where:\n- Descriptions share trigger phrases or keywords that would make selection ambiguous for an overlapping user prompt\n- Names are similar enough to confuse (e.g. `clean-code` vs `clean-comments`)\n- Both claim the same domain without clear differentiation\n\nFor each flagged pair, describe which user prompts would be ambiguous and suggest how to differentiate the descriptions.\n\n### 3. Evaluate each skill against the quality rubric\n\nFor each skill, check all 15 items below. Record pass\u002Ffail and a one-line note for any failing check. The purpose of these checks is to ensure skills trigger reliably and give the model clear, actionable guidance.\n\n\u003Cquality-rubric>\n**Frontmatter**\n1. `name` field exists and is kebab-case\n2. `name` matches the directory name\n3. `description` field exists\n4. Description follows the two-part pattern: what it does + when to use it (explicit trigger phrases)\n5. Description is under 1024 characters\n6. Description is \"pushy\" — lists specific trigger phrases rather than vague capability summaries (Claude undertriggers skills, so descriptions need to be explicit)\n\n**Size and structure**\n7. Body is under 500 lines\n8. If body exceeds 200 lines, large reference content is split into separate files rather than inlined\n9. Steps use numbered `###` headers rather than walls of prose\n10. No hardcoded absolute paths that break portability (`~` and relative paths are fine)\n\n**Instruction quality**\n11. Uses imperative form (\"Do X\" not \"You should do X\" or \"Claude will X\")\n12. Explains the *why* behind non-obvious instructions, not just *what* to do\n13. Output templates use consistent formatting (XML-style tags or fenced code blocks, not a mix)\n\n**Resources**\n14. Every file referenced by name in SKILL.md actually exists on disk\n15. If references\u002F, scripts\u002F or assets\u002F directories exist, SKILL.md mentions them so the model knows to use them. This applies to **model-facing** resources only — files the skill reads or renders at runtime. `evals\u002F`, `skill-feedback-ledger.md` and similar are development tooling the model never loads; requiring SKILL.md to mention them adds context noise and is not a finding.\n\u003C\u002Fquality-rubric>\n\nAssign severity to each failing check:\n- **Critical**: blocks correct skill usage (missing description, non-existent referenced files)\n- **Major**: meaningfully degrades output quality (vague triggers, missing why, hardcoded paths)\n- **Minor**: polish issues (style inconsistency, slightly verbose)\n\n### 4. Identify replicable good patterns\n\nLook across all skills for patterns worth adopting more broadly. Signal good work, not just problems. Patterns to watch for:\n\n- **Interview-before-action**: skill gathers requirements from the user before producing output — makes output more accurate and reduces rework\n- **GitHub issue as deliverable**: skill creates a structured GH issue — creates a durable record and fits code-review workflows\n- **Progressive disclosure**: SKILL.md is lean, with detailed content in reference files — keeps context window clean\n- **Vertical-slice philosophy**: work broken into thin end-to-end slices rather than layers\n- **Model override for simple tasks**: `model: haiku` in frontmatter for lightweight, mechanical skills — saves tokens and latency\n- **Bundled scripts for deterministic work**: scripts\u002F directory for code the skill always runs — avoids the model reinventing it each time\n\nFor each pattern found, note which skills use it and which other skills could benefit from adopting it, with a brief explanation of why it would help.\n\n### 5. Produce the audit report\n\n\u003Creport-template>\n## Skills Audit Report\n\n**Skills discovered**: [N] total — [N] installed, [N] global, [N] project-local, [N] plugin\n**Scanned**: [which locations existed and were read; say if you audited source rather than installed]\n\n---\n\n### Conflicts & Overlaps\n\n[For each flagged pair:]\n- **[skill-a] vs [skill-b]**: [which user prompts would be ambiguous]\n  - Suggestion: [how to differentiate descriptions]\n\n_If none:_ No conflicts detected.\n\n---\n\n### Quality Issues\n\n#### Critical\n- **[skill-name]**: [rubric check #] — [one-line problem description]\n  - Fix: [specific actionable change]\n\n#### Major\n[same format]\n\n#### Minor\n[same format]\n\n_If none in a category:_ None.\n\n---\n\n### Good Patterns Worth Spreading\n\n- **[pattern name]** — currently used in: [skill-a], [skill-b]\n  - Could benefit: [skill-x], [skill-y] — [brief explanation of how it would help]\n\n---\n\n### Per-Skill Scorecards\n\n**[skill-name]** ([source]) — [N] lines\n- Rubric: [N]\u002F15 checks passed\n- Strengths: [1-2 bullet points]\n- Top fix: [single most impactful improvement, or \"No issues found\"]\n\n[repeat for each skill]\n\u003C\u002Freport-template>\n\nKeep the report factual and concise. Cross-reference rather than repeat the same finding in multiple sections. If a skill passes all checks with no overlaps, say so briefly in its scorecard and move on.\n",{"name":5,"description":7,"disable-model-invocation":45},true,"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fmeta\u002Freview-skills","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 04:20:46",{"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 review-skills",{"tool":60,"command":61},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill review-skills",{"tool":63,"command":64},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill review-skills","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Freview-skills\u002FSKILL.md",[],[68,94,122,149,171,189],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"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",[],[75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,24,23,93],"to tickets","tickets","github","run","code","batch","manifest","plan","repo","command","worktrees","task","signatures","feature","plans","as","cut","ticket","new",{"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":105,"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",[100],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[106,107,108,109,83,110,84,21,111,112,113,114,115,90,116,117,118,119,24,120,23,121,22,93],"to seams","writing","repos","file","prompt","schema","build","but","either","record","records","it","block","interface","can","neither",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":133,"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",[128],{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[134,135,136,82,137,138,139,140,141,142,88,90,92,143,144,76,145,146,147,24,148,22],"roadmap","to roadmap","doc","board","never","later","next","self","ideas","via","card","now","about","re","features",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":156,"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",[155],{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},[157,158,159,160,82,161,162,163,88,90,164,165,76,166,167,168,147,24,169,170],"to prd","prd","report","state","ask","say","delivery","line","problem","spine","multi","interviews","which","codebase",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":40},"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",[],[82,178,179,79,109,180,181,182,183,184,21,111,185,27,186,88,89,187,24,23,188,93],"to plan","pr","ports","glossary","branch","short","overview","only","contract","types","\u003Cslug>",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":40},"01M6H87XEQEXSGT0PR5QWQZZ5P","ticket-tracker","Use when the request is about the *current state* of GitHub issues rather than creating new ones: \"where are my tickets\", \"show the board\", \"what's in progress\", \"what's ready to pick up\", \"move issue N to in-review\", \"mark N done\", \"update the ticket status\". Live triage board over GitHub issues via the gh CLI, moving each between backlog -> ready -> in-progress -> in-review -> done using status labels. This is the ticket-level board; .\u002Fideas\u002Froadmap.html is the feature-level one. To file new tickets, use \u002Fto-tickets, file-issue for a single ad-hoc one, or \u002Fsweep for a batch of small fixes.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fticket-tracker\u002FSKILL.md",[],[196,92,197,20,198,199,200,38,80,109,201,202,21,203,134,204,205,206,207,142,88,208,209,23,210,211,212,22,93],"tracker","ticket tracker","cli","current state","update","gh","pick","ready","up","show","done","backlog","progress","move","fixes","labels","request"]