[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXBPY88YKQYVMDPX8SZ95H":3,"skill-same:01M6BXBPY88YKQYVMDPX8SZ95H":81},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6BXBPY88YKQYVMDPX8SZ95H","prototype",null,"Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.","Tohuhono\u002FOberon","Tohuhono","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F135709951?v=4","01M6BXAYQ0F1T2E4Y2T5T1J4AH","01M6BXAYVMYXSWAB9DGD0K3HXY",23,"MIT","https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fprototype\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[5,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"when","design","throwaway","state model","answer","sanity","logic","build","look","use","user","question","check","model","explore","ui","state","2026-11-10 10:12:30",false,"---\nname: prototype\ndescription:\n  Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check\n  whether a state model or logic feels right, or explore what a UI should look like.\n---\n\n# Prototype\n\nA prototype is **throwaway code that answers a question**. The question decides the shape.\n\nRead [CONTEXT.md](..\u002F..\u002FCONTEXT.md) for domain names and [ARCHITECTURE.md](..\u002F..\u002FARCHITECTURE.md)\nfor the affected runtime or Framework integration.\n\n## Pick a branch\n\nIdentify which question is being answered, using the user's prompt, the surrounding code, or by\nasking if the user is around:\n\n- **\"Does this logic \u002F state model feel right?\"** → [LOGIC.md](LOGIC.md). Build a single shareable\n  HTML file (free-play buttons plus tabbed guided walkthroughs) that pushes the state machine\n  through cases that are hard to reason about on paper, and that a non-developer can drive.\n- **\"What should this look like?\"** → [UI.md](UI.md). Generate several radically different UI\n  variations on a single route, switchable via a URL search param and a floating bottom bar.\n\nThe two branches produce different artifacts. If the question is ambiguous, confirm whether the user\nwants to explore logic or UI before building it.\n\n## Rules that apply to both\n\n1. **Keep it temporary.** Put standalone logic demos in `.tmp\u002F`. Put UI variants next to their host\n   page in the affected Playground, clearly named as prototypes. Follow the host's routing\n   convention and keep prototype-only code out of published package exports.\n2. **Use the root workflow.** Run UI prototypes with the existing root command for their host:\n   `pnpm dev:oberon` for the Next.js Playground or `pnpm dev:new` for the TanStack Playground. Use\n   `pnpm dev:docs` only when the task concerns the Documentation app. A logic demo opens as a single\n   HTML file. If no root script covers the need, ask before changing the root workflow.\n3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is\n   _checking_, not something it should depend on. If the question explicitly involves a database,\n   hit a scratch DB or a local file with a clear \"PROTOTYPE, wipe me\" name.\n4. **Keep the scope small.** Build only what answers the question. Use existing UI and error\n   reporting; avoid production abstractions and a separate prototype test suite.\n5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or\n   render the full relevant state so the user can see what changed.\n6. **Verify the demo.** Check that the host responds and the controls work in the browser. Run\n   `pnpm format` and `pnpm validate` from the root before handoff. Report what the prototype does\n   and does not verify.\n\n## Capture the answer and choose the follow-up\n\nRecord the question, verdict, and supporting prototype path or URL in the existing implementation\nissue or discussion. If there is no issue, summarise them to the user.\n\nOffer to integrate the validated decision or preserve the prototype on a throwaway branch. Create a\nbranch, commit, or push only when the user requests it. Keep the prototype available until the user\ndecides which follow-up they want.\n\nIf the user requests integration, implement the decision to production standards with the coverage\nin [TESTING.md](..\u002F..\u002FTESTING.md), then remove the temporary shell, losing variants, and switcher.\nPreserving a prototype on a branch is optional, not a completion requirement.\n","# Prototype\n\nA prototype is **throwaway code that answers a question**. The question decides the shape.\n\nRead [CONTEXT.md](..\u002F..\u002FCONTEXT.md) for domain names and [ARCHITECTURE.md](..\u002F..\u002FARCHITECTURE.md)\nfor the affected runtime or Framework integration.\n\n## Pick a branch\n\nIdentify which question is being answered, using the user's prompt, the surrounding code, or by\nasking if the user is around:\n\n- **\"Does this logic \u002F state model feel right?\"** → [LOGIC.md](LOGIC.md). Build a single shareable\n  HTML file (free-play buttons plus tabbed guided walkthroughs) that pushes the state machine\n  through cases that are hard to reason about on paper, and that a non-developer can drive.\n- **\"What should this look like?\"** → [UI.md](UI.md). Generate several radically different UI\n  variations on a single route, switchable via a URL search param and a floating bottom bar.\n\nThe two branches produce different artifacts. If the question is ambiguous, confirm whether the user\nwants to explore logic or UI before building it.\n\n## Rules that apply to both\n\n1. **Keep it temporary.** Put standalone logic demos in `.tmp\u002F`. Put UI variants next to their host\n   page in the affected Playground, clearly named as prototypes. Follow the host's routing\n   convention and keep prototype-only code out of published package exports.\n2. **Use the root workflow.** Run UI prototypes with the existing root command for their host:\n   `pnpm dev:oberon` for the Next.js Playground or `pnpm dev:new` for the TanStack Playground. Use\n   `pnpm dev:docs` only when the task concerns the Documentation app. A logic demo opens as a single\n   HTML file. If no root script covers the need, ask before changing the root workflow.\n3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is\n   _checking_, not something it should depend on. If the question explicitly involves a database,\n   hit a scratch DB or a local file with a clear \"PROTOTYPE, wipe me\" name.\n4. **Keep the scope small.** Build only what answers the question. Use existing UI and error\n   reporting; avoid production abstractions and a separate prototype test suite.\n5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or\n   render the full relevant state so the user can see what changed.\n6. **Verify the demo.** Check that the host responds and the controls work in the browser. Run\n   `pnpm format` and `pnpm validate` from the root before handoff. Report what the prototype does\n   and does not verify.\n\n## Capture the answer and choose the follow-up\n\nRecord the question, verdict, and supporting prototype path or URL in the existing implementation\nissue or discussion. If there is no issue, summarise them to the user.\n\nOffer to integrate the validated decision or preserve the prototype on a throwaway branch. Create a\nbranch, commit, or push only when the user requests it. Keep the prototype available until the user\ndecides which follow-up they want.\n\nIf the user requests integration, implement the decision to production standards with the coverage\nin [TESTING.md](..\u002F..\u002FTESTING.md), then remove the temporary shell, losing variants, and switcher.\nPreserving a prototype on a branch is optional, not a completion requirement.\n",{"name":5,"description":7},"main","14802e0b8d6e1798a47427c4aaff725758531e24",".agents\u002Fskills\u002Fprototype",4,"https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon","https:\u002F\u002Foberon-tohuhono.vercel.app","https:\u002F\u002Fgithub.com\u002FTohuhono","2026-11-10 16:26:11",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add Tohuhono\u002FOberon --skill prototype",{"tool":59,"command":60},"bunx","bunx skills add Tohuhono\u002FOberon --skill prototype",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Tohuhono\u002FOberon --skill prototype","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fprototype\u002FSKILL.md",true,[67,73,77],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"agents\u002Fopenai.yaml","REFERENCE","参考文档",100,"https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fprototype\u002Fagents\u002Fopenai.yaml",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"LOGIC.md",6166,"https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fprototype\u002FLOGIC.md",{"path":78,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":80},"UI.md",7052,"https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fprototype\u002FUI.md",[82,99,119,142,155,172],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":40},"01M716NHE5Y7QMMR5FZEY2D84S","wait-what","Stop. That last message did not land: re-pitch it.","https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[89,90,91,92,93,94,95,96,97,98],"wait what","wait","last","true","message","land","re","pitch","it","stop",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":40},"01M6BXBYKDEB19X2DVZWDDQ43N","to-tickets","Break a plan, spec, or conversation into tracer-bullet GitHub issues for Oberon, with category and state labels, sub-issues, and blocking relationships.","https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fto-tickets\u002FSKILL.md",[],[106,107,108,109,110,111,92,112,113,114,115,39,116,117,118],"to tickets","tickets","plan","labels","break","for","with","relationships","conversation","issues","github issues","github","spec",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":40},"01M6BXBTNJ43ZFWMKJRJX0Q51Y","tdd","Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions \"red-green-refactor\", or wants integration tests.","https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftdd\u002FSKILL.md",[],[121,126,127,128,129,130,131,132,133,23,30,134,32,135,136,137,138,139,140,141],"green","test-first","test-driven","features","bugs","fix bugs","red","tests","red-green-refactor","fix","first","refactor","integration","integration tests","test","development",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":40},"01M6BXBKWFJFYVS7MZKYKNHS2Y","handoff","Compact the current conversation into a handoff document for another agent to pick up.","https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fhandoff\u002FSKILL.md",[],[144,149,111,92,150,151,114,152,153,154],"session","next","compact","document","up","pick",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":40},"01M6BXBGFFK8E8H92GRKST59HG","grill-with-docs","A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.","https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fgrill-with-docs\u002FSKILL.md",[],[112,162,163,164,24,165,166,92,167,168,169,170,171,108],"grill","grill with docs","docs","go","which","as","interview","glossary","adr","sharpen",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":186,"publishedAt":40},"01M6BXB0ZGP9VZY05BE2S32Z4X","code-review","Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue\u002Fspec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".","https:\u002F\u002Fgithub.com\u002FTohuhono\u002FOberon\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcode-review\u002FSKILL.md",[178,183],{"categoryNo":179,"categoryName":180,"taxonomyType":181,"taxonomyTypeDesc":182},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":184,"categoryName":185,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师",[187,188,189,32,23,190,191,111,192,193,194,195,196,197,198,199,200,201,202,203,204,118],"review","code review","code","point","changes","reviews","progress","what the","reports","standards","repo","branch","work","parallel","coding standards","pr","merge","commit"]