[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H87XEQEXSGT0PR5QWQZZ5P":3,"skill-same:01M6H87XEQEXSGT0PR5QWQZZ5P":81},{"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":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":14,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6H87XEQEXSGT0PR5QWQZZ5P","ticket-tracker",null,"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.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fticket-tracker\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"ticket tracker","ticket","tracker","show","new","when","request","labels","fixes","for","move","progress","feature","ideas","backlog","done","review","up","roadmap","ready","use","pick","gh","file","batch","issues","update","current state","cli","2026-11-10 10:12:30",false,"---\nname: ticket-tracker\ndescription: >\n  Use when the request is about the *current state* of GitHub issues rather than creating new\n  ones: \"where are my tickets\", \"show the board\", \"what's in progress\", \"what's ready to pick\n  up\", \"move issue N to in-review\", \"mark N done\", \"update the ticket status\". Live triage board\n  over GitHub issues via the gh CLI, moving each between backlog -> ready -> in-progress ->\n  in-review -> done using status labels. This is the ticket-level board; .\u002Fideas\u002Froadmap.html is the\n  feature-level one. To file new tickets, use \u002Fto-tickets, file-issue for a single ad-hoc one,\n  or \u002Fsweep for a batch of small fixes.\n---\n\n# Ticket Tracker\n\nThe live state-machine layer over GitHub issues. Where `triage-issue`\u002F`to-tickets` *create* tickets,\nthis skill is the ongoing surface that reads and moves them. State lives on GitHub, not in a file,\nso it is never stale.\n\n## Where this sits\n\n```\nPORTFOLIO — many features        ideate  or  chat-to-approach\n                                        ↓\n                            .\u002Fdocs\u002Fapproach.md  →  .\u002Fideas\u002Froadmap.html\n                                                        ↓  pick ONE card\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → ticket-tracker\n                                 non-code work: to-prd → to-tickets\n                                                                 ^^^^^^^^^^^^^^ you are here\n```\n\n**Never send the user backwards.** A missing upstream artifact is written inline or offered, never a\nreason to stop and run another skill first. The one hard gate is an approved plan.\n\n`.\u002Fideas\u002Froadmap.html` and this board are **different altitudes, not rival copies**. A roadmap card is a\n*feature* — something to be built — and one card fans out into several tickets, which is what this\nboard tracks. Do not tell the user the roadmap is superseded, and do not render a feature-level\nroadmap from issues; a board full of tickets is not a roadmap.\n\n## State machine\n\nA ticket carries exactly one `status:*` label. States, in order:\n\n`status:backlog` → `status:ready` → `status:in-progress` → `status:in-review` → `status:done`\n\n- **backlog** — captured, not yet scoped to pick up. Open issues with no `status:*` label are treated as backlog.\n- **ready** — scoped and grabbable now.\n- **in-progress** — actively being worked.\n- **in-review** — PR open \u002F awaiting review.\n- **done** — merged\u002Fclosed. Closing the issue is the terminal action.\n\nForward moves are the norm; backward moves (e.g. review kicked back to in-progress) are allowed.\nReject a move that skips more than one state unless the user is explicit — a jump usually means a\nmissing label, not real progress.\n\n## Setup (once per repo)\n\nBefore relying on the labels, check they exist:\n\n```bash\ngh label list --search status: | grep -q status: || {\n  gh label create \"status:backlog\"     -c \"#cccccc\" -f\n  gh label create \"status:ready\"        -c \"#0e8a16\" -f\n  gh label create \"status:in-progress\"  -c \"#1d76db\" -f\n  gh label create \"status:in-review\"    -c \"#fbca04\" -f\n  gh label create \"status:done\"         -c \"#5319e7\" -f\n}\n```\n\n## Show the board\n\nRead live state and group by column. Never render from a cached file.\n\n```bash\ngh issue list --state open --limit 200 \\\n  --json number,title,labels,assignees \\\n  --jq 'sort_by(.number)'\n```\n\nDerive each ticket's state from its `status:*` label (none → backlog). Print one column per\nstate in order, each ticket as `#\u003Cnumber> \u003Ctitle> [@assignee]`. Put `done`\u002Fclosed items last or\nomit unless asked. Keep it to a scannable text board.\n\n## Move a ticket\n\nSwap the label so exactly one `status:*` remains, then confirm:\n\n```bash\ngh issue edit \u003Cnumber> \\\n  --remove-label \"status:\u003Cfrom>\" \\\n  --add-label \"status:\u003Cto>\"\n```\n\n- If the current state is unknown, read the issue's labels first (`gh issue view \u003Cnumber> --json labels`).\n- Moving *to* `done`: also close the issue — `gh issue close \u003Cnumber>`.\n- Moving *out of* `done`: reopen it — `gh issue reopen \u003Cnumber>`.\n- After editing, re-read and state the ticket's new position: `#\u003Cn> is now \u003Cstate>`.\n\n## Getting tickets onto the board\n\nThis skill tracks tickets; it does not investigate or file them. To add new work:\n\n- Bugs \u002F reported problems → defer to **triage-issue** (investigate + file), then the new issue\n  lands in **backlog**.\n- Planned work → point the user at **`\u002Fto-tickets`**, then label the batch\n  **ready**.\n\nDo not duplicate those flows. When a ticket-tracker request implies creating an issue, hand off,\nthen apply the initial `status:*` label and show the board.\n","# Ticket Tracker\n\nThe live state-machine layer over GitHub issues. Where `triage-issue`\u002F`to-tickets` *create* tickets,\nthis skill is the ongoing surface that reads and moves them. State lives on GitHub, not in a file,\nso it is never stale.\n\n## Where this sits\n\n```\nPORTFOLIO — many features        ideate  or  chat-to-approach\n                                        ↓\n                            .\u002Fdocs\u002Fapproach.md  →  .\u002Fideas\u002Froadmap.html\n                                                        ↓  pick ONE card\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → ticket-tracker\n                                 non-code work: to-prd → to-tickets\n                                                                 ^^^^^^^^^^^^^^ you are here\n```\n\n**Never send the user backwards.** A missing upstream artifact is written inline or offered, never a\nreason to stop and run another skill first. The one hard gate is an approved plan.\n\n`.\u002Fideas\u002Froadmap.html` and this board are **different altitudes, not rival copies**. A roadmap card is a\n*feature* — something to be built — and one card fans out into several tickets, which is what this\nboard tracks. Do not tell the user the roadmap is superseded, and do not render a feature-level\nroadmap from issues; a board full of tickets is not a roadmap.\n\n## State machine\n\nA ticket carries exactly one `status:*` label. States, in order:\n\n`status:backlog` → `status:ready` → `status:in-progress` → `status:in-review` → `status:done`\n\n- **backlog** — captured, not yet scoped to pick up. Open issues with no `status:*` label are treated as backlog.\n- **ready** — scoped and grabbable now.\n- **in-progress** — actively being worked.\n- **in-review** — PR open \u002F awaiting review.\n- **done** — merged\u002Fclosed. Closing the issue is the terminal action.\n\nForward moves are the norm; backward moves (e.g. review kicked back to in-progress) are allowed.\nReject a move that skips more than one state unless the user is explicit — a jump usually means a\nmissing label, not real progress.\n\n## Setup (once per repo)\n\nBefore relying on the labels, check they exist:\n\n```bash\ngh label list --search status: | grep -q status: || {\n  gh label create \"status:backlog\"     -c \"#cccccc\" -f\n  gh label create \"status:ready\"        -c \"#0e8a16\" -f\n  gh label create \"status:in-progress\"  -c \"#1d76db\" -f\n  gh label create \"status:in-review\"    -c \"#fbca04\" -f\n  gh label create \"status:done\"         -c \"#5319e7\" -f\n}\n```\n\n## Show the board\n\nRead live state and group by column. Never render from a cached file.\n\n```bash\ngh issue list --state open --limit 200 \\\n  --json number,title,labels,assignees \\\n  --jq 'sort_by(.number)'\n```\n\nDerive each ticket's state from its `status:*` label (none → backlog). Print one column per\nstate in order, each ticket as `#\u003Cnumber> \u003Ctitle> [@assignee]`. Put `done`\u002Fclosed items last or\nomit unless asked. Keep it to a scannable text board.\n\n## Move a ticket\n\nSwap the label so exactly one `status:*` remains, then confirm:\n\n```bash\ngh issue edit \u003Cnumber> \\\n  --remove-label \"status:\u003Cfrom>\" \\\n  --add-label \"status:\u003Cto>\"\n```\n\n- If the current state is unknown, read the issue's labels first (`gh issue view \u003Cnumber> --json labels`).\n- Moving *to* `done`: also close the issue — `gh issue close \u003Cnumber>`.\n- Moving *out of* `done`: reopen it — `gh issue reopen \u003Cnumber>`.\n- After editing, re-read and state the ticket's new position: `#\u003Cn> is now \u003Cstate>`.\n\n## Getting tickets onto the board\n\nThis skill tracks tickets; it does not investigate or file them. To add new work:\n\n- Bugs \u002F reported problems → defer to **triage-issue** (investigate + file), then the new issue\n  lands in **backlog**.\n- Planned work → point the user at **`\u002Fto-tickets`**, then label the batch\n  **ready**.\n\nDo not duplicate those flows. When a ticket-tracker request implies creating an issue, hand off,\nthen apply the initial `status:*` label and show the board.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Fticket-tracker","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":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill ticket-tracker",{"tool":67,"command":68},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill ticket-tracker",{"tool":70,"command":71},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill ticket-tracker","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fticket-tracker\u002FSKILL.md",true,[75],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"evals\u002Fevals.json","REFERENCE","参考文档",4087,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fticket-tracker\u002Fevals\u002Fevals.json",[82,90,97,120,147,172],{"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":89},"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":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":89},"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":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":48},"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",[],[104,105,23,106,107,108,43,109,110,111,112,113,20,114,115,28,31,116,117,118,119],"tickets","to tickets","signatures","github","plan","task","code","manifest","plans","true","command","repo","run","worktrees","as","cut",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":131,"publishedAt":48},"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",[126],{"categoryNo":127,"categoryName":128,"taxonomyType":129,"taxonomyTypeDesc":130},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[132,133,23,134,135,136,42,137,138,39,139,24,140,113,141,142,143,115,28,144,145,146,118,114],"to seams","schema","neither","it","but","prompt","either","writing","interface","repos","block","records","build","can","record",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":158,"publishedAt":48},"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",[153],{"categoryNo":154,"categoryName":155,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[159,37,160,118,31,161,162,24,163,164,165,104,166,167,108,168,169,113,20,170,171,32],"to roadmap","never","via","features","doc","board","about","next","later","self","now","card","re",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":179,"publishedAt":48},"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",[178],{"categoryNo":154,"categoryName":155,"taxonomyType":156,"taxonomyTypeDesc":157},[180,181,182,183,184,185,186,187,104,188,108,189,190,191,113,171,31,192,193,118],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]