[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H80CMCP1NH58P6PMV4YT47":3,"skill-same:01M6H80CMCP1NH58P6PMV4YT47":98},{"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":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":14,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6H80CMCP1NH58P6PMV4YT47","architecture-review",null,"Use when the user wants an architecture review, a design health check, a staff-level read on architectural risk, or an assessment of coupling and cohesion: \"review my architecture\", \"is this codebase well-architected\", \"architecture health check\", \"where's the design risk\", \"design review before we scale\". Maps the system, detects the stack, fans out seven parallel reviewers (one per quality dimension — boundaries, coupling, data flow, failure modes, information hiding), and synthesises a verdict plus a prioritised roadmap. Diagnoses only — does not refactor. For a diff or PR, use code-review; to actually apply refactors, use improve-codebase-architecture.","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\u002Farchitecture-review\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,48],"review","architecture","architecture review","use","when","diff","only","roadmap","maps","cohesion","coupling","information","for","architecture health","Staff","data flow","design","read","parallel","system","stack","improve","risk","data","flow","code-review","code","assessment","pr","design review","2026-11-10 10:12:30",false,"---\nname: architecture-review\ndescription: >\n  Use when the user wants an architecture review, a design health check, a staff-level read on\n  architectural risk, or an assessment of coupling and cohesion: \"review my architecture\", \"is\n  this codebase well-architected\", \"architecture health check\", \"where's the design risk\",\n  \"design review before we scale\". Maps the system, detects the stack, fans out seven parallel\n  reviewers (one per quality dimension — boundaries, coupling, data flow, failure modes,\n  information hiding), and synthesises a verdict plus a prioritised roadmap. Diagnoses only —\n  does not refactor. For a diff or PR, use code-review; to actually apply refactors, use\n  improve-codebase-architecture.\n---\n\n# Architecture Review\n\nCritical architectural assessment. Judge system design — boundaries,\nresponsibilities, coupling, data flow, failure modes, evolvability, information hiding. Read-only; produces a written assessment and prioritised recommendations,\ndoes not edit source files.\n\n**Stance.** Adversarial, not a balanced scorecard. Hunt for what is wrong, weak, or risky.\nNever manufacture strengths for balance — praise is earned, and any dimension (or the whole\nsystem) may come back net-negative. Stay high-signal: surface the issues that matter and go\n*deep* on each (root cause, blast radius, evidence), not a long list of shallow nitpicks.\n\n**Agnostic vocabulary, stack-specific probes.** The vocabulary is technology-agnostic (a god\nobject is a god object in any language); formatting, naming, and idiom stay out of scope. But\nprobes adapt to the stack — a frontend's design-system\u002Ftheming, UI\u002FUX, and component-API\nconsistency are architectural, and a generic review misses them. See\n[`references\u002Fdomain-probes.md`](references\u002Fdomain-probes.md).\n\n## Capabilities\n\nA staff-engineer reviewer operating this skill:\n\n- Identifies the architectural style in use and evaluates whether it fits the system's actual constraints\n- Names patterns precisely — where they are applied correctly, misapplied, or conspicuously absent\n- Traces data flow and transaction\u002Fconsistency boundaries across service and module edges\n- Locates resilience and scalability ceilings (missing circuit breakers, unbounded queues, stateful services)\n- Maps trust boundaries and identity\u002Fsecret flow; flags where authentication, authorisation, or secret handling is absent or porous\n- Assesses module depth, coupling direction, cohesion, and information-hiding discipline\n- Surfaces genuine quality-attribute trade-offs rather than treating all dimensions as simultaneously maximisable\n- Grounds every finding in code evidence — and, where the repo provides it, in measured evidence (bundle reports, dependency graphs, coverage, profiles), not reasoning from reading alone\n- Is willing to deliver a net-negative verdict; reserves praise for what is genuinely well-built\n\nThe vocabulary for naming patterns precisely lives in\n[`references\u002Fknowledge-base.md`](references\u002Fknowledge-base.md).\nThe per-dimension rubric (what good looks like, checklists, anti-patterns) lives in\n[`references\u002Fdimensions.md`](references\u002Fdimensions.md).\n\n## Process\n\n### Phase 1 — Discover and map\n\nUse the Agent tool with `subagent_type=Explore` to build a **system map**:\n\n- Entry points and how the system is driven\n- Top-level modules \u002F services and their responsibilities\n- Major boundaries and seams\n- Data flow through a representative request or job\n- State, persistence, and ownership\n- External dependencies\n- Deployment \u002F runtime shape\n\nAlso **detect the stack** (frontend, backend, data\u002FML, infra, library, or a mix) and list\nthe build\u002Fanalysis tooling the repo provides (bundlers, dependency analysers, coverage\nrunners, profilers). The stack selects which stack-specific probes to inject (see\n[`references\u002Fdomain-probes.md`](references\u002Fdomain-probes.md)); the tooling tells reviewers\nwhat to measure rather than estimate.\n\nRecord navigational friction — if understanding one concept requires bouncing between\nmany files, note it. The system map is both this phase's output and the shared context\nfor all reviewer subagents. Do not grade yet.\n\n### Phase 2 — Fan out per-dimension reviewers\n\nSpawn **seven reviewer subagents in parallel** — one message, seven Agent calls,\n`subagent_type=Explore`. Each owns one lens:\n\n1. **Simplicity & understandability**\n2. **Maintainability**\n3. **Extensibility**\n4. **Security**\n5. **Performance & scalability**\n6. **Modularity** (deep modules + coupling & cohesion)\n7. **Deployability** (release coupling, CI\u002Fbuild-matrix coupling, operational blast radius)\n\nRead [`references\u002Fdimensions.md`](references\u002Fdimensions.md) and\n[`references\u002Fknowledge-base.md`](references\u002Fknowledge-base.md). For each reviewer, paste\n(a) their dimension's section from `dimensions.md`, (b) the knowledge-base domains\nlisted for their lens in the **Lens → domains mapping** table at the end of\n`knowledge-base.md`, and (c) any stack-specific probes for their lens from\n[`references\u002Fdomain-probes.md`](references\u002Fdomain-probes.md) matching the stack detected in\nPhase 1. Subagents do not share your context.\n\n**Measure, don't estimate.** `Explore` agents can run read-only shell commands. Where Phase\n1 found tooling, tell the reviewer to run it and cite the output (bundle report → Performance,\ndependency\u002Fcycle graph → Modularity, coverage → Maintainability). Flag any claim that is an\nestimate because no tooling existed.\n\n**Subagent prompt template** — fill the seven `{{...}}` slots per reviewer:\n\n```\nYou are a staff engineer performing a focused architecture review of the codebase at\n{{REPO_PATH}}. Your lens: {{DIMENSION NAME}}.\n\nAssess system design, not code style — boundaries, responsibilities, coupling, data flow,\nfailure modes, evolvability, information hiding. Formatting, naming, and idiom are out of\nscope unless they reveal a structural problem; stack-specific *architectural* concerns (e.g.\na frontend's design-system\u002Ftheming, UI\u002FUX, and component-API consistency) are in scope.\n\nSystem map (your ground truth — read the real code to confirm or challenge it):\n{{SYSTEM MAP}}\n\nRubric for your lens (definition, what good looks like, checklist, anti-patterns):\n{{PASTE THIS DIMENSION'S SECTION FROM references\u002Fdimensions.md}}\n\nArchitectural vocabulary relevant to your lens:\n{{PASTE THE KNOWLEDGE-BASE DOMAINS FOR THIS LENS FROM references\u002Fknowledge-base.md}}\n\nStack-specific probes for your lens (skip any that don't apply to this stack):\n{{PASTE THIS LENS'S PROBES FOR THE DETECTED STACK FROM references\u002Fdomain-probes.md, or \"none\"}}\n\nAvailable measurement tooling (run it and cite the output where it strengthens a finding):\n{{TOOLING FOUND IN PHASE 1 RELEVANT TO THIS LENS, or \"none found — reason from the code and say so\"}}\n\nName patterns from this vocabulary precisely where they apply, are misapplied, or are\nconspicuously absent. Do not force-fit — a pattern named where it does not belong is noise,\nnot insight.\n\nMethod: explore read-only (you may run read-only shell commands and the tooling above).\nGround every finding in file paths (with line ranges where useful) and measured output where\nyou have it.\n\nStance: be critical — find what is wrong, weak, or risky, do not reassure. Mention a strength\nonly if it is genuinely well-built and material. Stay high-signal: surface the issues that\nmatter and go deep on each (root cause, blast radius), not a pile of nitpicks.\n\nReturn narrative prose, no scores or severity tags. Structure:\n- A 2–3 sentence overall verdict — blunt, allowed to be net-negative. Note strengths only if real.\n- Findings, ranked most-serious first. Each: (a) what, (b) where — file-path\u002Fmeasured evidence,\n  (c) why it matters architecturally, (d) a direction for remediation (direction, not implementation).\nSay the dimension is healthy only if the evidence supports it — not as a default.\n```\n\n### Phase 3 — Synthesise\n\nCollect the seven reports:\n\n- **Dedupe.** The same root issue often surfaces across multiple lenses. Merge it.\n- **Surface cross-cutting themes.** Where several lenses independently land on the same\n  subsystem or boundary, that convergence is the highest-signal result — lead with it.\n- **Rank by impact.** Be opinion-forward and critical. The synthesis carries an explicit\n  overall verdict that may be net-negative — do not soften it with manufactured positives.\n  Note strengths only where they are genuine and material to the verdict.\n\n### Phase 4 — Deliver\n\nWrite the report to `.\u002Fdocs\u002Farchitecture-reviews\u002F\u003Cdescriptive-name>.md` (create the\ndirectory if needed), following\n[`references\u002Freport-template.md`](references\u002Freport-template.md). The directory allows\nmultiple reviews over time.\n","# Architecture Review\n\nCritical architectural assessment. Judge system design — boundaries,\nresponsibilities, coupling, data flow, failure modes, evolvability, information hiding. Read-only; produces a written assessment and prioritised recommendations,\ndoes not edit source files.\n\n**Stance.** Adversarial, not a balanced scorecard. Hunt for what is wrong, weak, or risky.\nNever manufacture strengths for balance — praise is earned, and any dimension (or the whole\nsystem) may come back net-negative. Stay high-signal: surface the issues that matter and go\n*deep* on each (root cause, blast radius, evidence), not a long list of shallow nitpicks.\n\n**Agnostic vocabulary, stack-specific probes.** The vocabulary is technology-agnostic (a god\nobject is a god object in any language); formatting, naming, and idiom stay out of scope. But\nprobes adapt to the stack — a frontend's design-system\u002Ftheming, UI\u002FUX, and component-API\nconsistency are architectural, and a generic review misses them. See\n[`references\u002Fdomain-probes.md`](references\u002Fdomain-probes.md).\n\n## Capabilities\n\nA staff-engineer reviewer operating this skill:\n\n- Identifies the architectural style in use and evaluates whether it fits the system's actual constraints\n- Names patterns precisely — where they are applied correctly, misapplied, or conspicuously absent\n- Traces data flow and transaction\u002Fconsistency boundaries across service and module edges\n- Locates resilience and scalability ceilings (missing circuit breakers, unbounded queues, stateful services)\n- Maps trust boundaries and identity\u002Fsecret flow; flags where authentication, authorisation, or secret handling is absent or porous\n- Assesses module depth, coupling direction, cohesion, and information-hiding discipline\n- Surfaces genuine quality-attribute trade-offs rather than treating all dimensions as simultaneously maximisable\n- Grounds every finding in code evidence — and, where the repo provides it, in measured evidence (bundle reports, dependency graphs, coverage, profiles), not reasoning from reading alone\n- Is willing to deliver a net-negative verdict; reserves praise for what is genuinely well-built\n\nThe vocabulary for naming patterns precisely lives in\n[`references\u002Fknowledge-base.md`](references\u002Fknowledge-base.md).\nThe per-dimension rubric (what good looks like, checklists, anti-patterns) lives in\n[`references\u002Fdimensions.md`](references\u002Fdimensions.md).\n\n## Process\n\n### Phase 1 — Discover and map\n\nUse the Agent tool with `subagent_type=Explore` to build a **system map**:\n\n- Entry points and how the system is driven\n- Top-level modules \u002F services and their responsibilities\n- Major boundaries and seams\n- Data flow through a representative request or job\n- State, persistence, and ownership\n- External dependencies\n- Deployment \u002F runtime shape\n\nAlso **detect the stack** (frontend, backend, data\u002FML, infra, library, or a mix) and list\nthe build\u002Fanalysis tooling the repo provides (bundlers, dependency analysers, coverage\nrunners, profilers). The stack selects which stack-specific probes to inject (see\n[`references\u002Fdomain-probes.md`](references\u002Fdomain-probes.md)); the tooling tells reviewers\nwhat to measure rather than estimate.\n\nRecord navigational friction — if understanding one concept requires bouncing between\nmany files, note it. The system map is both this phase's output and the shared context\nfor all reviewer subagents. Do not grade yet.\n\n### Phase 2 — Fan out per-dimension reviewers\n\nSpawn **seven reviewer subagents in parallel** — one message, seven Agent calls,\n`subagent_type=Explore`. Each owns one lens:\n\n1. **Simplicity & understandability**\n2. **Maintainability**\n3. **Extensibility**\n4. **Security**\n5. **Performance & scalability**\n6. **Modularity** (deep modules + coupling & cohesion)\n7. **Deployability** (release coupling, CI\u002Fbuild-matrix coupling, operational blast radius)\n\nRead [`references\u002Fdimensions.md`](references\u002Fdimensions.md) and\n[`references\u002Fknowledge-base.md`](references\u002Fknowledge-base.md). For each reviewer, paste\n(a) their dimension's section from `dimensions.md`, (b) the knowledge-base domains\nlisted for their lens in the **Lens → domains mapping** table at the end of\n`knowledge-base.md`, and (c) any stack-specific probes for their lens from\n[`references\u002Fdomain-probes.md`](references\u002Fdomain-probes.md) matching the stack detected in\nPhase 1. Subagents do not share your context.\n\n**Measure, don't estimate.** `Explore` agents can run read-only shell commands. Where Phase\n1 found tooling, tell the reviewer to run it and cite the output (bundle report → Performance,\ndependency\u002Fcycle graph → Modularity, coverage → Maintainability). Flag any claim that is an\nestimate because no tooling existed.\n\n**Subagent prompt template** — fill the seven `{{...}}` slots per reviewer:\n\n```\nYou are a staff engineer performing a focused architecture review of the codebase at\n{{REPO_PATH}}. Your lens: {{DIMENSION NAME}}.\n\nAssess system design, not code style — boundaries, responsibilities, coupling, data flow,\nfailure modes, evolvability, information hiding. Formatting, naming, and idiom are out of\nscope unless they reveal a structural problem; stack-specific *architectural* concerns (e.g.\na frontend's design-system\u002Ftheming, UI\u002FUX, and component-API consistency) are in scope.\n\nSystem map (your ground truth — read the real code to confirm or challenge it):\n{{SYSTEM MAP}}\n\nRubric for your lens (definition, what good looks like, checklist, anti-patterns):\n{{PASTE THIS DIMENSION'S SECTION FROM references\u002Fdimensions.md}}\n\nArchitectural vocabulary relevant to your lens:\n{{PASTE THE KNOWLEDGE-BASE DOMAINS FOR THIS LENS FROM references\u002Fknowledge-base.md}}\n\nStack-specific probes for your lens (skip any that don't apply to this stack):\n{{PASTE THIS LENS'S PROBES FOR THE DETECTED STACK FROM references\u002Fdomain-probes.md, or \"none\"}}\n\nAvailable measurement tooling (run it and cite the output where it strengthens a finding):\n{{TOOLING FOUND IN PHASE 1 RELEVANT TO THIS LENS, or \"none found — reason from the code and say so\"}}\n\nName patterns from this vocabulary precisely where they apply, are misapplied, or are\nconspicuously absent. Do not force-fit — a pattern named where it does not belong is noise,\nnot insight.\n\nMethod: explore read-only (you may run read-only shell commands and the tooling above).\nGround every finding in file paths (with line ranges where useful) and measured output where\nyou have it.\n\nStance: be critical — find what is wrong, weak, or risky, do not reassure. Mention a strength\nonly if it is genuinely well-built and material. Stay high-signal: surface the issues that\nmatter and go deep on each (root cause, blast radius), not a pile of nitpicks.\n\nReturn narrative prose, no scores or severity tags. Structure:\n- A 2–3 sentence overall verdict — blunt, allowed to be net-negative. Note strengths only if real.\n- Findings, ranked most-serious first. Each: (a) what, (b) where — file-path\u002Fmeasured evidence,\n  (c) why it matters architecturally, (d) a direction for remediation (direction, not implementation).\nSay the dimension is healthy only if the evidence supports it — not as a default.\n```\n\n### Phase 3 — Synthesise\n\nCollect the seven reports:\n\n- **Dedupe.** The same root issue often surfaces across multiple lenses. Merge it.\n- **Surface cross-cutting themes.** Where several lenses independently land on the same\n  subsystem or boundary, that convergence is the highest-signal result — lead with it.\n- **Rank by impact.** Be opinion-forward and critical. The synthesis carries an explicit\n  overall verdict that may be net-negative — do not soften it with manufactured positives.\n  Note strengths only where they are genuine and material to the verdict.\n\n### Phase 4 — Deliver\n\nWrite the report to `.\u002Fdocs\u002Farchitecture-reviews\u002F\u003Cdescriptive-name>.md` (create the\ndirectory if needed), following\n[`references\u002Freport-template.md`](references\u002Freport-template.md). The directory allows\nmultiple reviews over time.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fcode\u002Farchitecture-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":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill architecture-review",{"tool":68,"command":69},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill architecture-review",{"tool":71,"command":72},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill architecture-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Farchitecture-review\u002FSKILL.md",true,[76,82,86,90,94],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"evals\u002Fevals.json","REFERENCE","参考文档",1771,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Farchitecture-review\u002Fevals\u002Fevals.json",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fdimensions.md",17118,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Farchitecture-review\u002Freferences\u002Fdimensions.md",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fdomain-probes.md",4330,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Farchitecture-review\u002Freferences\u002Fdomain-probes.md",{"path":91,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fknowledge-base.md",15444,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Farchitecture-review\u002Freferences\u002Fknowledge-base.md",{"path":95,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Freport-template.md",2386,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Farchitecture-review\u002Freferences\u002Freport-template.md",[99,107,114,140,168,194],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":106},"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":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":106},"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":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":49},"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",[],[121,122,123,124,125,126,127,128,45,129,130,131,132,133,134,31,135,136,137,138,139],"tickets","to tickets","new","signatures","github","plan","batch","task","manifest","plans","true","ticket","command","repo","feature","run","worktrees","as","cut",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":151,"publishedAt":49},"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",[146],{"categoryNo":147,"categoryName":148,"taxonomyType":149,"taxonomyTypeDesc":150},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[152,153,123,154,155,156,157,158,159,22,160,23,161,131,162,163,164,134,31,165,166,167,138,133],"to seams","schema","neither","it","but","file","prompt","either","writing","interface","repos","block","records","build","can","record",{"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":179,"publishedAt":49},"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",[174],{"categoryNo":175,"categoryName":176,"taxonomyType":177,"taxonomyTypeDesc":178},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[180,26,181,138,135,182,183,23,184,185,186,121,187,188,126,189,190,131,132,191,192,193],"to roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":201,"publishedAt":49},"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",[200],{"categoryNo":175,"categoryName":176,"taxonomyType":177,"taxonomyTypeDesc":178},[202,203,204,205,206,207,208,209,121,210,126,211,212,213,131,192,135,214,215,138],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem","which"]