[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71K6X7XKZQJE1D8ZX40CXWR":3,"skill-same:01M71K6X7XKZQJE1D8ZX40CXWR":73},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M71K6X7XKZQJE1D8ZX40CXWR","grill-me",null,"Interactive assumption-surfacing Q&A that stress-tests a plan through relentless questioning until every decision is resolved. Use when user wants to challenge a plan, validate decisions from conversation\u002Fcontext, or mentions \"grill me\". For doc-grounded variant, use grill-with-docs.","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",292,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fgrill-me\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"grill","grill me","me","standard","interactive","decisions","use","tests","variant","for","context","sonnet","stress","doc","q&a","plan","when","challenge","decision","conversation","2026-11-10 10:12:30",false,"---\nname: grill-me\nmodel: sonnet\neffort: standard\ndescription: Interactive assumption-surfacing Q&A that stress-tests a plan through relentless questioning until every decision is resolved. Use when user wants to challenge a plan, validate decisions from conversation\u002Fcontext, or mentions \"grill me\". For doc-grounded variant, use grill-with-docs.\n---\n\n# Grill Me\n\n> **Use this vs grill-with-docs:** `grill-me` surfaces assumptions from the conversation and context alone — no documentation fetching. Use `grill-with-docs` (the doc-grounded variant) when the plan relies on a specific library or external API and every challenge must cite a real doc URL.\n\nTwo modes. Default is **Design**. Switch to **Docs** by saying \"grill me with docs\" or when the plan relies on a specific library or external API.\n\n> **HARD GATE** — Do NOT accept a design until every hard decision has been stress-tested. \"Seems right\" is not a decision. Grilling must identify and resolve tensions before build begins.\n\n## Design mode (default)\n\nInterview relentlessly about every aspect of this plan until reaching shared understanding. Walk each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask one question at a time.\n\nIf a question can be answered by exploring the codebase, explore it instead.\n\n### Facts vs. Decisions Boundary\n\nDistinguish between **facts** and **decisions**:\n- **Facts** — things discoverable by exploring the codebase, reading docs, or checking APIs. Do not ask the user to confirm facts; find them yourself.\n- **Decisions** — choices that require user input (trade-offs, preferences, priorities). Always present options and ask the user to choose.\n\nNever \"grill yourself\" — if the answer is in the code, go find it. Only ask questions where the user's judgment is needed.\n\n## Docs mode\n\nGround every challenge in real documentation — no assumption about a library's behavior goes unchecked. See [REFERENCE.md](REFERENCE.md) for the full process.\n\nShort form:\n1. List every external library, third-party API, and framework behavior relied upon.\n2. Fetch the actual docs for each (`WebFetch` the official API reference).\n3. Challenge each plan assumption against the real docs: correct method signature? right version? deprecated?\n4. Report confirmed ✓, corrected ✗ (with the real behavior), and uncertain → `spike-prototype`.\n5. Update the plan for each confirmed discrepancy.\n\n## Confirmation Gate\n\n> **HARD GATE** — Do NOT enact the plan or generate specifications until the user explicitly confirms shared understanding. Wait for explicit approval (e.g., \"looks good\", \"confirmed\", \"proceed\") before transitioning to any implementation, spec-writing, or task-slicing step.\n\n","# Grill Me\n\n> **Use this vs grill-with-docs:** `grill-me` surfaces assumptions from the conversation and context alone — no documentation fetching. Use `grill-with-docs` (the doc-grounded variant) when the plan relies on a specific library or external API and every challenge must cite a real doc URL.\n\nTwo modes. Default is **Design**. Switch to **Docs** by saying \"grill me with docs\" or when the plan relies on a specific library or external API.\n\n> **HARD GATE** — Do NOT accept a design until every hard decision has been stress-tested. \"Seems right\" is not a decision. Grilling must identify and resolve tensions before build begins.\n\n## Design mode (default)\n\nInterview relentlessly about every aspect of this plan until reaching shared understanding. Walk each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask one question at a time.\n\nIf a question can be answered by exploring the codebase, explore it instead.\n\n### Facts vs. Decisions Boundary\n\nDistinguish between **facts** and **decisions**:\n- **Facts** — things discoverable by exploring the codebase, reading docs, or checking APIs. Do not ask the user to confirm facts; find them yourself.\n- **Decisions** — choices that require user input (trade-offs, preferences, priorities). Always present options and ask the user to choose.\n\nNever \"grill yourself\" — if the answer is in the code, go find it. Only ask questions where the user's judgment is needed.\n\n## Docs mode\n\nGround every challenge in real documentation — no assumption about a library's behavior goes unchecked. See [REFERENCE.md](REFERENCE.md) for the full process.\n\nShort form:\n1. List every external library, third-party API, and framework behavior relied upon.\n2. Fetch the actual docs for each (`WebFetch` the official API reference).\n3. Challenge each plan assumption against the real docs: correct method signature? right version? deprecated?\n4. Report confirmed ✓, corrected ✗ (with the real behavior), and uncertain → `spike-prototype`.\n5. Update the plan for each confirmed discrepancy.\n\n## Confirmation Gate\n\n> **HARD GATE** — Do NOT enact the plan or generate specifications until the user explicitly confirms shared understanding. Wait for explicit approval (e.g., \"looks good\", \"confirmed\", \"proceed\") before transitioning to any implementation, spec-writing, or task-slicing step.\n\n",{"name":5,"model":30,"effort":22,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa","skills\u002Fgrill-me",23,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add danielvm-git\u002Fbigpowers --skill grill-me",{"tool":59,"command":60},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill grill-me",{"tool":62,"command":63},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill grill-me","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fgrill-me\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"REFERENCE.md","REFERENCE","参考文档",2341,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fgrill-me\u002FREFERENCE.md",[74,94,101,127,150,171],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":85,"publishedAt":39},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[86,87,88,89,90,91,92,28,93],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","never",{"skillNo":95,"name":96,"nameZh":6,"description":6,"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":39},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[100,91],"negative path",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":110,"publishedAt":39},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000002","文档处理",[111,112,113,114,115,116,117,118,119,22,25,35,120,121,30,122,123,124,125,126],"write","write document","document","documents","actionable","technical","methodology","high","bmad","minimal","bold","integrity","organize","sync","directory","guides",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":39},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[134,135,136,22,137,25,138,139,140,141,30,142,143,144,145,146,147,35,148,149],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":39},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[157,158,159,160,161,162,163,164,165,166,167,22,168,28,134,30,169,170],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":188,"publishedAt":39},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[177,180,185],{"categoryNo":178,"categoryName":179,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":181,"categoryName":182,"taxonomyType":183,"taxonomyTypeDesc":184},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":186,"categoryName":187,"taxonomyType":183,"taxonomyTypeDesc":184},"01JBSEEDCAT000000000000033","数据分析师",[189,190,191,192,193,194,195,196,197,30,198,199,200,34,201,202,203,148,204,205],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","browser","api","architecture","project status","http api"]