[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H80P01T757RXRDWTYKE8FH":3,"skill-same:01M6H80P01T757RXRDWTYKE8FH":84},{"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":28,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":14,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6H80P01T757RXRDWTYKE8FH","code-review",null,"Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\". Reviews changes since a fixed point (commit, branch, tag, or merge-base) along two parallel axes — Standards (does this follow the repo's documented coding standards?) and Contract (does this match the ticket and the feature's frozen contract?) — reported side by side. Also defines the Journey axis, which \u002Ffleet reconcile applies to a completed slice. For whole-system design assessment rather than a diff, use architecture-review.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fcode-review\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"review","code","code review","system design","point","slice","for","which","reviews","ticket","feature","contract","journey","standards","diff","repo","branch","parallel","system","assessment","pr","design","2026-11-10 10:12:30",false,"---\nname: code-review\ndescription: >\n  Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to\n  \"review since X\". Reviews changes since a fixed point (commit, branch, tag, or merge-base)\n  along two parallel axes — Standards (does this follow the repo's documented coding standards?)\n  and Contract (does this match the ticket and the feature's frozen contract?) — reported side by side.\n  Also defines the Journey axis, which \u002Ffleet reconcile applies to a completed slice. For\n  whole-system design assessment rather than a diff, use architecture-review.\n---\n\nReview of the change against a fixed point the user supplies, along two axes (a third, Journey, checks a delivery slice rather than a diff; see _Journey axis_):\n\n- **Standards** — does the code conform to this repo's documented coding standards?\n- **Contract** — does the code meet the ticket's acceptance criteria, implement every signature the ticket lists, and keep those signatures as written?\n\nBoth diff axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.\n\n## Process\n\n### 1. Pin the fixed point\n\nWhatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`, etc. If they didn't specify one, ask for it.\n\nFor committed work capture `git diff \u003Cfixed-point>...HEAD` (three-dot, against the merge-base).\nFor work still in progress capture `git diff \u003Cfixed-point>` (tracked staged and unstaged changes)\nand read any untracked files in scope explicitly. Note the commits via\n`git log \u003Cfixed-point>..HEAD --oneline`. Keep the worktree path in both reviewer briefs.\n\nBefore going further, confirm the fixed point resolves (`git rev-parse \u003Cfixed-point>`) and the\neffective change is non-empty, including untracked files. A bad ref or empty change should fail\nhere — not inside two parallel sub-agents. A review run for \u002Fimplement is **low** on `size:xs`\nand **medium** otherwise; both require independent reviewers. Low uses the same two axes but\nfocuses on the small fix and its regression test rather than adjacent design advice.\n\n### 2. Identify the contract and spec source\n\nLook for the originating ticket and contract, in this order:\n\n1. Issue references in the commit messages or branch name (`#123`, `Closes #45`) — resolve with `gh issue view`.\n2. A path the user passed as an argument.\n3. A spec file under `docs\u002F`, `specs\u002F`, or `.scratch\u002F` matching the branch name or feature.\n4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Contract** sub-agent will skip and report \"no spec available\".\n\nThen look for the contract: the ticket body's `## Signatures` section, which `to-tickets` copies from the plan (`new:` signatures and `change:` bullets). The ticket carries it because `docs\u002Fplans\u002F` is usually gitignored, so a fresh checkout lacks the plan. If the ticket has no `## Signatures` section (ad hoc work, sweep, non-code), there is no contract and the Contract axis falls back to plain spec review: acceptance criteria only, as below.\n\n### 3. Identify the standards sources\n\nAnything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.\n\nOn top of whatever the repo documents, the Standards axis always carries the **smell baseline** below — a fixed set of Fowler code smells (_Refactoring_, ch.3) that applies even when a repo documents nothing. Two rules bind it:\n\n- **The repo overrides.** A documented repo standard always wins; where it endorses something the baseline would flag, suppress the smell.\n- **Always a judgement call.** Each smell is a labelled heuristic (\"possible Feature Envy\"), never a hard violation — and, like any standard here, skip anything tooling already enforces.\n\nEach smell reads *what it is* → *how to fix*; match it against the diff:\n\n- **Mysterious Name** — a function, variable, or type whose name doesn't reveal what it does or holds. → rename it; if no honest name comes, the design's murky.\n- **Duplicated Code** — the same logic shape appears in more than one hunk or file in the change. → extract the shared shape, call it from both.\n- **Feature Envy** — a method that reaches into another object's data more than its own. → move the method onto the data it envies.\n- **Data Clumps** — the same few fields or params keep travelling together (a type wanting to be born). → bundle them into one type, pass that.\n- **Primitive Obsession** — a primitive or string standing in for a domain concept that deserves its own type. → give the concept its own small type.\n- **Repeated Switches** — the same `switch`\u002F`if`-cascade on the same type recurs across the change. → replace with polymorphism, or one map both sites share.\n- **Shotgun Surgery** — one logical change forces scattered edits across many files in the diff. → gather what changes together into one module.\n- **Divergent Change** — one file or module is edited for several unrelated reasons. → split so each module changes for one reason.\n- **Speculative Generality** — abstraction, parameters, or hooks added for needs the spec doesn't have. → delete it; inline back until a real need shows.\n- **Message Chains** — long `a.b().c().d()` navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.\n- **Middle Man** — a class or function that mostly just delegates onward. → cut it, call the real target direct.\n- **Refused Bequest** — a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.\n\n### 4. Spawn both sub-agents in parallel\n\n**Standards sub-agent prompt** — include:\n\n- The full diff command, any untracked-file paths, and commit list.\n- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full — the sub-agent has no other access to it.\n- The brief: \"Report — per file\u002Fhunk where relevant — (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls — documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words.\"\n\n**Contract sub-agent prompt** — include:\n\n- The diff command, any untracked-file paths, and commit list.\n- The path or fetched contents of the ticket (or other spec), including its `## Signatures` section when one exists.\n- The brief: \"Report: (a) acceptance criteria or requirements that are missing, partial, or look implemented but wrong; (b) behaviour in the diff that wasn't asked for (scope creep). Quote the ticket line for each finding. With a contract also report: (c) every `new:` signature or `change:` bullet in the ticket's `## Signatures` that the diff does not implement; (d) signature diff: compare each declaration the diff adds for a `new:` signature (name, parameters, return types, visibility) against the ticket's block, and flag every mismatch that is not tied to a `contract-change` issue (match `gh issue list --label contract-change --state all` against the issue numbers in the commits and PR body, or an issue naming the changed symbol). A signature edit with no such issue is a violation, not a judgement call. Under 400 words.\"\n\nIf neither a ticket nor a spec is available, skip the Contract sub-agent and note this in the final report.\nIf a required reviewer cannot be launched or its report cannot be read, report the review as\nblocked; never replace that axis with the implementer's own judgement or claim it passed.\n\n### 5. Aggregate\n\nPresent the reports under `## Standards` and `## Contract` headings (Contract covers acceptance criteria, signature coverage and the signature diff; without a contract, acceptance criteria only), verbatim or lightly cleaned. Do **not** merge or rerank findings — the axes are deliberately separate (see _Why separate axes_).\n\nEnd with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes — that's the reranking the separation exists to prevent.\n\n## Journey axis\n\nA third axis, separate from Standards and Contract. It does not review a diff: it runs once per\ndelivery slice, on integrated code, when `\u002Ffleet reconcile` finds the slice's last ticket merged.\nRun it as its own sub-agent, never inside the two above, so a passing diff cannot mask a broken journey.\n\nInput is one PRD journey (title, surface, steps, final `→ \u003Cobservable state>`) and the evidence\ngathered for it: the output of running its steps. Missing or empty evidence counts as needs human\neyes, never pass. Report, per journey:\n\n- **Pass**: the evidence shows the `→` end state. Quote the evidence line that shows it.\n- **Fail**: the evidence contradicts the end state or stops before it. Quote the step where it diverged.\n- **Needs human eyes**: the end state is visual UI, or the evidence cannot show it. List what the user\n  should look at. Never guess pass or fail from output that cannot show the state.\n\n## Why separate axes\n\nA change can pass one axis and fail another:\n\n- Code that follows every standard but implements the wrong thing → **Standards pass, Contract fail.**\n- Code that does exactly what the issue asked but breaks the project's conventions → **Contract pass, Standards fail.**\n\nReporting them separately stops one axis from masking another.\n","Review of the change against a fixed point the user supplies, along two axes (a third, Journey, checks a delivery slice rather than a diff; see _Journey axis_):\n\n- **Standards** — does the code conform to this repo's documented coding standards?\n- **Contract** — does the code meet the ticket's acceptance criteria, implement every signature the ticket lists, and keep those signatures as written?\n\nBoth diff axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.\n\n## Process\n\n### 1. Pin the fixed point\n\nWhatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`, etc. If they didn't specify one, ask for it.\n\nFor committed work capture `git diff \u003Cfixed-point>...HEAD` (three-dot, against the merge-base).\nFor work still in progress capture `git diff \u003Cfixed-point>` (tracked staged and unstaged changes)\nand read any untracked files in scope explicitly. Note the commits via\n`git log \u003Cfixed-point>..HEAD --oneline`. Keep the worktree path in both reviewer briefs.\n\nBefore going further, confirm the fixed point resolves (`git rev-parse \u003Cfixed-point>`) and the\neffective change is non-empty, including untracked files. A bad ref or empty change should fail\nhere — not inside two parallel sub-agents. A review run for \u002Fimplement is **low** on `size:xs`\nand **medium** otherwise; both require independent reviewers. Low uses the same two axes but\nfocuses on the small fix and its regression test rather than adjacent design advice.\n\n### 2. Identify the contract and spec source\n\nLook for the originating ticket and contract, in this order:\n\n1. Issue references in the commit messages or branch name (`#123`, `Closes #45`) — resolve with `gh issue view`.\n2. A path the user passed as an argument.\n3. A spec file under `docs\u002F`, `specs\u002F`, or `.scratch\u002F` matching the branch name or feature.\n4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Contract** sub-agent will skip and report \"no spec available\".\n\nThen look for the contract: the ticket body's `## Signatures` section, which `to-tickets` copies from the plan (`new:` signatures and `change:` bullets). The ticket carries it because `docs\u002Fplans\u002F` is usually gitignored, so a fresh checkout lacks the plan. If the ticket has no `## Signatures` section (ad hoc work, sweep, non-code), there is no contract and the Contract axis falls back to plain spec review: acceptance criteria only, as below.\n\n### 3. Identify the standards sources\n\nAnything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.\n\nOn top of whatever the repo documents, the Standards axis always carries the **smell baseline** below — a fixed set of Fowler code smells (_Refactoring_, ch.3) that applies even when a repo documents nothing. Two rules bind it:\n\n- **The repo overrides.** A documented repo standard always wins; where it endorses something the baseline would flag, suppress the smell.\n- **Always a judgement call.** Each smell is a labelled heuristic (\"possible Feature Envy\"), never a hard violation — and, like any standard here, skip anything tooling already enforces.\n\nEach smell reads *what it is* → *how to fix*; match it against the diff:\n\n- **Mysterious Name** — a function, variable, or type whose name doesn't reveal what it does or holds. → rename it; if no honest name comes, the design's murky.\n- **Duplicated Code** — the same logic shape appears in more than one hunk or file in the change. → extract the shared shape, call it from both.\n- **Feature Envy** — a method that reaches into another object's data more than its own. → move the method onto the data it envies.\n- **Data Clumps** — the same few fields or params keep travelling together (a type wanting to be born). → bundle them into one type, pass that.\n- **Primitive Obsession** — a primitive or string standing in for a domain concept that deserves its own type. → give the concept its own small type.\n- **Repeated Switches** — the same `switch`\u002F`if`-cascade on the same type recurs across the change. → replace with polymorphism, or one map both sites share.\n- **Shotgun Surgery** — one logical change forces scattered edits across many files in the diff. → gather what changes together into one module.\n- **Divergent Change** — one file or module is edited for several unrelated reasons. → split so each module changes for one reason.\n- **Speculative Generality** — abstraction, parameters, or hooks added for needs the spec doesn't have. → delete it; inline back until a real need shows.\n- **Message Chains** — long `a.b().c().d()` navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.\n- **Middle Man** — a class or function that mostly just delegates onward. → cut it, call the real target direct.\n- **Refused Bequest** — a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.\n\n### 4. Spawn both sub-agents in parallel\n\n**Standards sub-agent prompt** — include:\n\n- The full diff command, any untracked-file paths, and commit list.\n- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full — the sub-agent has no other access to it.\n- The brief: \"Report — per file\u002Fhunk where relevant — (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls — documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words.\"\n\n**Contract sub-agent prompt** — include:\n\n- The diff command, any untracked-file paths, and commit list.\n- The path or fetched contents of the ticket (or other spec), including its `## Signatures` section when one exists.\n- The brief: \"Report: (a) acceptance criteria or requirements that are missing, partial, or look implemented but wrong; (b) behaviour in the diff that wasn't asked for (scope creep). Quote the ticket line for each finding. With a contract also report: (c) every `new:` signature or `change:` bullet in the ticket's `## Signatures` that the diff does not implement; (d) signature diff: compare each declaration the diff adds for a `new:` signature (name, parameters, return types, visibility) against the ticket's block, and flag every mismatch that is not tied to a `contract-change` issue (match `gh issue list --label contract-change --state all` against the issue numbers in the commits and PR body, or an issue naming the changed symbol). A signature edit with no such issue is a violation, not a judgement call. Under 400 words.\"\n\nIf neither a ticket nor a spec is available, skip the Contract sub-agent and note this in the final report.\nIf a required reviewer cannot be launched or its report cannot be read, report the review as\nblocked; never replace that axis with the implementer's own judgement or claim it passed.\n\n### 5. Aggregate\n\nPresent the reports under `## Standards` and `## Contract` headings (Contract covers acceptance criteria, signature coverage and the signature diff; without a contract, acceptance criteria only), verbatim or lightly cleaned. Do **not** merge or rerank findings — the axes are deliberately separate (see _Why separate axes_).\n\nEnd with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes — that's the reranking the separation exists to prevent.\n\n## Journey axis\n\nA third axis, separate from Standards and Contract. It does not review a diff: it runs once per\ndelivery slice, on integrated code, when `\u002Ffleet reconcile` finds the slice's last ticket merged.\nRun it as its own sub-agent, never inside the two above, so a passing diff cannot mask a broken journey.\n\nInput is one PRD journey (title, surface, steps, final `→ \u003Cobservable state>`) and the evidence\ngathered for it: the output of running its steps. Missing or empty evidence counts as needs human\neyes, never pass. Report, per journey:\n\n- **Pass**: the evidence shows the `→` end state. Quote the evidence line that shows it.\n- **Fail**: the evidence contradicts the end state or stops before it. Quote the step where it diverged.\n- **Needs human eyes**: the end state is visual UI, or the evidence cannot show it. List what the user\n  should look at. Never guess pass or fail from output that cannot show the state.\n\n## Why separate axes\n\nA change can pass one axis and fail another:\n\n- Code that follows every standard but implements the wrong thing → **Standards pass, Contract fail.**\n- Code that does exactly what the issue asked but breaks the project's conventions → **Contract pass, Standards fail.**\n\nReporting them separately stops one axis from masking another.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fcode\u002Fcode-review","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":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill code-review",{"tool":70,"command":71},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill code-review",{"tool":73,"command":74},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill code-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fcode-review\u002FSKILL.md",true,[78],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"agents\u002Fopenai.yaml","REFERENCE","参考文档",104,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Fcode-review\u002Fagents\u002Fopenai.yaml",[85,93,100,123,151,176],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":92},"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":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":92},"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":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":51},"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",[],[107,108,109,110,111,112,113,114,30,115,116,117,38,118,44,35,39,119,120,121,122],"tickets","to tickets","new","signatures","github","plan","batch","task","manifest","plans","true","command","run","worktrees","as","cut",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":132,"publishedAt":51},"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",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[133,134,109,135,136,137,138,139,140,141,142,143,144,117,145,146,147,44,35,148,149,150,121,118],"to seams","schema","neither","it","but","file","prompt","either","use","writing","when","interface","repos","block","records","build","can","record",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":160,"publishedAt":51},"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",[157],{"categoryNo":158,"categoryName":159,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理",[161,162,163,121,39,164,165,143,166,167,168,107,169,170,112,171,172,117,38,173,174,175],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":183,"publishedAt":51},"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",[182],{"categoryNo":158,"categoryName":159,"taxonomyType":26,"taxonomyTypeDesc":27},[184,185,186,187,188,189,190,191,107,192,112,193,194,195,117,174,39,196,36,121],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem"]