[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CPA1EP5JD7E9CKA080MPPM":3,"skill-same:01M6CPA1EP5JD7E9CKA080MPPM":70},{"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":23,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":69},"01M6CPA1EP5JD7E9CKA080MPPM","write-product-spec",null,"Write a PRODUCT.md spec for a significant Hubble user-facing feature, focused only on user experience and observable behavior. Use when the user asks for a product spec, UX spec, PRD, desired behavior doc, or wants feature behavior clarified before implementation.","bholmesdev\u002Fhubble.md","bholmesdev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F51384119?v=4","01M6CP8SJ3N9W8FYVCGV41QT3G","Ben Holmes","01M6CP8SP3A84K1TFMVS8BEBDW",1524,"MIT","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwrite-product-spec\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"spec","product","write","write product spec","ux","prd","doc","behavior","user","use","only","implementation","user experience","feature","true","for","2026-11-10 10:12:30",false,"---\nname: write-product-spec\ndescription: Write a PRODUCT.md spec for a significant Hubble user-facing feature, focused only on user experience and observable behavior. Use when the user asks for a product spec, UX spec, PRD, desired behavior doc, or wants feature behavior clarified before implementation.\nmetadata:\n  internal: true\n---\n\n# write-product-spec\n\nWrite a `PRODUCT.md` spec for a significant Hubble feature.\n\n## Overview\n\nThe product spec settles the product decisions and spells out the user flow. A maintainer should be able to scan it in under a minute and either agree or point at the exact bullet they disagree with. It is a decision record, not documentation: write the choices, not the reasoning that led to them.\n\nStay out of implementation. No internal types, state layout, data flow, module architecture, or file paths. Those belong in the companion `TECH.md` from `write-tech-spec`.\n\n\"User\" means the consumer of the surface: the person using Hubble desktop or web, or the developer invoking `hubble` for CLI surfaces.\n\nWrite specs to `specs\u002F\u003Cid>\u002FPRODUCT.md`, where `\u003Cid>` is a GitHub issue id prefixed with `gh-` (for example `specs\u002Fgh-456\u002FPRODUCT.md`) or a short kebab-case feature name. `specs\u002F` should contain only id-named directories as direct children. Use the sibling `TECH.md` path for the same id.\n\nOnly create a GitHub issue when the user explicitly asks. This repo uses GitHub Issues on `bholmesdev\u002Fhubble.md` via `gh`; see `docs\u002Fagents\u002Fissue-tracker.md`.\n\n## Before Writing\n\nGather only enough context to write observable behavior:\n\n- The existing user journey and the desired one.\n- Nearby Hubble screens, flows, and design-system primitives the experience should reuse. Do not invent a new visual system.\n- Project vocabulary from `CONTEXT.md`: Workspace, Workspace Folder, Plain Folder, Loose File, Cloud Sync, Markdown File, Asset, Embed, Embed Bundle, Workspace Snapshot.\n\n## Structure\n\n1. **Summary** — 1-2 sentences: the feature and the outcome.\n2. **Flows** — the core of the spec. For each user flow, spell it out step by step: where the user starts, what they do, what they see at each step. Group the decisions that shape each flow as short bullets directly under it: inputs and their results, error and empty states, cross-surface (desktop vs web) differences, and what stays unchanged. One bullet per decision; state the choice, not the options considered.\n3. **Out of scope** — bullets for what this slice deliberately does not do, including anything from the original issue that was dropped and why in a few words.\n\nOptional, only when they earn their lines:\n\n- **Problem** — one short paragraph, only when motivation is not obvious.\n- **Open questions** — prefer inline `**Open question:** ...` next to the affected bullet.\n\nDo not include implementation, module breakdown, engineering validation, or success criteria. The E2E test plan lives in `TECH.md` and should derive directly from the Flows section here.\n\n## Writing Guidance\n\n- Every bullet is a testable, observable behavior: what the user does and what they see.\n- Cover the happy path completely, then only the edge cases where the answer is not obvious: error, empty, offline, conflict, and cancellation states that a reviewer would otherwise have to guess.\n- Name existing primitives the user experiences (dialog, toast, popover, menu item) rather than describing new UI from scratch.\n- Note Workspace-state differences (Workspace Folder, Plain Folder, Loose File, synced) only when the behavior actually differs.\n- Target 20-60 lines total. If a section restates another, collapse it. Long numbered invariant lists are a smell: fold them into the flow they belong to.\n\n## Keep Current\n\nUpdate `PRODUCT.md` in the same PR when shipped behavior changes. The checked-in spec should describe what ships.\n\n## Related Skills\n\n- `write-tech-spec`\n- `to-issues`\n- `grill-with-docs`\n","# write-product-spec\n\nWrite a `PRODUCT.md` spec for a significant Hubble feature.\n\n## Overview\n\nThe product spec settles the product decisions and spells out the user flow. A maintainer should be able to scan it in under a minute and either agree or point at the exact bullet they disagree with. It is a decision record, not documentation: write the choices, not the reasoning that led to them.\n\nStay out of implementation. No internal types, state layout, data flow, module architecture, or file paths. Those belong in the companion `TECH.md` from `write-tech-spec`.\n\n\"User\" means the consumer of the surface: the person using Hubble desktop or web, or the developer invoking `hubble` for CLI surfaces.\n\nWrite specs to `specs\u002F\u003Cid>\u002FPRODUCT.md`, where `\u003Cid>` is a GitHub issue id prefixed with `gh-` (for example `specs\u002Fgh-456\u002FPRODUCT.md`) or a short kebab-case feature name. `specs\u002F` should contain only id-named directories as direct children. Use the sibling `TECH.md` path for the same id.\n\nOnly create a GitHub issue when the user explicitly asks. This repo uses GitHub Issues on `bholmesdev\u002Fhubble.md` via `gh`; see `docs\u002Fagents\u002Fissue-tracker.md`.\n\n## Before Writing\n\nGather only enough context to write observable behavior:\n\n- The existing user journey and the desired one.\n- Nearby Hubble screens, flows, and design-system primitives the experience should reuse. Do not invent a new visual system.\n- Project vocabulary from `CONTEXT.md`: Workspace, Workspace Folder, Plain Folder, Loose File, Cloud Sync, Markdown File, Asset, Embed, Embed Bundle, Workspace Snapshot.\n\n## Structure\n\n1. **Summary** — 1-2 sentences: the feature and the outcome.\n2. **Flows** — the core of the spec. For each user flow, spell it out step by step: where the user starts, what they do, what they see at each step. Group the decisions that shape each flow as short bullets directly under it: inputs and their results, error and empty states, cross-surface (desktop vs web) differences, and what stays unchanged. One bullet per decision; state the choice, not the options considered.\n3. **Out of scope** — bullets for what this slice deliberately does not do, including anything from the original issue that was dropped and why in a few words.\n\nOptional, only when they earn their lines:\n\n- **Problem** — one short paragraph, only when motivation is not obvious.\n- **Open questions** — prefer inline `**Open question:** ...` next to the affected bullet.\n\nDo not include implementation, module breakdown, engineering validation, or success criteria. The E2E test plan lives in `TECH.md` and should derive directly from the Flows section here.\n\n## Writing Guidance\n\n- Every bullet is a testable, observable behavior: what the user does and what they see.\n- Cover the happy path completely, then only the edge cases where the answer is not obvious: error, empty, offline, conflict, and cancellation states that a reviewer would otherwise have to guess.\n- Name existing primitives the user experiences (dialog, toast, popover, menu item) rather than describing new UI from scratch.\n- Note Workspace-state differences (Workspace Folder, Plain Folder, Loose File, synced) only when the behavior actually differs.\n- Target 20-60 lines total. If a section restates another, collapse it. Long numbered invariant lists are a smell: fold them into the flow they belong to.\n\n## Keep Current\n\nUpdate `PRODUCT.md` in the same PR when shipped behavior changes. The checked-in spec should describe what ships.\n\n## Related Skills\n\n- `write-tech-spec`\n- `to-issues`\n- `grill-with-docs`\n",{"name":5,"metadata":45,"description":7},{"internal":46},true,"main","cf633b3221b9572f22604168ac77c1ffa921debe",".agents\u002Fskills\u002Fwrite-product-spec",100,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md","https:\u002F\u002Fhubble.md","https:\u002F\u002Fgithub.com\u002Fbholmesdev","https:\u002F\u002Fbholmes.dev","Web developer, teacher, whiteboardist. Building the next terminal @warpdotdev ","2026-11-06 02:02:39",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":46},[59,62,65],{"tool":60,"command":61},"npx","npx skills add bholmesdev\u002Fhubble.md --skill write-product-spec",{"tool":63,"command":64},"bunx","bunx skills add bholmesdev\u002Fhubble.md --skill write-product-spec",{"tool":66,"command":67},"pnpm","pnpm dlx skills add bholmesdev\u002Fhubble.md --skill write-product-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwrite-product-spec\u002FSKILL.md",[],[71,90,106,126,145,170],{"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":82,"publishedAt":40},"01M6PQAVS5DTTVEV9VA313YSYM","review-markdown-comments","Reply to, resolve, or reopen Hubble review comments stored as CriticMarkup in Markdown files. Use when asked to address a Hubble review comment.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freview-markdown-comments\u002FSKILL.md",[77],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[83,84,85,86,87,88,89,33],"review markdown comments","comments","review","markdown","as","files","reply",{"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":40},"01M6PQAH29FCQB6921Y94CA8F4","merge-risk","Use when assessing the risk of merging a PR","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmerge-risk\u002FSKILL.md",[],[97,98,99,100,101,102,103,104,38,105,33,47],"merge","risk","merge risk","github","blob","pr","https","engineering","matt pocock",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":116,"publishedAt":40},"01M6PQA0ADFHMANPW4KRAV7EA6","embed-html-app","Embed a Hubble HTML App inline inside a Markdown File using an iframe block. Use when an app should be viewed in the context of a document.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fembed-html-app\u002FSKILL.md",[112,113],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},{"categoryNo":114,"categoryName":115,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000009","前端开发",[117,118,119,120,121,122,86,123,33,124,125],"html","app","embed","embed html app","inline","file","context","document","block",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":40},"01M6PQ9WQM5HF4QQ1J750346NY","edit-diagram","Create or edit a Hubble diagram: a .tldr file Hubble opens in its built-in tldraw canvas. With this skill installed, any diagram, canvas, whiteboard, or .tldr file is a Hubble diagram: use this skill instead of tldraw-offline, unless the user names the tldraw offline app or the file is a .tldraw archive.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fedit-diagram\u002FSKILL.md",[],[133,134,135,33,136,137,138,139,122,140,141,142,32,118,143,144],"edit diagram","edit","diagram","whiteboard","canvas","create","offline","tldraw offline","archive","tldr","tldraw","with",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":155,"publishedAt":40},"01M6PQ9JKMF9ZDQWNVSA38VCTT","create-html-app","Create or update a Hubble HTML App: a folder-local .html file Hubble runs as a self-contained interactive UI, with Alpine, Tailwind, Hubble theme tokens, and the injected hubble runtime API.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcreate-html-app\u002FSKILL.md",[151,152],{"categoryNo":114,"categoryName":115,"taxonomyType":80,"taxonomyTypeDesc":81},{"categoryNo":153,"categoryName":154,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000010","后端与接口",[156,118,117,138,157,158,159,160,161,162,163,164,165,166,122,167,87,168,144,169],"create html app","ui","theme tokens","runtime","tokens","local","self","interactive","Tailwind","api","alpine","update","theme","folder",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":40},"01M6CPAR6ECFN9P9H1S4XWDCB1","convex","Routes general Convex requests to the right project skill. Use when the user asks which Convex skill to use or gives an underspecified Convex app task.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex\u002FSKILL.md",[],[172,177,178,179,33,32],"task","general","project skill"]