[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H845P7DVR6XRWX3HXCA6KV":3,"skill-same:01M6H845P7DVR6XRWX3HXCA6KV":74},{"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":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M6H845P7DVR6XRWX3HXCA6KV","skill-brief",null,"Turns a rough idea for a new skill into a skill-creator-ready brief — the prep work a careful person does by hand before building: source prior art, decide what's worth lifting vs. what only half-fits, check the idea doesn't duplicate a skill you already have, and package the decisions. It does NOT write the final skill; it produces the brief skill-creator builds from. Use when the user says \"skill-brief\", \"brief for a skill\", \"source and synthesise skills for X\", \"what's out there before I build a skill for X\", \"I have an idea for a skill, help me scope it\", \"capture this into a skill brief\", or \"turn this into a skill-creator prompt\". Trigger proactively whenever someone is about to start a skill-creator session from a raw idea and hasn't sourced prior art yet — the sourcing pass is exactly what prevents building a duplicate.","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\u002Fskill-brief\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"skill brief","brief","me","new","when","skill-creator","sourcing","source","for","hand","you","scope","trigger","new skill","idea","Art","ready","only","write","decide","work","careful","start","2026-11-10 10:12:30",false,"---\nname: skill-brief\ndescription: >\n  Turns a rough idea for a new skill into a skill-creator-ready brief — the prep work\n  a careful person does by hand before building: source prior art, decide what's worth\n  lifting vs. what only half-fits, check the idea doesn't duplicate a skill you already\n  have, and package the decisions. It does NOT write the final skill; it produces the\n  brief skill-creator builds from. Use when the user says \"skill-brief\", \"brief for a\n  skill\", \"source and synthesise skills for X\", \"what's out there before I build a skill\n  for X\", \"I have an idea for a skill, help me scope it\", \"capture this into a skill\n  brief\", or \"turn this into a skill-creator prompt\". Trigger proactively whenever\n  someone is about to start a skill-creator session from a raw idea and hasn't sourced\n  prior art yet — the sourcing pass is exactly what prevents building a duplicate.\n---\n\n# Skill Brief\n\nYou turn a rough skill idea into a decision-ready brief that `skill-creator` can build from. You are the step *before* skill-creator: source prior art, decide what to lift, confirm it isn't a duplicate, and package the choices. You never write the final skill — that would rob skill-creator of the interview it does well and rob the user of the review pauses that make the brief trustworthy.\n\n## Shape — three modes, one per invocation\n\n```\nSOURCE  →  (user reviews)  →  CAPTURE  →  (user reviews)  →  HANDOFF  →  skill-creator\n```\n\nEach mode does one thing, writes one file, and **stops**. The review pauses between modes are the whole point — the user reads what you found, adds notes, and only then do you advance. Never chain source → handoff in a single run; a brief nobody reviewed is just a guess with extra steps.\n\nRoute by what the user gives you:\n\n| Input | Mode |\n|-------|------|\n| A fresh skill idea \u002F description | **SOURCE** |\n| \"capture\" (or notes on `sources.md`) | **CAPTURE** |\n| \"handoff\" (or \"turn this into a skill-creator prompt\") | **HANDOFF** |\n\nAll working files live in `.claude\u002Fskill-brief\u002F` in the current repo — these are personal scratch, not committed artifacts. Don't put them in `docs\u002F`. (The user can `.gitignore .claude\u002Fskill-brief\u002F` if they want; you don't need to.)\n\n---\n\n## SOURCE mode\n\nGoal: a `sources.md` that tells the user whether to build at all, and if so, what prior art to steal from.\n\n### 1. Delegate discovery to find-skills\n\nInvoke the existing **`find-skills`** skill for the idea. It already searches skills.sh, the Skills CLI, GitHub code search, GitHub collections, and local installs, ranks candidates, and produces a table plus a landscape synthesis. Do **not** reimplement any of that.\n\nWhen find-skills finishes it will offer its own \"reply build it\" CTA — **ignore that CTA** and continue with skill-brief's flow below. You want its table and synthesis, not its handoff.\n\n### 2. Add \"what to lift\" per candidate — the part find-skills skips\n\nfind-skills ranks by relevance; it does not read each candidate and tell you what to take. That's your job. For each candidate worth considering, read its `SKILL.md` and write a blunt note keyed by the skill's catalog number (see step 4):\n\n- **Partial match** → \"lift X, ignore the rest\" (name the one technique or structure worth taking).\n- **Full match** → \"grab wholesale\" — and that's a signal the idea might be a duplicate; see step 3.\n\nDon't pad this list. A candidate with nothing worth lifting doesn't belong in the Candidates list — drop it (it still appears in the catalog above). Three real lifts beat ten polite ones.\n\n### 3. Compliance review vs. skills the user already has\n\nScan the user's own installed skills — not just what's on the internet:\n\n```bash\nls skills\u002F ~\u002F.claude\u002Fskills\u002F .claude\u002Fskills\u002F 2>\u002Fdev\u002Fnull\n```\n\nRead the `description` of anything that looks close. If the idea duplicates a skill the user already has, **say so plainly** and recommend not building it (or building a narrower thing the existing skill doesn't cover). Catching a duplicate here is the single most valuable thing this mode does — a \"don't build, you already have X\" verdict just saved the user an afternoon.\n\nFor a full health audit of their whole skill set (conflicts, stale descriptions), point them at **`review-skills`** — that's a different job and not something you inline here.\n\n### 4. Write `sources.md`\n\nWrite `.claude\u002Fskill-brief\u002Fsources.md`, tables over prose. Assign every skill find-skills surfaced a **stable incrementing number** in the catalog — that number is the skill's canonical ID for the rest of the brief's life. Reference it (not the name) everywhere downstream: candidates, compliance, notes, and any follow-up command.\n\n```markdown\n# Skill brief — sources: {idea}\n\n**Verdict:** {build \u002F build narrower (duplicates parts of X) \u002F don't build (X already covers this)}\n\n## Similar skills found\nReproduce find-skills' ranked results — do NOT pre-digest them away; this is the browsable catalog the user reads from. One table per capability area of the brief. Number skills continuously across all tables (1, 2, 3 …).\n\n### {capability area}\n| # | Skill | Installs | Source | Relevance | Link |\n|---|-------|----------|--------|-----------|------|\n| 1 | ... | 95.1K | ✅ Microsoft | ... | url |\n| 2 | ... | 13.5K | community | ... | url |\n\n## Candidates — what to lift\nOnly the numbered skills worth stealing from, by their catalog number — drop any with nothing worth lifting (they stay in the catalog above, just not here):\n\n3. **{skill-name}**\n   - lift: {technique \u002F structure worth taking}\n   - leave: {what to ignore}\n\n## Compliance — vs. skills you already have\n| # | Existing skill | Overlap | Verdict |\n|---|----------------|---------|---------|\n| ... | ... | none \u002F partial \u002F full | safe to build \u002F narrow it \u002F skip |\n\n## Landscape\n{the synthesis paragraphs from find-skills — the readable overview of the field}\n\n## Your notes\n\u003C!-- For each catalogued skill, add bullets you want captured. Leave a skill's bullets empty to capture nothing for it. Then run skill-brief in \"capture\" mode. -->\n1. {skill-name} —\n2. {skill-name} —\n```\n\nList every catalogued skill in \"Your notes\" by its number, so the user has one slot per skill; an empty slot means \"capture nothing for this one\".\n\n### 5. Tell the user and stop\n\nGive the one-line verdict, name the top 2–3 lifts in the conversation, then: \"Full breakdown in `.claude\u002Fskill-brief\u002Fsources.md` — add notes there, then say **capture** to lock in the decisions.\" Do not advance on your own.\n\n---\n\n## CAPTURE mode\n\nGoal: a tight decision record so skill-creator inherits *decisions*, not a research dump.\n\nRe-read `.claude\u002Fskill-brief\u002Fsources.md`, **including the user's per-skill notes** — those override your original recommendations. If any note raises a clarifying question or contradicts a recommendation (e.g. asks to lift from a skill you flagged as a full-match duplicate), invoke **`\u002Fgrilling`** to stress-test the decision *before* writing `capture.md` — don't silently bake the contradiction in. Preserve the catalog numbers from `sources.md` verbatim when referencing skills. Then write `.claude\u002Fskill-brief\u002Fcapture.md`:\n\n```markdown\n# Skill brief — capture: {name}\n\n## Decision\n{build \u002F build narrower \u002F don't build} · **name:** {proposed-name} · **modes:** {if any}\n\n## What it does\n- **In scope:** ...\n- **Out of scope:** ...\n\n## Lifted from prior art\n| Take | From (#) | How it's adapted |\n|------|----------|------------------|\n| ... | #3 [skill](url) | ... |\n\n## Deliberately not doing\n- {thing we could have built but chose not to, and why}\n\n## Open questions for skill-creator\n- ...\n```\n\nThe \"deliberately not doing\" list is as valuable as the lifts — it stops skill-creator from re-adding scope the user already rejected. Then tell the user it's ready and to say **handoff** when they want the skill-creator prompt. Stop.\n\n---\n\n## HANDOFF mode\n\nGoal: a self-contained prompt skill-creator can run cold.\n\nRe-read `.claude\u002Fskill-brief\u002Fcapture.md` and emit a prompt with: what to build, proposed name, shape\u002Fmodes, patterns to borrow (with source links and their catalog numbers, preserved verbatim from `sources.md`), out-of-scope list, and open questions. Print it in the conversation so the user can eyeball it, then offer to run `\u002Fskill-creator` with it (invoke the `skill-creator` skill on confirmation).\n\n---\n\n## What not to do\n\n- **Don't reimplement find-skills' discovery.** Marketplace\u002FGitHub\u002Flocal search is its job; call it, don't rebuild it.\n- **Don't force-fit adjacent skills.** `source-synthesis` digests URLs, `review-skills` audits skill-set health, `handoff` compacts a conversation for another agent — none is the sourcing-a-brief job. Point the user at them where relevant; don't wire them in.\n- **Don't skip the review pauses.** One mode per invocation. A brief the user never read is worthless.\n- **Don't write the final skill.** That's skill-creator's job, and it does the interview better with a clean brief.\n- **Don't pad \"what to lift\".** A candidate with nothing to steal gets dropped, not a courtesy row.\n","# Skill Brief\n\nYou turn a rough skill idea into a decision-ready brief that `skill-creator` can build from. You are the step *before* skill-creator: source prior art, decide what to lift, confirm it isn't a duplicate, and package the choices. You never write the final skill — that would rob skill-creator of the interview it does well and rob the user of the review pauses that make the brief trustworthy.\n\n## Shape — three modes, one per invocation\n\n```\nSOURCE  →  (user reviews)  →  CAPTURE  →  (user reviews)  →  HANDOFF  →  skill-creator\n```\n\nEach mode does one thing, writes one file, and **stops**. The review pauses between modes are the whole point — the user reads what you found, adds notes, and only then do you advance. Never chain source → handoff in a single run; a brief nobody reviewed is just a guess with extra steps.\n\nRoute by what the user gives you:\n\n| Input | Mode |\n|-------|------|\n| A fresh skill idea \u002F description | **SOURCE** |\n| \"capture\" (or notes on `sources.md`) | **CAPTURE** |\n| \"handoff\" (or \"turn this into a skill-creator prompt\") | **HANDOFF** |\n\nAll working files live in `.claude\u002Fskill-brief\u002F` in the current repo — these are personal scratch, not committed artifacts. Don't put them in `docs\u002F`. (The user can `.gitignore .claude\u002Fskill-brief\u002F` if they want; you don't need to.)\n\n---\n\n## SOURCE mode\n\nGoal: a `sources.md` that tells the user whether to build at all, and if so, what prior art to steal from.\n\n### 1. Delegate discovery to find-skills\n\nInvoke the existing **`find-skills`** skill for the idea. It already searches skills.sh, the Skills CLI, GitHub code search, GitHub collections, and local installs, ranks candidates, and produces a table plus a landscape synthesis. Do **not** reimplement any of that.\n\nWhen find-skills finishes it will offer its own \"reply build it\" CTA — **ignore that CTA** and continue with skill-brief's flow below. You want its table and synthesis, not its handoff.\n\n### 2. Add \"what to lift\" per candidate — the part find-skills skips\n\nfind-skills ranks by relevance; it does not read each candidate and tell you what to take. That's your job. For each candidate worth considering, read its `SKILL.md` and write a blunt note keyed by the skill's catalog number (see step 4):\n\n- **Partial match** → \"lift X, ignore the rest\" (name the one technique or structure worth taking).\n- **Full match** → \"grab wholesale\" — and that's a signal the idea might be a duplicate; see step 3.\n\nDon't pad this list. A candidate with nothing worth lifting doesn't belong in the Candidates list — drop it (it still appears in the catalog above). Three real lifts beat ten polite ones.\n\n### 3. Compliance review vs. skills the user already has\n\nScan the user's own installed skills — not just what's on the internet:\n\n```bash\nls skills\u002F ~\u002F.claude\u002Fskills\u002F .claude\u002Fskills\u002F 2>\u002Fdev\u002Fnull\n```\n\nRead the `description` of anything that looks close. If the idea duplicates a skill the user already has, **say so plainly** and recommend not building it (or building a narrower thing the existing skill doesn't cover). Catching a duplicate here is the single most valuable thing this mode does — a \"don't build, you already have X\" verdict just saved the user an afternoon.\n\nFor a full health audit of their whole skill set (conflicts, stale descriptions), point them at **`review-skills`** — that's a different job and not something you inline here.\n\n### 4. Write `sources.md`\n\nWrite `.claude\u002Fskill-brief\u002Fsources.md`, tables over prose. Assign every skill find-skills surfaced a **stable incrementing number** in the catalog — that number is the skill's canonical ID for the rest of the brief's life. Reference it (not the name) everywhere downstream: candidates, compliance, notes, and any follow-up command.\n\n```markdown\n# Skill brief — sources: {idea}\n\n**Verdict:** {build \u002F build narrower (duplicates parts of X) \u002F don't build (X already covers this)}\n\n## Similar skills found\nReproduce find-skills' ranked results — do NOT pre-digest them away; this is the browsable catalog the user reads from. One table per capability area of the brief. Number skills continuously across all tables (1, 2, 3 …).\n\n### {capability area}\n| # | Skill | Installs | Source | Relevance | Link |\n|---|-------|----------|--------|-----------|------|\n| 1 | ... | 95.1K | ✅ Microsoft | ... | url |\n| 2 | ... | 13.5K | community | ... | url |\n\n## Candidates — what to lift\nOnly the numbered skills worth stealing from, by their catalog number — drop any with nothing worth lifting (they stay in the catalog above, just not here):\n\n3. **{skill-name}**\n   - lift: {technique \u002F structure worth taking}\n   - leave: {what to ignore}\n\n## Compliance — vs. skills you already have\n| # | Existing skill | Overlap | Verdict |\n|---|----------------|---------|---------|\n| ... | ... | none \u002F partial \u002F full | safe to build \u002F narrow it \u002F skip |\n\n## Landscape\n{the synthesis paragraphs from find-skills — the readable overview of the field}\n\n## Your notes\n\u003C!-- For each catalogued skill, add bullets you want captured. Leave a skill's bullets empty to capture nothing for it. Then run skill-brief in \"capture\" mode. -->\n1. {skill-name} —\n2. {skill-name} —\n```\n\nList every catalogued skill in \"Your notes\" by its number, so the user has one slot per skill; an empty slot means \"capture nothing for this one\".\n\n### 5. Tell the user and stop\n\nGive the one-line verdict, name the top 2–3 lifts in the conversation, then: \"Full breakdown in `.claude\u002Fskill-brief\u002Fsources.md` — add notes there, then say **capture** to lock in the decisions.\" Do not advance on your own.\n\n---\n\n## CAPTURE mode\n\nGoal: a tight decision record so skill-creator inherits *decisions*, not a research dump.\n\nRe-read `.claude\u002Fskill-brief\u002Fsources.md`, **including the user's per-skill notes** — those override your original recommendations. If any note raises a clarifying question or contradicts a recommendation (e.g. asks to lift from a skill you flagged as a full-match duplicate), invoke **`\u002Fgrilling`** to stress-test the decision *before* writing `capture.md` — don't silently bake the contradiction in. Preserve the catalog numbers from `sources.md` verbatim when referencing skills. Then write `.claude\u002Fskill-brief\u002Fcapture.md`:\n\n```markdown\n# Skill brief — capture: {name}\n\n## Decision\n{build \u002F build narrower \u002F don't build} · **name:** {proposed-name} · **modes:** {if any}\n\n## What it does\n- **In scope:** ...\n- **Out of scope:** ...\n\n## Lifted from prior art\n| Take | From (#) | How it's adapted |\n|------|----------|------------------|\n| ... | #3 [skill](url) | ... |\n\n## Deliberately not doing\n- {thing we could have built but chose not to, and why}\n\n## Open questions for skill-creator\n- ...\n```\n\nThe \"deliberately not doing\" list is as valuable as the lifts — it stops skill-creator from re-adding scope the user already rejected. Then tell the user it's ready and to say **handoff** when they want the skill-creator prompt. Stop.\n\n---\n\n## HANDOFF mode\n\nGoal: a self-contained prompt skill-creator can run cold.\n\nRe-read `.claude\u002Fskill-brief\u002Fcapture.md` and emit a prompt with: what to build, proposed name, shape\u002Fmodes, patterns to borrow (with source links and their catalog numbers, preserved verbatim from `sources.md`), out-of-scope list, and open questions. Print it in the conversation so the user can eyeball it, then offer to run `\u002Fskill-creator` with it (invoke the `skill-creator` skill on confirmation).\n\n---\n\n## What not to do\n\n- **Don't reimplement find-skills' discovery.** Marketplace\u002FGitHub\u002Flocal search is its job; call it, don't rebuild it.\n- **Don't force-fit adjacent skills.** `source-synthesis` digests URLs, `review-skills` audits skill-set health, `handoff` compacts a conversation for another agent — none is the sourcing-a-brief job. Point the user at them where relevant; don't wire them in.\n- **Don't skip the review pauses.** One mode per invocation. A brief the user never read is worthless.\n- **Don't write the final skill.** That's skill-creator's job, and it does the interview better with a clean brief.\n- **Don't pad \"what to lift\".** A candidate with nothing to steal gets dropped, not a courtesy row.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fmeta\u002Fskill-brief","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":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill skill-brief",{"tool":66,"command":67},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill skill-brief",{"tool":69,"command":70},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill skill-brief","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fmeta\u002Fskill-brief\u002FSKILL.md",true,[],[75,83,90,116,141,168],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":82},"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":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":82},"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":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":47},"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",[],[97,98,27,99,100,101,102,103,104,105,106,107,108,109,110,32,111,112,113,114,115],"tickets","to tickets","signatures","github","plan","batch","task","code","manifest","plans","true","ticket","command","repo","feature","run","worktrees","as","cut",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":123,"publishedAt":47},"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",[122],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[124,125,27,126,127,128,129,130,131,132,133,28,134,107,135,136,137,110,32,138,139,140,114,109],"to seams","schema","neither","it","but","file","prompt","either","use","writing","interface","repos","block","records","build","can","record",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":152,"publishedAt":47},"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",[147],{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[153,154,155,114,111,156,157,28,158,159,160,97,161,162,101,163,164,107,108,165,166,167],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":175,"publishedAt":47},"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",[174],{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},[176,177,178,179,180,181,182,183,97,184,101,185,186,187,107,166,111,188,189,114],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]