[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JZ4S9EWRDFDVTN8FKJ87M":3,"skill-same:01M71JZ4S9EWRDFDVTN8FKJ87M":67},{"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},"01M71JZ4S9EWRDFDVTN8FKJ87M","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",290,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.trae\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","with","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\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---\n\n# Docs Mode — Full Process\n\nTriggered by \"grill me with docs\" or when a plan depends on a specific library or external API.\n\n**Why this matters:** AI agents hallucinate API methods, argument orders, and behaviors. Every assumption about an external dependency must be validated against the actual docs before code is written.\n\n## Step 1 — Identify the dependencies\n\nFrom the plan or conversation, list:\n- Every external library being used\n- Every third-party API being called\n- Every framework behavior being relied upon\n\nAsk: \"Which of these are you most confident about? Which are you less sure of?\"\n\n## Step 2 — Fetch the relevant docs\n\nFor each dependency, fetch the actual documentation:\n\n```\nWebFetch the official docs for [library\u002FAPI]\n```\n\nPrioritize:\n- The API reference for the specific method being used\n- The changelog for the version in use (breaking changes)\n- Migration guides if upgrading from a previous version\n- Known gotchas \u002F FAQ sections\n\n## Step 3 — Challenge each assumption\n\nFor every assumption in the plan, find the corresponding doc section and ask:\n\n- \"Does the real API actually work this way? Show me the doc.\"\n- \"Is this method available in the version you're using?\"\n- \"Does this argument order match the actual signature?\"\n- \"Are there rate limits, quotas, or timeout behaviors that affect this design?\"\n- \"Is this marked as deprecated in the current version?\"\n\nAsk one question at a time. For each challenge, cite the specific URL and section.\n\n## Step 4 — Surface hallucinations\n\nWhen an assumption doesn't match the docs:\n\n> \"Your plan uses `library.doThing(a, b)` but the [docs](https:\u002F\u002Fexample.com\u002Fapi-reference) show the signature is `doThing(config: {a, b})` with a config object. This will fail at runtime.\"\n\nDocument each discrepancy clearly.\n\n## Step 5 — Update the plan\n\nFor each confirmed discrepancy, recommend a concrete fix:\n- Correct method signature\n- Correct argument order\n- Alternative approach that matches what the library actually supports\n- Whether a spike (`spike-prototype`) is needed to validate a remaining uncertainty\n\n## Step 6 — Sign off\n\nWhen all major assumptions have been validated against docs, report:\n- Which assumptions were confirmed ✓\n- Which were corrected ✗ + what the correct approach is\n- Which remain uncertain → recommend `spike-prototype`\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---\n\n# Docs Mode — Full Process\n\nTriggered by \"grill me with docs\" or when a plan depends on a specific library or external API.\n\n**Why this matters:** AI agents hallucinate API methods, argument orders, and behaviors. Every assumption about an external dependency must be validated against the actual docs before code is written.\n\n## Step 1 — Identify the dependencies\n\nFrom the plan or conversation, list:\n- Every external library being used\n- Every third-party API being called\n- Every framework behavior being relied upon\n\nAsk: \"Which of these are you most confident about? Which are you less sure of?\"\n\n## Step 2 — Fetch the relevant docs\n\nFor each dependency, fetch the actual documentation:\n\n```\nWebFetch the official docs for [library\u002FAPI]\n```\n\nPrioritize:\n- The API reference for the specific method being used\n- The changelog for the version in use (breaking changes)\n- Migration guides if upgrading from a previous version\n- Known gotchas \u002F FAQ sections\n\n## Step 3 — Challenge each assumption\n\nFor every assumption in the plan, find the corresponding doc section and ask:\n\n- \"Does the real API actually work this way? Show me the doc.\"\n- \"Is this method available in the version you're using?\"\n- \"Does this argument order match the actual signature?\"\n- \"Are there rate limits, quotas, or timeout behaviors that affect this design?\"\n- \"Is this marked as deprecated in the current version?\"\n\nAsk one question at a time. For each challenge, cite the specific URL and section.\n\n## Step 4 — Surface hallucinations\n\nWhen an assumption doesn't match the docs:\n\n> \"Your plan uses `library.doThing(a, b)` but the [docs](https:\u002F\u002Fexample.com\u002Fapi-reference) show the signature is `doThing(config: {a, b})` with a config object. This will fail at runtime.\"\n\nDocument each discrepancy clearly.\n\n## Step 5 — Update the plan\n\nFor each confirmed discrepancy, recommend a concrete fix:\n- Correct method signature\n- Correct argument order\n- Alternative approach that matches what the library actually supports\n- Whether a spike (`spike-prototype`) is needed to validate a remaining uncertainty\n\n## Step 6 — Sign off\n\nWhen all major assumptions have been validated against docs, report:\n- Which assumptions were confirmed ✓\n- Which were corrected ✗ + what the correct approach is\n- Which remain uncertain → recommend `spike-prototype`\n",{"name":5,"model":30,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".trae\u002Fskills\u002Fgrill-me",24,"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\u002F.trae\u002Fskills\u002Fgrill-me\u002FSKILL.md",true,[],[68,88,95,122,145,165],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":79,"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",[74],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[80,81,82,83,84,85,86,28,87],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","never",{"skillNo":89,"name":90,"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":91,"categories":92,"keywords":93,"publishedAt":39},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[94,85],"negative path",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":104,"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",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000002","文档处理",[105,106,107,108,109,110,111,112,113,114,25,35,115,116,30,117,118,119,120,121],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","minimal","bold","integrity","organize","sync","directory","guides",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"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",[],[129,130,131,114,132,25,133,134,135,136,30,137,138,139,140,141,142,35,143,144],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"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":151,"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",[],[152,153,154,155,156,157,158,159,160,161,22,114,162,28,129,30,163,164],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","ci pipeline setup","git","workflows",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":182,"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",[171,174,179],{"categoryNo":172,"categoryName":173,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":175,"categoryName":176,"taxonomyType":177,"taxonomyTypeDesc":178},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":180,"categoryName":181,"taxonomyType":177,"taxonomyTypeDesc":178},"01JBSEEDCAT000000000000033","数据分析师",[183,184,185,186,187,188,189,190,191,30,192,193,194,34,195,196,197,143,198,199],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","browser","api","architecture","project status","http api"]