[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CY3PJTJRWS5JWPXQ7ESRED":3,"skill-same:01M6CY3PJTJRWS5JWPXQ7ESRED":69},{"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":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":13,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M6CY3PJTJRWS5JWPXQ7ESRED","grill-with-docs",null,"Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, brainstorm docs, plan docs, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.","The-Rabak\u002Fcompound-engineering-plugin","The-Rabak","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F44833742?v=4","01M6CY211HB58Y8JNWWEV9FGN1","01M6CY2165MYWKS66VN01X82EB",1,"MIT","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fplugins\u002Fcompound-engineering\u002Fskills\u002Fgrill-me\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"grill with docs","docs","grill","project","stress-test","domain model","domain","terminology","language","use","session","user","context","decisions","brainstorm","model","plan","documentation","test","grilling","2026-11-10 10:12:30",false,"---\nname: grill-with-docs\ndescription: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, brainstorm docs, plan docs, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.\n---\n\n\u003Cwhat-to-do>\n\nInterview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.\n\nAsk the questions one at a time, waiting for feedback on each question before continuing.\n\nIf a question can be answered by exploring the codebase, explore the codebase instead.\n\n\u003C\u002Fwhat-to-do>\n\n\u003Csupporting-info>\n\n## Domain awareness\n\nDuring codebase exploration, also look for existing documentation, especially the active feature artifact for the current discussion.\n\n### File structure\n\nMost repos have a repo-wide constitution, a glossary-oriented `CONTEXT.md`, and feature documents under `docs\u002F`:\n\n```\n\u002F\n├── CONSTITUTION.md\n├── CONTEXT.md\n├── docs\u002F\n│   ├── brainstorms\u002F\n│   │   └── 2026-04-30-checkout-race-brainstorm.md\n│   ├── plans\u002F\n│   │   └── 2026-05-01-fix-checkout-race-plan.md\n│   └── architecture\u002F\n│       ├── 2026-04-30-nucleus-stage-1-architecture.md\n└── src\u002F\n```\n\nCreate files lazily -- only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `CONSTITUTION.md` exists, advise the user to create one using the workflows-constitution command using the context from this session.\n\n## During the session\n\n### Choose the right documentation sink\n\nBefore grilling, decide where concrete decisions belong:\n\n1. If a plan file exists for the current feature, or the session is clearly continuing plan work, the plan file is the implementation-decision sink.\n2. Otherwise, if a brainstorm document exists for the current feature, or the session is clearly continuing brainstorm work, the brainstorm document is the implementation-decision sink.\n3. `CONTEXT.md` is only for canonical domain language. ADRs remain for cross-feature decisions that deserve a durable architectural record.\n4. If neither a plan nor a brainstorm artifact exists, do not invent one just for this skill unless the user explicitly asks for it.\n\n### Challenge against the glossary\n\nWhen the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. \"Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?\"\n\n### Sharpen fuzzy language\n\nWhen the user uses vague or overloaded terms, propose a precise canonical term. \"You're saying 'account' — do you mean the Customer or the User? Those are different things.\"\n\n### Discuss concrete scenarios\n\nWhen domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.\n\n### Cross-reference with code\n\nWhen the user states how something works, check whether the code agrees. If you find a contradiction, surface it: \"Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?\"\n\n### Update CONTEXT.md inline\n\nWhen a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](.\u002FCONTEXT-FORMAT.md).\n\n### Update the active feature doc inline\n\nAfter each question is answered with concrete implementation, architecture, data-shape, API, dependency, boundary, rollout, or operational detail, immediately write it into the active feature doc. Do not wait until the end of the session, and do not leave the decision only in chat history.\n\nPrefer updating the most specific existing section over inventing a catch-all notes bucket:\n\n- **Brainstorm doc:** update the Chosen Approach, Key Decisions, and Architectural Context content, and move answered items into Resolved Questions.\n- **Plan doc:** update the Implementation\u002FOverview, Technical Considerations, Architectural Context, and Success Criteria content, and the relevant execution slice, acceptance criteria, or file list when the answer changes execution shape.\n- If a new answer supersedes earlier wording, edit the earlier section in place so the document stays coherent.\n\n`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.\n\n### `grill-with-docs` is the canonical brainstorm mutator (`.md` vs `.html`)\n\nDetect the active feature doc's format by extension before writing -- a brainstorm or plan may now be a legacy `.md` file or the composer's `.html` output (`island-contract.md`).\n\n- **`.md` brainstorm or plan** -- edit the file directly as today: the section updates above (Chosen Approach, Key Decisions, Architectural Context, Resolved Questions, etc.) are literal Markdown edits (legacy path, unchanged).\n- **`.html` brainstorm** -- `grill-with-docs` is the canonical brainstorm mutator: it is the skill that first proves in-place mutation on this artifact kind. A content decision (a rewritten Key Decision, an updated Chosen Approach, a question moved from Open to Resolved) never edits the rendered markup directly -- it routes through `skills\u002Fhtml-artifact-mutator\u002FSKILL.md` (the shared T01 update capability; do not reimplement or re-derive its read\u002Fparse\u002Fmutate\u002Fre-serialize\u002Fre-project pipeline here):\n  1. Load and follow `commands\u002Fworkflows\u002Freferences\u002Fhtml-artifacts\u002Fisland-contract.md` (\"Mutation contract\" section, including the brainstorm-kind Tier-2 core) and the mutator's own `SKILL.md`.\n  2. Build `mutation: { class: \"content\", patch: {...} }` against the brainstorm's `.html` path, supplying the complete new value for each changed top-level field -- e.g. the full `key_decisions[]` array with one entry rewritten, or the full `resolved_questions[]` **and** `open_questions[]` arrays together when a question moves from one to the other (supply both fields' complete new values in the same patch).\n  3. The mutator handles fail-loud extraction, mutable-region validation, and re-serialization; never touch a Tier-1 envelope key (including `render_meta`) from this path.\n  4. Content mutations always re-project. Dispatch **one fresh subagent** with exactly: an instruction to load and follow `skills\u002Fhtml-artifact-composer\u002FSKILL.md` in re-projection mode (point at the file; do not paste the skill body into the prompt), the brainstorm's `target_path`, and the recorded `render_meta` read back from the just-mutated island. The subagent re-renders only the affected section(s), reusing the exact `archetypes`\u002F`design_seed` already recorded -- never reclassifying, never inventing a fact the island doesn't carry. The update is not complete, and must not be reported complete to the user, until this subagent returns the rewritten artifact path.\n- **`.html` plan** -- when the active sink is the plan instead of the brainstorm, the same routing already exists via `\u002Fdeepen-plan`'s `.html`-plan content-enrichment step; `grill-with-docs` only needs to pick the active sink per \"Choose the right documentation sink\" above and hand the same content decision to that existing path.\n\n## Final Handoff: Workflow Next Step Advisor\n\nAfter the grilling session has resolved the current decision branch, updated `CONTEXT.md` for canonical domain language, and updated the active brainstorm or plan with concrete decisions, load the `workflow-next-step` skill.\n\nRun it in advisory mode only:\n- pass the current workflow name: `grill-with-docs`\n- pass `CONTEXT.md`\n- pass the active brainstorm or plan path that was updated\n- inspect relevant artifacts without mutating them\n- output the full core workflow checklist and the exact next-session command with required inputs\n\nThis must be the last phase of the session. If grilling stopped before decisions were resolved, still run the advisor with the current state so it can mark blockers and recommend the recovery step.\n\n\n\u003C\u002Fsupporting-info>\n","\u003Cwhat-to-do>\n\nInterview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.\n\nAsk the questions one at a time, waiting for feedback on each question before continuing.\n\nIf a question can be answered by exploring the codebase, explore the codebase instead.\n\n\u003C\u002Fwhat-to-do>\n\n\u003Csupporting-info>\n\n## Domain awareness\n\nDuring codebase exploration, also look for existing documentation, especially the active feature artifact for the current discussion.\n\n### File structure\n\nMost repos have a repo-wide constitution, a glossary-oriented `CONTEXT.md`, and feature documents under `docs\u002F`:\n\n```\n\u002F\n├── CONSTITUTION.md\n├── CONTEXT.md\n├── docs\u002F\n│   ├── brainstorms\u002F\n│   │   └── 2026-04-30-checkout-race-brainstorm.md\n│   ├── plans\u002F\n│   │   └── 2026-05-01-fix-checkout-race-plan.md\n│   └── architecture\u002F\n│       ├── 2026-04-30-nucleus-stage-1-architecture.md\n└── src\u002F\n```\n\nCreate files lazily -- only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `CONSTITUTION.md` exists, advise the user to create one using the workflows-constitution command using the context from this session.\n\n## During the session\n\n### Choose the right documentation sink\n\nBefore grilling, decide where concrete decisions belong:\n\n1. If a plan file exists for the current feature, or the session is clearly continuing plan work, the plan file is the implementation-decision sink.\n2. Otherwise, if a brainstorm document exists for the current feature, or the session is clearly continuing brainstorm work, the brainstorm document is the implementation-decision sink.\n3. `CONTEXT.md` is only for canonical domain language. ADRs remain for cross-feature decisions that deserve a durable architectural record.\n4. If neither a plan nor a brainstorm artifact exists, do not invent one just for this skill unless the user explicitly asks for it.\n\n### Challenge against the glossary\n\nWhen the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. \"Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?\"\n\n### Sharpen fuzzy language\n\nWhen the user uses vague or overloaded terms, propose a precise canonical term. \"You're saying 'account' — do you mean the Customer or the User? Those are different things.\"\n\n### Discuss concrete scenarios\n\nWhen domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.\n\n### Cross-reference with code\n\nWhen the user states how something works, check whether the code agrees. If you find a contradiction, surface it: \"Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?\"\n\n### Update CONTEXT.md inline\n\nWhen a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](.\u002FCONTEXT-FORMAT.md).\n\n### Update the active feature doc inline\n\nAfter each question is answered with concrete implementation, architecture, data-shape, API, dependency, boundary, rollout, or operational detail, immediately write it into the active feature doc. Do not wait until the end of the session, and do not leave the decision only in chat history.\n\nPrefer updating the most specific existing section over inventing a catch-all notes bucket:\n\n- **Brainstorm doc:** update the Chosen Approach, Key Decisions, and Architectural Context content, and move answered items into Resolved Questions.\n- **Plan doc:** update the Implementation\u002FOverview, Technical Considerations, Architectural Context, and Success Criteria content, and the relevant execution slice, acceptance criteria, or file list when the answer changes execution shape.\n- If a new answer supersedes earlier wording, edit the earlier section in place so the document stays coherent.\n\n`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.\n\n### `grill-with-docs` is the canonical brainstorm mutator (`.md` vs `.html`)\n\nDetect the active feature doc's format by extension before writing -- a brainstorm or plan may now be a legacy `.md` file or the composer's `.html` output (`island-contract.md`).\n\n- **`.md` brainstorm or plan** -- edit the file directly as today: the section updates above (Chosen Approach, Key Decisions, Architectural Context, Resolved Questions, etc.) are literal Markdown edits (legacy path, unchanged).\n- **`.html` brainstorm** -- `grill-with-docs` is the canonical brainstorm mutator: it is the skill that first proves in-place mutation on this artifact kind. A content decision (a rewritten Key Decision, an updated Chosen Approach, a question moved from Open to Resolved) never edits the rendered markup directly -- it routes through `skills\u002Fhtml-artifact-mutator\u002FSKILL.md` (the shared T01 update capability; do not reimplement or re-derive its read\u002Fparse\u002Fmutate\u002Fre-serialize\u002Fre-project pipeline here):\n  1. Load and follow `commands\u002Fworkflows\u002Freferences\u002Fhtml-artifacts\u002Fisland-contract.md` (\"Mutation contract\" section, including the brainstorm-kind Tier-2 core) and the mutator's own `SKILL.md`.\n  2. Build `mutation: { class: \"content\", patch: {...} }` against the brainstorm's `.html` path, supplying the complete new value for each changed top-level field -- e.g. the full `key_decisions[]` array with one entry rewritten, or the full `resolved_questions[]` **and** `open_questions[]` arrays together when a question moves from one to the other (supply both fields' complete new values in the same patch).\n  3. The mutator handles fail-loud extraction, mutable-region validation, and re-serialization; never touch a Tier-1 envelope key (including `render_meta`) from this path.\n  4. Content mutations always re-project. Dispatch **one fresh subagent** with exactly: an instruction to load and follow `skills\u002Fhtml-artifact-composer\u002FSKILL.md` in re-projection mode (point at the file; do not paste the skill body into the prompt), the brainstorm's `target_path`, and the recorded `render_meta` read back from the just-mutated island. The subagent re-renders only the affected section(s), reusing the exact `archetypes`\u002F`design_seed` already recorded -- never reclassifying, never inventing a fact the island doesn't carry. The update is not complete, and must not be reported complete to the user, until this subagent returns the rewritten artifact path.\n- **`.html` plan** -- when the active sink is the plan instead of the brainstorm, the same routing already exists via `\u002Fdeepen-plan`'s `.html`-plan content-enrichment step; `grill-with-docs` only needs to pick the active sink per \"Choose the right documentation sink\" above and hand the same content decision to that existing path.\n\n## Final Handoff: Workflow Next Step Advisor\n\nAfter the grilling session has resolved the current decision branch, updated `CONTEXT.md` for canonical domain language, and updated the active brainstorm or plan with concrete decisions, load the `workflow-next-step` skill.\n\nRun it in advisory mode only:\n- pass the current workflow name: `grill-with-docs`\n- pass `CONTEXT.md`\n- pass the active brainstorm or plan path that was updated\n- inspect relevant artifacts without mutating them\n- output the full core workflow checklist and the exact next-session command with required inputs\n\nThis must be the last phase of the session. If grilling stopped before decisions were resolved, still run the advisor with the current state so it can mark blockers and recommend the recovery step.\n\n\n\u003C\u002Fsupporting-info>\n",{"name":5,"description":7},"main","4c70ff7e10e692dfcc6d7877a6e57dd08df94d9b","plugins\u002Fcompound-engineering\u002Fskills\u002Fgrill-me","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin","https:\u002F\u002Fgithub.com\u002FThe-Rabak","2026-07-28 15:25:35",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add The-Rabak\u002Fcompound-engineering-plugin --skill grill-with-docs",{"tool":55,"command":56},"bunx","bunx skills add The-Rabak\u002Fcompound-engineering-plugin --skill grill-with-docs",{"tool":58,"command":59},"pnpm","pnpm dlx skills add The-Rabak\u002Fcompound-engineering-plugin --skill grill-with-docs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fplugins\u002Fcompound-engineering\u002Fskills\u002Fgrill-me\u002FSKILL.md",true,[63],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"CONTEXT-FORMAT.md","REFERENCE","参考文档",2698,"https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fplugins\u002Fcompound-engineering\u002Fskills\u002Fgrill-me\u002FCONTEXT-FORMAT.md",[70,87,96,105,113,120],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":81,"publishedAt":38},"01M6CY858Z5RCC30TKAVBDJ6SZ","skill-one","Shared reusable skill.","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-portable-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[76],{"categoryNo":77,"categoryName":78,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[82,83,84,85,86],"skill one","shared","reusable","haiku","gpt",{"skillNo":88,"name":72,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":93,"publishedAt":38},"01M6CY843KQG3FQF6259420CCD","Sample skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[92],{"categoryNo":77,"categoryName":78,"taxonomyType":79,"taxonomyTypeDesc":80},[82,94,95],"sample","sample skill",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":103,"publishedAt":38},"01M6CY82607GGPWR5H25SY74H2","disabled-skill","A skill with model invocation disabled","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fdisabled-skill\u002FSKILL.md",[102],{"categoryNo":77,"categoryName":78,"taxonomyType":79,"taxonomyTypeDesc":80},[104,33],"disabled skill",{"skillNo":106,"name":107,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":38},"01M6CY80RWMK81T97A2Q5KAFAF","default-skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fskills\u002Fdefault-skill\u002FSKILL.md",[],[111,112],"default skill","default",{"skillNo":114,"name":115,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":38},"01M6CY7ZK2PMV75ES90W6YYD4S","custom-skill","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fcustom-skills\u002Fcustom-skill\u002FSKILL.md",[],[119],"custom skill",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":127,"publishedAt":38},"01M6CY7V6C7HFCNJEVNFT1X00T","workflow-next-step","This skill should be used at the end of core compound-engineering workflows to inspect completed artifacts, show the workflow progress checklist, and give the exact next-session command with inputs.","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fcompound-engineering-plugin\u002Fblob\u002Fmain\u002Fportable\u002Fcompound-engineering\u002Fskills\u002Fworkflow-next-step\u002FSKILL.md",[126],{"categoryNo":77,"categoryName":78,"taxonomyType":79,"taxonomyTypeDesc":80},[128,129,130,131,132,133,28,134,135,136,137,138],"workflow","next","workflow next step","compound","show","checklist","command","engineering","artifacts","core","workflows"]