[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7B33CDNQF9CE5072HYJ27VT":3,"skill-same:01M7B33CDNQF9CE5072HYJ27VT":49},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M7B33CDNQF9CE5072HYJ27VT","mermaid-diagrams",null,"Best practices for when to create Mermaid diagrams and how to write good ones — layout direction, readability, shape choice, and anti-patterns. Use when writing or reviewing blueprints, initiatives, or briefs that need visual structure, when deciding whether a diagram is the right format, or when a Mermaid diagram is already in a doc and needs review.","gethamster\u002Fskills","gethamster","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F215697643?v=4","01M7B2R6PGB3SDZZ71E0WE2S74","Hamster","01M7B2R6Q21HWJRXZZWB78BNDG",4,"MIT","https:\u002F\u002Fgithub.com\u002Fgethamster\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002F.experimental\u002Fmermaid-diagrams\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: mermaid-diagrams\ndescription: \"Best practices for when to create Mermaid diagrams and how to write good ones — layout direction, readability, shape choice, and anti-patterns. Use when writing or reviewing blueprints, initiatives, or briefs that need visual structure, when deciding whether a diagram is the right format, or when a Mermaid diagram is already in a doc and needs review.\"\nversion: \"1.0.0\"\ncategory: \"Development\"\n---\n\n# Mermaid Diagrams\n\nBest practices for when to create Mermaid diagrams and how to write good ones. Use when writing or reviewing blueprints, initiatives, or briefs that need visual structure.\n\n## When to Create a Diagram\n\n**Create a diagram when:**\n\n- The relationships between 4+ entities matter and prose would bury the structure.\n- A workflow has branching, parallelism, or conditional paths that are hard to follow linearly.\n\n**Do NOT create a diagram when:**\n\n- The content is a simple sequential list — a numbered list is better.\n- A table communicates the same information more clearly — diagrams are for relationships, not tabular data.\n\n### In blueprints\n\nUse diagrams for: architecture, data flow, system relationships, workflow sequences.\n\n### In initiatives\n\nUse diagrams for: dependency chains, team handoff flows, milestone sequencing.\n\n### In briefs\n\nUse diagrams for: task dependency graphs, integration points, data flow within the feature.\n\n## Mermaid Best Practices\n\n### Direction\n\n- Always set `TD` or `LR` explicitly — never rely on the default.\n- Prefer `flowchart TD` (top-down) for pipelines with 5+ nodes. Horizontal diagrams become unreadably wide.\n- Use `flowchart LR` (left-right) only when the diagram is naturally wide and shallow (2–3 rows of nodes).\n- Aim for a roughly square aspect ratio. If the diagram is too wide or too tall, switch direction.\n\n### Structure\n\n- Use subgraphs to group related nodes and create visual structure.\n- Use `direction LR` inside a subgraph to create horizontal sections within a vertical flow — good for grouping routines, side paths, or parallel tracks.\n\n### Links\n\n- Use solid links (`-->`) for the main flow.\n- Use dashed links (`-.->`) for alternative paths, optional branches, or cross-cutting concerns.\n- Never mix more than 2 link styles. Solid = main, dashed = alternatives. That's it.\n\n### Labels and Shapes\n\n- Keep node labels to 1–3 words. If a label needs more than 3–4 words, the diagram is too complex — split it.\n- Use consistent node shapes: rectangles `[label]` for processes, rounded `(label)` for start\u002Fend, diamonds `{label}` for decisions.\n- Add a brief one-line caption above the diagram explaining what it shows.\n\n## Anti-Patterns\n\n- **`flowchart LR` with 8+ nodes in a single row** — becomes an unreadable horizontal strip. Switch to `TD`.\n- **Node labels that are full sentences** — keep them to 1–3 words.\n- **Mixing too many link styles without clear meaning** — pick 2 max (solid for main, dashed for alternatives).\n- **Diagrams that duplicate what a table or list already says** — diagrams are for relationships, not tabular data.\n- **Overly nested subgraphs (3+ levels)** — flatten or split into multiple diagrams.\n- **No direction specified** — always set `TD` or `LR` explicitly, never rely on default.\n\n## Examples\n\n### Example 1 — Vertical pipeline (good for workflows with many sequential steps)\n\n```mermaid\nflowchart TD\n    A[brainstorming] --> B[writing-plans]\n    B --> C[using-git-worktrees]\n    C --> D[subagent-driven-development]\n    D --> E[finishing-a-development-branch]\n    E --> F[verification]\n```\n\n### Example 2 — Vertical flow with horizontal subgraph (good for main flow + grouped side concerns)\n\n```mermaid\nflowchart TD\n    A[start] --> B[main step]\n    B --> C[another step]\n    C --> D[finish]\n\n    subgraph side[\"Cross-cutting\"]\n        direction LR\n        E[debugging]\n        F[parallel agents]\n    end\n\n    B -.-> E\n    C -.-> F\n```\n\n### Example 3 — Horizontal flow (good for 2–3 wide, shallow diagrams)\n\n```mermaid\nflowchart LR\n    A[input] --> B[process] --> C[output]\n```\n\n## Decision Guide: Diagram vs Prose vs Table vs List\n\n| Format | Use when |\n| --- | --- |\n| **Diagram** | 4+ entities with relationships that matter; branching\u002Fparallel\u002Fconditional workflows |\n| **Prose** | Narrative explanation, context, rationale — when the *why* matters more than the *what connects to what* |\n| **Table** | Comparing attributes across items; structured data with clear columns |\n| **List** | Simple sequential steps; items with no meaningful relationships between them |\n","# Mermaid Diagrams\n\nBest practices for when to create Mermaid diagrams and how to write good ones. Use when writing or reviewing blueprints, initiatives, or briefs that need visual structure.\n\n## When to Create a Diagram\n\n**Create a diagram when:**\n\n- The relationships between 4+ entities matter and prose would bury the structure.\n- A workflow has branching, parallelism, or conditional paths that are hard to follow linearly.\n\n**Do NOT create a diagram when:**\n\n- The content is a simple sequential list — a numbered list is better.\n- A table communicates the same information more clearly — diagrams are for relationships, not tabular data.\n\n### In blueprints\n\nUse diagrams for: architecture, data flow, system relationships, workflow sequences.\n\n### In initiatives\n\nUse diagrams for: dependency chains, team handoff flows, milestone sequencing.\n\n### In briefs\n\nUse diagrams for: task dependency graphs, integration points, data flow within the feature.\n\n## Mermaid Best Practices\n\n### Direction\n\n- Always set `TD` or `LR` explicitly — never rely on the default.\n- Prefer `flowchart TD` (top-down) for pipelines with 5+ nodes. Horizontal diagrams become unreadably wide.\n- Use `flowchart LR` (left-right) only when the diagram is naturally wide and shallow (2–3 rows of nodes).\n- Aim for a roughly square aspect ratio. If the diagram is too wide or too tall, switch direction.\n\n### Structure\n\n- Use subgraphs to group related nodes and create visual structure.\n- Use `direction LR` inside a subgraph to create horizontal sections within a vertical flow — good for grouping routines, side paths, or parallel tracks.\n\n### Links\n\n- Use solid links (`-->`) for the main flow.\n- Use dashed links (`-.->`) for alternative paths, optional branches, or cross-cutting concerns.\n- Never mix more than 2 link styles. Solid = main, dashed = alternatives. That's it.\n\n### Labels and Shapes\n\n- Keep node labels to 1–3 words. If a label needs more than 3–4 words, the diagram is too complex — split it.\n- Use consistent node shapes: rectangles `[label]` for processes, rounded `(label)` for start\u002Fend, diamonds `{label}` for decisions.\n- Add a brief one-line caption above the diagram explaining what it shows.\n\n## Anti-Patterns\n\n- **`flowchart LR` with 8+ nodes in a single row** — becomes an unreadable horizontal strip. Switch to `TD`.\n- **Node labels that are full sentences** — keep them to 1–3 words.\n- **Mixing too many link styles without clear meaning** — pick 2 max (solid for main, dashed for alternatives).\n- **Diagrams that duplicate what a table or list already says** — diagrams are for relationships, not tabular data.\n- **Overly nested subgraphs (3+ levels)** — flatten or split into multiple diagrams.\n- **No direction specified** — always set `TD` or `LR` explicitly, never rely on default.\n\n## Examples\n\n### Example 1 — Vertical pipeline (good for workflows with many sequential steps)\n\n```mermaid\nflowchart TD\n    A[brainstorming] --> B[writing-plans]\n    B --> C[using-git-worktrees]\n    C --> D[subagent-driven-development]\n    D --> E[finishing-a-development-branch]\n    E --> F[verification]\n```\n\n### Example 2 — Vertical flow with horizontal subgraph (good for main flow + grouped side concerns)\n\n```mermaid\nflowchart TD\n    A[start] --> B[main step]\n    B --> C[another step]\n    C --> D[finish]\n\n    subgraph side[\"Cross-cutting\"]\n        direction LR\n        E[debugging]\n        F[parallel agents]\n    end\n\n    B -.-> E\n    C -.-> F\n```\n\n### Example 3 — Horizontal flow (good for 2–3 wide, shallow diagrams)\n\n```mermaid\nflowchart LR\n    A[input] --> B[process] --> C[output]\n```\n\n## Decision Guide: Diagram vs Prose vs Table vs List\n\n| Format | Use when |\n| --- | --- |\n| **Diagram** | 4+ entities with relationships that matter; branching\u002Fparallel\u002Fconditional workflows |\n| **Prose** | Narrative explanation, context, rationale — when the *why* matters more than the *what connects to what* |\n| **Table** | Comparing attributes across items; structured data with clear columns |\n| **List** | Simple sequential steps; items with no meaningful relationships between them |\n",{"name":5,"version":24,"category":25,"description":7},"1.0.0","Development","main","fe3bb1476c3ec23d8a366eac0fa8cd9f0852360a","skills\u002F.experimental\u002Fmermaid-diagrams",0,"https:\u002F\u002Fgithub.com\u002Fgethamster\u002Fskills","https:\u002F\u002Fgithub.com\u002Fgethamster","https:\u002F\u002Ftryhamster.com","We're building the AI-native future of work, unlocking the promised acceleration for your whole team, from idea to impact.","2026-11-05 11:33:33",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add gethamster\u002Fskills --skill mermaid-diagrams",{"tool":41,"command":42},"bunx","bunx skills add gethamster\u002Fskills --skill mermaid-diagrams",{"tool":44,"command":45},"pnpm","pnpm dlx skills add gethamster\u002Fskills --skill mermaid-diagrams","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgethamster\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002F.experimental\u002Fmermaid-diagrams\u002FSKILL.md",true,[],[50,57,64,71,78,85],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":54,"categories":55,"keywords":56,"publishedAt":19},"01M7B5MWYW0KE251276S56KQDZ","writing-waterfall-requirements-documents","Write a waterfall requirements document: elicit, structure and review testable, traceable requirements, then baseline the specification before design.","https:\u002F\u002Fgithub.com\u002Fgethamster\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-waterfall-requirements-documents\u002FSKILL.md",[],[],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":19},"01M7B5MRCXWWPKREPB1CHQ7H90","writing-vision-and-values-statements","Write a V2MOM vision a reader can test and a ranked list of values that settles real tradeoffs, so the rest of the document has a clear anchor.","https:\u002F\u002Fgithub.com\u002Fgethamster\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-vision-and-values-statements\u002FSKILL.md",[],[],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"01M7B5MKH2CH22YZAHQW3080VQ","writing-system-prompts-for-claude","Write Claude prompts and CLAUDE.md files that supply exact inputs, scope the task, and define done so the first attempt can be checked.","https:\u002F\u002Fgithub.com\u002Fgethamster\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-system-prompts-for-claude\u002FSKILL.md",[],[],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"01M7B5ME1Y3X9RNRKP5HKHKACZ","writing-page-specific-website-copy","Website copywriting by page type: write homepage, landing page, pricing page and feature page copy that fits each page's visitor and single job.","https:\u002F\u002Fgithub.com\u002Fgethamster\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-page-specific-website-copy\u002FSKILL.md",[],[],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":19},"01M7B5M8MQNM8MN8PYH6BVWJ2B","writing-internal-press-releases","How to write an internal press release: the one-page working backwards press release that opens a PR\u002FFAQ document before anything is built.","https:\u002F\u002Fgithub.com\u002Fgethamster\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-internal-press-releases\u002FSKILL.md",[],[],{"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":19},"01M7B5M3P3YH1XF37R8PWXXSBK","writing-email-sequences-that-sell","Email sequence copywriting for nurture and sales: give each email one job, write clear subject lines, and close with one specific call to action.","https:\u002F\u002Fgithub.com\u002Fgethamster\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-email-sequences-that-sell\u002FSKILL.md",[],[]]