[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H85YPBP9WFARCNHN316K1Y":3,"skill-same:01M6H85YPBP9WFARCNHN316K1Y":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":14,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6H85YPBP9WFARCNHN316K1Y","handoff",null,"Compact the current conversation into a handoff document that another agent picks up in a fresh context window — including an agent targeting a different repo. Use when the user says \"hand off\", \"write a handoff\", \"pass this to another agent\", \"continue in another repo\", or wants to preserve context before switching sessions\u002Frepos.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fhandoff\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"document","context window","when","window","preserve","hand","targeting","fresh","switching","compact","conversation","up","use","user","context","write","repo","continue","repos","sessions","2026-11-10 10:12:30",false,"---\nname: handoff\ndescription: Compact the current conversation into a handoff document that another agent picks up in a fresh context window — including an agent targeting a different repo. Use when the user says \"hand off\", \"write a handoff\", \"pass this to another agent\", \"continue in another repo\", or wants to preserve context before switching sessions\u002Frepos.\n---\n\n# Handoff\n\nCompact the current conversation into a self-contained handoff document so a *fresh* agent — with none of this conversation's context — can pick up exactly where you left off. Work often crosses repos (backend work in one repo, then a separate agent for the frontend), and the receiving agent must be able to find the handoff without being told where to look.\n\n## Where the handoff lives (READ THIS FIRST)\n\nThe single most important thing about this skill: **the handoff must be trivially findable by an agent in a brand-new context window.** Do not save it to a temp dir — it would be invisible to the next agent.\n\n**Always write to `.claude\u002Fhandoffs\u002F` at the current git repo's root**, and tell the user the exact absolute path.\n\n- Create the directory if it does not exist: `mkdir -p \u003Crepo-root>\u002F.claude\u002Fhandoffs`\n- **Filename convention:** `\u003Cfrom-repo>__to__\u003Cto-repo>__\u003Cshort-slug>.md`\n  - e.g. `services__to__web__teammate-invite-api.md`\n  - If the handoff is not repo-to-repo (same repo, just a new session), use `\u003Crepo>__\u003Cshort-slug>.md`.\n- Also maintain a pointer to the most recent handoff at `\u003Crepo-root>\u002F.claude\u002Fhandoffs\u002FLATEST.md` — overwrite it each time with a one-line link to the newest handoff file plus its one-line summary. A new agent that knows nothing can always start by reading `LATEST.md`.\n\nFor a cross-repo handoff, the receiving agent works in a different checkout, so give it the absolute path to the file.\n\n### Tell the user how to resume\n\nAfter writing the file, end your response with the **exact** copy-pasteable instruction for the next agent, e.g.:\n\n> Start the next agent in `web\u002F` and paste:\n> `Read \u002Fabs\u002Fpath\u002Fto\u002Fservices\u002F.claude\u002Fhandoffs\u002Fservices__to__web__teammate-invite-api.md and continue from there.`\n\n## For the receiving agent (how to find a handoff)\n\nIf you were told to continue from a handoff, or you suspect one exists:\n\n1. Read `\u003Crepo-root>\u002F.claude\u002Fhandoffs\u002FLATEST.md` for the newest handoff.\n2. Or `ls \u003Crepo-root>\u002F.claude\u002Fhandoffs\u002F` and pick the file whose `__to__\u003Cyour-repo>__` segment matches the repo you're working in.\n\n## What to include\n\nKeep it tight — this is a compaction, not a transcript. Prefer links over copies.\n\n1. **Goal** — one or two sentences: what we're ultimately trying to achieve.\n2. **Target repo & where to work** — which repo the next agent should `cd` into, the branch\u002Fworktree to use, and how to run\u002Fbuild\u002Ftest it there. Be explicit; the next agent may never have opened that repo.\n3. **State so far** — what's done, what's in progress, what's verified vs. assumed. Note the current branch and whether there are uncommitted changes.\n4. **Cross-repo contract** — for backend→frontend (or any cross-repo) handoffs, spell out the *interface* between the repos: API endpoints\u002Fshapes, types, event names, feature flags, env vars, generated clients, or schema the next agent depends on. This is the context most expensive to rediscover — make it precise.\n5. **Next steps** — an ordered, concrete task list for the receiving agent.\n6. **Gotchas \u002F decisions** — non-obvious constraints, dead ends already tried, and decisions made (with the *why*).\n7. **Suggested skills** — name the skills the next agent should use (e.g. `tdd`, `code-review`, `triage-issue`), so it doesn't reinvent workflow.\n\n## Reference, don't duplicate\n\nDo **not** paste large artifacts into the handoff. Link to them by path or URL instead:\n\n- specs, plans, PRDs, ADRs → repo path\n- issues \u002F PRs → GitHub URL or number\n- commits \u002F diffs → SHA (and `git show \u003Csha>` hint)\n- prior handoffs → path under `.claude\u002Fhandoffs\u002F`\n\nUse clickable `file_path:line_number` references so the next agent can jump straight to the code.\n\n## Security\n\nBefore writing the file, **redact** all secrets and PII: API keys, tokens, passwords, connection strings, customer data, personal emails\u002Fnames. Replace with `\u003CREDACTED: description>`. The handoff lives on disk — treat it as if it could be read by anyone with repo access.\n\n## Tailoring\n\nIf the user passed arguments describing the next session's focus (e.g. \"handing off the frontend work\" or \"only the migration\"), scope the handoff to that focus: lead with the relevant next steps and trim state that doesn't serve it.\n\n## Template\n\n```markdown\n# Handoff: \u003Cshort title>\n\n**From:** \u003Crepo> (\u003Cbranch>)  →  **To:** \u003Crepo> (\u003Cbranch\u002Fworktree>)\n**Date:** \u003CYYYY-MM-DD>  ·  **One-line summary:** \u003Cwhat the next agent is picking up>\n\n## Goal\n\u003C1–2 sentences>\n\n## Where to work\n- Repo: `\u003Cabsolute path to repo>`\n- Branch\u002Fworktree: `\u003Cbranch>`\n- Run \u002F test: `\u003Ccommands>`\n\n## State so far\n- Done: …\n- In progress: …\n- Verified vs assumed: …\n- Uncommitted changes: \u003Cyes\u002Fno — what>\n\n## Cross-repo contract  (backend ↔ frontend)\n- Endpoints \u002F types \u002F events \u002F flags \u002F env the other side depends on\n- Links: \u003Cpaths, URLs, SHAs>\n\n## Next steps\n1. …\n2. …\n\n## Gotchas & decisions\n- …\n\n## Suggested skills\n- `\u003Cskill>` — why\n```\n","# Handoff\n\nCompact the current conversation into a self-contained handoff document so a *fresh* agent — with none of this conversation's context — can pick up exactly where you left off. Work often crosses repos (backend work in one repo, then a separate agent for the frontend), and the receiving agent must be able to find the handoff without being told where to look.\n\n## Where the handoff lives (READ THIS FIRST)\n\nThe single most important thing about this skill: **the handoff must be trivially findable by an agent in a brand-new context window.** Do not save it to a temp dir — it would be invisible to the next agent.\n\n**Always write to `.claude\u002Fhandoffs\u002F` at the current git repo's root**, and tell the user the exact absolute path.\n\n- Create the directory if it does not exist: `mkdir -p \u003Crepo-root>\u002F.claude\u002Fhandoffs`\n- **Filename convention:** `\u003Cfrom-repo>__to__\u003Cto-repo>__\u003Cshort-slug>.md`\n  - e.g. `services__to__web__teammate-invite-api.md`\n  - If the handoff is not repo-to-repo (same repo, just a new session), use `\u003Crepo>__\u003Cshort-slug>.md`.\n- Also maintain a pointer to the most recent handoff at `\u003Crepo-root>\u002F.claude\u002Fhandoffs\u002FLATEST.md` — overwrite it each time with a one-line link to the newest handoff file plus its one-line summary. A new agent that knows nothing can always start by reading `LATEST.md`.\n\nFor a cross-repo handoff, the receiving agent works in a different checkout, so give it the absolute path to the file.\n\n### Tell the user how to resume\n\nAfter writing the file, end your response with the **exact** copy-pasteable instruction for the next agent, e.g.:\n\n> Start the next agent in `web\u002F` and paste:\n> `Read \u002Fabs\u002Fpath\u002Fto\u002Fservices\u002F.claude\u002Fhandoffs\u002Fservices__to__web__teammate-invite-api.md and continue from there.`\n\n## For the receiving agent (how to find a handoff)\n\nIf you were told to continue from a handoff, or you suspect one exists:\n\n1. Read `\u003Crepo-root>\u002F.claude\u002Fhandoffs\u002FLATEST.md` for the newest handoff.\n2. Or `ls \u003Crepo-root>\u002F.claude\u002Fhandoffs\u002F` and pick the file whose `__to__\u003Cyour-repo>__` segment matches the repo you're working in.\n\n## What to include\n\nKeep it tight — this is a compaction, not a transcript. Prefer links over copies.\n\n1. **Goal** — one or two sentences: what we're ultimately trying to achieve.\n2. **Target repo & where to work** — which repo the next agent should `cd` into, the branch\u002Fworktree to use, and how to run\u002Fbuild\u002Ftest it there. Be explicit; the next agent may never have opened that repo.\n3. **State so far** — what's done, what's in progress, what's verified vs. assumed. Note the current branch and whether there are uncommitted changes.\n4. **Cross-repo contract** — for backend→frontend (or any cross-repo) handoffs, spell out the *interface* between the repos: API endpoints\u002Fshapes, types, event names, feature flags, env vars, generated clients, or schema the next agent depends on. This is the context most expensive to rediscover — make it precise.\n5. **Next steps** — an ordered, concrete task list for the receiving agent.\n6. **Gotchas \u002F decisions** — non-obvious constraints, dead ends already tried, and decisions made (with the *why*).\n7. **Suggested skills** — name the skills the next agent should use (e.g. `tdd`, `code-review`, `triage-issue`), so it doesn't reinvent workflow.\n\n## Reference, don't duplicate\n\nDo **not** paste large artifacts into the handoff. Link to them by path or URL instead:\n\n- specs, plans, PRDs, ADRs → repo path\n- issues \u002F PRs → GitHub URL or number\n- commits \u002F diffs → SHA (and `git show \u003Csha>` hint)\n- prior handoffs → path under `.claude\u002Fhandoffs\u002F`\n\nUse clickable `file_path:line_number` references so the next agent can jump straight to the code.\n\n## Security\n\nBefore writing the file, **redact** all secrets and PII: API keys, tokens, passwords, connection strings, customer data, personal emails\u002Fnames. Replace with `\u003CREDACTED: description>`. The handoff lives on disk — treat it as if it could be read by anyone with repo access.\n\n## Tailoring\n\nIf the user passed arguments describing the next session's focus (e.g. \"handing off the frontend work\" or \"only the migration\"), scope the handoff to that focus: lead with the relevant next steps and trim state that doesn't serve it.\n\n## Template\n\n```markdown\n# Handoff: \u003Cshort title>\n\n**From:** \u003Crepo> (\u003Cbranch>)  →  **To:** \u003Crepo> (\u003Cbranch\u002Fworktree>)\n**Date:** \u003CYYYY-MM-DD>  ·  **One-line summary:** \u003Cwhat the next agent is picking up>\n\n## Goal\n\u003C1–2 sentences>\n\n## Where to work\n- Repo: `\u003Cabsolute path to repo>`\n- Branch\u002Fworktree: `\u003Cbranch>`\n- Run \u002F test: `\u003Ccommands>`\n\n## State so far\n- Done: …\n- In progress: …\n- Verified vs assumed: …\n- Uncommitted changes: \u003Cyes\u002Fno — what>\n\n## Cross-repo contract  (backend ↔ frontend)\n- Endpoints \u002F types \u002F events \u002F flags \u002F env the other side depends on\n- Links: \u003Cpaths, URLs, SHAs>\n\n## Next steps\n1. …\n2. …\n\n## Gotchas & decisions\n- …\n\n## Suggested skills\n- `\u003Cskill>` — why\n```\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fproduct\u002Fhandoff","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":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill handoff",{"tool":58,"command":59},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill handoff",{"tool":61,"command":62},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill handoff","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproduct\u002Fhandoff\u002FSKILL.md",true,[],[67,75,82,109,136,163],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":74},"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":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":74},"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":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":39},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets","Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[],[89,90,91,92,93,94,95,96,97,98,99,100,101,102,35,103,104,105,106,107,108],"tickets","to tickets","new","signatures","github","plan","batch","task","code","manifest","plans","true","ticket","command","for","feature","run","worktrees","as","cut",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":120,"publishedAt":39},"01M6H88E98X9KGGYBGSVDS1E8H","to-seams","Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — \"record a seam for X\", \"we agreed on this schema, seam it\", \"add a seam so Y can build against Z's new field\". Halts for approval before writing either file.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-seams\u002FSKILL.md",[115],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[121,122,91,123,124,125,126,127,128,31,129,21,130,100,37,131,132,35,103,133,134,135,107,102],"to seams","schema","neither","it","but","file","prompt","either","writing","interface","block","records","build","can","record",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":147,"publishedAt":39},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap","Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[148,149,150,107,104,151,152,21,153,154,155,89,156,157,94,158,159,100,101,160,161,162],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":170,"publishedAt":39},"01M6H885QAK839Q771ZBKBK1KA","to-prd","Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[169],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},[171,172,173,174,175,176,177,178,89,179,94,180,181,182,100,161,104,183,184,107],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]