[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6HRF4HXQ4PZR7G8MPDDKGYG":3,"skill-same:01M6HRF4HXQ4PZR7G8MPDDKGYG":96},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":45,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M6HRF4HXQ4PZR7G8MPDDKGYG","brainstorming",null,"Explore a design with the user when creative choices or unclear goals call for a conversation. Invoke when brainstorming is requested; not a mandatory gate for other work.","edgyarmati\u002Fgedpi","edgyarmati","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F34992044?v=4","01M6HREX1PRWA8ZTSTN261V9TV","Ed Gyarmati","01M6HREX5KXH25QNGMKHC1F9EJ",9,"MIT","https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fbrainstorming\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34],"design","explore","work","user","creative","gate","goals","conversation","call","with","for","2026-11-10 10:12:30",false,"---\nname: brainstorming\ndescription: \"Explore a design with the user when creative choices or unclear goals call for a conversation. Invoke when brainstorming is requested; not a mandatory gate for other work.\"\n---\n\n# Brainstorming\n\nYou are very good at building. You build what you believe your human\npartner wants, and that belief is usually thinner than it feels. This\nskill is for finding out what they actually want, and why, before\nanything gets built.\n\nPeople often haven't finished working out what they want. Good questions\nhelp them think it through. When you understand the why, you make the\nhundred decisions they never mention the way they would have made them.\n\n## First: What Do You Actually Know?\n\nBefore you reply, ask yourself: what do I know about what they want, and\nwhy?\n\n- **Everything that matters is in the request** (\"make the icon cornflower\n  blue\"). This is a quick, clear task. Do it, and say what you did.\n- **Something non-trivial is missing.** Start the conversation.\n\n## Your First Message\n\nYour first message is two things, in this order:\n\n1. One line letting them know that if they'd rather skip the questions and\n   have you just start, they can say so. If they take you up on it, this\n   skill is done: state any significant how-it-gets-made choice\n   (platform, language, medium) in one plain line, then do what they\n   asked using ordinary Pi tools.\n2. One open question that gets them describing. Ask about a real moment\n   or a concrete picture: \"What's the moment you find yourself wishing\n   this existed?\" or \"Tell me about the people who'll be in the room.\"\n\nThat's the whole message.\n\n## The Conversation\n\nEach message ends with one question: a single sentence with no list of\nexample answers hanging off it. Use plain language, pitched just a little\nabove where your human partner is. Match their vocabulary; never use\nprocess jargon.\n\nBe clear and concise. Lead with what matters. Avoid jargon. When you\nreport what you found, give them the most important findings and offer\nthe rest.\n\n**Get them describing.** Open questions come first. Their own words carry\nintent that your options can't. Offer a short menu only when they're\nstuck. When they say \"just guess\" or \"what do you think?\", propose\nsomething concrete.\n\n**How it gets made.** Every project rests on choices about medium, tools,\nmaterials, and resources: the platform, programming language, and\nlibraries for an app; the medium for a piece of art. Find out early which\nof those choices they want to make, which they're handing to you, and what\nthey already have to work with. Someone with strong views or skills will\nwant to talk it through. Someone counting on you needs sensible defaults,\nsaid in plain words. When there's existing work, build on what it already\nuses. Any choice you make goes in the design as your call, never as\nsomething they agreed to.\n\n**Ground to cover.** This is territory, not a script. Never read these\nout as questions:\n\n- what kind of thing this is, and what makes it special\n- why now, and what success looks like to them\n- goals, non-goals, and anti-goals (what would make this a failure even\n  if it technically works)\n- prior art: what they've seen elsewhere, loved or hated\n- current state: what exists now, what they've tried\n- the details they care about\n\n**Questions that work** anchor in specifics: \"Walk me through the last\ntime...\", \"If it could only do one of these well, which?\", \"What would\nmake you wince if I got it wrong?\" A guess they can correct (\"I'm\nguessing this is because X keeps biting you?\") often beats a question.\n\n**Offer recon.** Once you have a bit of grounding and looking would help,\noffer to go look: their codebase or project, their own files and data,\nor the web. Say what you'd look for. They decide whether you go.\n\n**Think wide privately.** Before you propose anything, come up with\nseveral ideas and drop the weak ones, including any that fight what\nthey've told you about why. Show the comparison only when it helps them\ndecide.\n\n**Show, don't tell.** Offer the visual companion (below) whenever seeing\nwould help more than reading:\n\n- something they'll look at: a screen, a page, a printout, a sign\n- a layout or arrangement: of a screen, a room, a schedule\n- a flow or a sequence of steps\n- options that would look different from each other\n- a structure that's easier to see than read: a diagram, a timeline, a map\n\nOnce they've accepted, use it for mockups to react to, side-by-side\noptions, and throwaway prototypes they can click.\n\n**Spike to feel things out.** Agentic work is waterfall, but very, very\nfast. A quick throwaway build is often the cheapest way to learn what\nthey want or whether something works. Offer one when it would help.\nWhen they just want to spike, get out of the way. Spikes get no tests\nor minimal ones, aren't bulletproof, and skip the plan, implementation,\nand review process. Bring what the spike taught you back into the\nconversation.\n\n## Play It Back\n\nPlay back as you go. As soon as you understand one part well enough to\ndescribe it (what it's for and who it serves, say, or how one piece\nbehaves), describe that part back in about 200-300 words, then return to\nquestions about the next part. Playback and questions alternate through\nthe whole conversation; the last chunk covers whatever is left.\n\nMark anything you're guessing as your guess; only what they said goes in\nas theirs. End each chunk by asking what's wrong or missing.\n\nBefore you send a chunk, check it: does it describe something they'll\nlook at, like a page, a screen, a schedule, or a printout? If so, and\nthey haven't seen the visual companion offer yet, send the offer instead\n(its own message, below) and hold the chunk for the next message. Once\nthey've accepted, put a mockup next to the description.\n\n## Size the Work\n\nOnce you understand what they want, pick a size and say it in plain\nwords. They can override it.\n\n| Size | The full description | Then |\n|------|----------------------|------|\n| A quick, clear task | the request itself | do it |\n| A small change | in chat | build it using ordinary Pi tools |\n| A project with a written design | a written design document | a full plan (if the user wants a plan) |\n\nIf it grows mid-task, stop, say so, and step up a size.\n\nIf this is really several independent projects, say so, agree on an\norder, and brainstorm them one at a time.\n\n## The Written Design\n\nFor a project, write a plain document a talented builder in the domain\ncould plan from without going back to your human partner. Cover:\n\n- intent and the why\n- goals, non-goals, anti-goals\n- constraints\n- the parts of the how they decided, as they decided them\n- what's left to the builder\n\n**Where it goes:** in a software repo,\na location the user chooses, or in chat if no file is needed; no commit is required by this skill.\nOtherwise, ask. Your human partner's preferences override both.\n\n**Builder check:** dispatch a fresh subagent with\n`builder-check-prompt.md` in this directory. When you tell your human\npartner you're writing it up, say a reviewer will read it first and you\nmay come back once with a few questions. Don't hand over the document\nuntil the check is back. Sort what the builder asks into three piles:\n\n- **Answered already** by the conversation or the project: put the answer\n  in the document.\n- **Minor:** a sensible builder could settle it without changing what gets\n  built. Settle it yourself and mark it in the document as your call.\n- **Theirs:** only your human partner can answer it, and the answer changes\n  what gets built.\n\nBring the \"theirs\" pile in one message, most important first. Update the\ndocument with their answers, then hand it over with a short list of the\ncalls you made so they can check those while reading. That's the only\nround of questions the check produces. Without a subagent tool, read the\ndocument as that builder yourself.\n\nIf the user wants to proceed, follow their requested next step using ordinary Pi tools. Approval and plan writing are optional, not a global gate.\n\n## Red Flags\n\n| Thought | Reality |\n|---------|---------|\n| \"I'll offer options to save them effort\" | Options steer. Ask them to describe it first. |\n| \"I'll fill in sensible defaults\" | Good. Say them out loud. A default they never heard is one they couldn't reject. |\n| \"I should explain the process first\" | Ask your question. The process shows itself. |\n| \"They said 'sounds good' to the idea\" | Approval covers what you showed them. A description you haven't written isn't approved. |\n| \"The spike works, I'll keep building on it\" | Keeping it is a new request. Back through the gate. |\n\n## Visual Companion\n\nAn optional browser tab for showing mockups, diagrams, and prototypes. If no browser is available, use text diagrams instead. It's a\ntool, not a mode: accepting it doesn't send every question to the\nbrowser.\n\n**Offer it just-in-time.** Offer it the first time one of the moments\nabove comes up, never upfront. The offer is its own message with nothing\nelse in it:\n\n> \"This might be easier if I show you. Want me to open a browser tab with some mockups?\"\n\nIf they decline, stay in text and don't offer again unless they raise it.\n\n**Per question, ask: would they understand this better by seeing it?**\nMockups, layouts, diagrams, and side-by-side designs go in the browser.\nRequirements, scope, tradeoffs, and conceptual choices stay in text. A\nquestion about a UI topic isn't automatically a visual question.\n\nIf they accept, read `visual-companion.md` in this directory before\nstarting the server.\n","# Brainstorming\n\nYou are very good at building. You build what you believe your human\npartner wants, and that belief is usually thinner than it feels. This\nskill is for finding out what they actually want, and why, before\nanything gets built.\n\nPeople often haven't finished working out what they want. Good questions\nhelp them think it through. When you understand the why, you make the\nhundred decisions they never mention the way they would have made them.\n\n## First: What Do You Actually Know?\n\nBefore you reply, ask yourself: what do I know about what they want, and\nwhy?\n\n- **Everything that matters is in the request** (\"make the icon cornflower\n  blue\"). This is a quick, clear task. Do it, and say what you did.\n- **Something non-trivial is missing.** Start the conversation.\n\n## Your First Message\n\nYour first message is two things, in this order:\n\n1. One line letting them know that if they'd rather skip the questions and\n   have you just start, they can say so. If they take you up on it, this\n   skill is done: state any significant how-it-gets-made choice\n   (platform, language, medium) in one plain line, then do what they\n   asked using ordinary Pi tools.\n2. One open question that gets them describing. Ask about a real moment\n   or a concrete picture: \"What's the moment you find yourself wishing\n   this existed?\" or \"Tell me about the people who'll be in the room.\"\n\nThat's the whole message.\n\n## The Conversation\n\nEach message ends with one question: a single sentence with no list of\nexample answers hanging off it. Use plain language, pitched just a little\nabove where your human partner is. Match their vocabulary; never use\nprocess jargon.\n\nBe clear and concise. Lead with what matters. Avoid jargon. When you\nreport what you found, give them the most important findings and offer\nthe rest.\n\n**Get them describing.** Open questions come first. Their own words carry\nintent that your options can't. Offer a short menu only when they're\nstuck. When they say \"just guess\" or \"what do you think?\", propose\nsomething concrete.\n\n**How it gets made.** Every project rests on choices about medium, tools,\nmaterials, and resources: the platform, programming language, and\nlibraries for an app; the medium for a piece of art. Find out early which\nof those choices they want to make, which they're handing to you, and what\nthey already have to work with. Someone with strong views or skills will\nwant to talk it through. Someone counting on you needs sensible defaults,\nsaid in plain words. When there's existing work, build on what it already\nuses. Any choice you make goes in the design as your call, never as\nsomething they agreed to.\n\n**Ground to cover.** This is territory, not a script. Never read these\nout as questions:\n\n- what kind of thing this is, and what makes it special\n- why now, and what success looks like to them\n- goals, non-goals, and anti-goals (what would make this a failure even\n  if it technically works)\n- prior art: what they've seen elsewhere, loved or hated\n- current state: what exists now, what they've tried\n- the details they care about\n\n**Questions that work** anchor in specifics: \"Walk me through the last\ntime...\", \"If it could only do one of these well, which?\", \"What would\nmake you wince if I got it wrong?\" A guess they can correct (\"I'm\nguessing this is because X keeps biting you?\") often beats a question.\n\n**Offer recon.** Once you have a bit of grounding and looking would help,\noffer to go look: their codebase or project, their own files and data,\nor the web. Say what you'd look for. They decide whether you go.\n\n**Think wide privately.** Before you propose anything, come up with\nseveral ideas and drop the weak ones, including any that fight what\nthey've told you about why. Show the comparison only when it helps them\ndecide.\n\n**Show, don't tell.** Offer the visual companion (below) whenever seeing\nwould help more than reading:\n\n- something they'll look at: a screen, a page, a printout, a sign\n- a layout or arrangement: of a screen, a room, a schedule\n- a flow or a sequence of steps\n- options that would look different from each other\n- a structure that's easier to see than read: a diagram, a timeline, a map\n\nOnce they've accepted, use it for mockups to react to, side-by-side\noptions, and throwaway prototypes they can click.\n\n**Spike to feel things out.** Agentic work is waterfall, but very, very\nfast. A quick throwaway build is often the cheapest way to learn what\nthey want or whether something works. Offer one when it would help.\nWhen they just want to spike, get out of the way. Spikes get no tests\nor minimal ones, aren't bulletproof, and skip the plan, implementation,\nand review process. Bring what the spike taught you back into the\nconversation.\n\n## Play It Back\n\nPlay back as you go. As soon as you understand one part well enough to\ndescribe it (what it's for and who it serves, say, or how one piece\nbehaves), describe that part back in about 200-300 words, then return to\nquestions about the next part. Playback and questions alternate through\nthe whole conversation; the last chunk covers whatever is left.\n\nMark anything you're guessing as your guess; only what they said goes in\nas theirs. End each chunk by asking what's wrong or missing.\n\nBefore you send a chunk, check it: does it describe something they'll\nlook at, like a page, a screen, a schedule, or a printout? If so, and\nthey haven't seen the visual companion offer yet, send the offer instead\n(its own message, below) and hold the chunk for the next message. Once\nthey've accepted, put a mockup next to the description.\n\n## Size the Work\n\nOnce you understand what they want, pick a size and say it in plain\nwords. They can override it.\n\n| Size | The full description | Then |\n|------|----------------------|------|\n| A quick, clear task | the request itself | do it |\n| A small change | in chat | build it using ordinary Pi tools |\n| A project with a written design | a written design document | a full plan (if the user wants a plan) |\n\nIf it grows mid-task, stop, say so, and step up a size.\n\nIf this is really several independent projects, say so, agree on an\norder, and brainstorm them one at a time.\n\n## The Written Design\n\nFor a project, write a plain document a talented builder in the domain\ncould plan from without going back to your human partner. Cover:\n\n- intent and the why\n- goals, non-goals, anti-goals\n- constraints\n- the parts of the how they decided, as they decided them\n- what's left to the builder\n\n**Where it goes:** in a software repo,\na location the user chooses, or in chat if no file is needed; no commit is required by this skill.\nOtherwise, ask. Your human partner's preferences override both.\n\n**Builder check:** dispatch a fresh subagent with\n`builder-check-prompt.md` in this directory. When you tell your human\npartner you're writing it up, say a reviewer will read it first and you\nmay come back once with a few questions. Don't hand over the document\nuntil the check is back. Sort what the builder asks into three piles:\n\n- **Answered already** by the conversation or the project: put the answer\n  in the document.\n- **Minor:** a sensible builder could settle it without changing what gets\n  built. Settle it yourself and mark it in the document as your call.\n- **Theirs:** only your human partner can answer it, and the answer changes\n  what gets built.\n\nBring the \"theirs\" pile in one message, most important first. Update the\ndocument with their answers, then hand it over with a short list of the\ncalls you made so they can check those while reading. That's the only\nround of questions the check produces. Without a subagent tool, read the\ndocument as that builder yourself.\n\nIf the user wants to proceed, follow their requested next step using ordinary Pi tools. Approval and plan writing are optional, not a global gate.\n\n## Red Flags\n\n| Thought | Reality |\n|---------|---------|\n| \"I'll offer options to save them effort\" | Options steer. Ask them to describe it first. |\n| \"I'll fill in sensible defaults\" | Good. Say them out loud. A default they never heard is one they couldn't reject. |\n| \"I should explain the process first\" | Ask your question. The process shows itself. |\n| \"They said 'sounds good' to the idea\" | Approval covers what you showed them. A description you haven't written isn't approved. |\n| \"The spike works, I'll keep building on it\" | Keeping it is a new request. Back through the gate. |\n\n## Visual Companion\n\nAn optional browser tab for showing mockups, diagrams, and prototypes. If no browser is available, use text diagrams instead. It's a\ntool, not a mode: accepting it doesn't send every question to the\nbrowser.\n\n**Offer it just-in-time.** Offer it the first time one of the moments\nabove comes up, never upfront. The offer is its own message with nothing\nelse in it:\n\n> \"This might be easier if I show you. Want me to open a browser tab with some mockups?\"\n\nIf they decline, stay in text and don't offer again unless they raise it.\n\n**Per question, ask: would they understand this better by seeing it?**\nMockups, layouts, diagrams, and side-by-side designs go in the browser.\nRequirements, scope, tradeoffs, and conceptual choices stay in text. A\nquestion about a UI topic isn't automatically a visual question.\n\nIf they accept, read `visual-companion.md` in this directory before\nstarting the server.\n",{"name":5,"description":7},"main","f3d53148a165f6122b372fcd92f52b02bd079cac","skills\u002Fbrainstorming",0,"https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi","https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi#readme","https:\u002F\u002Fgithub.com\u002Fedgyarmati","https:\u002F\u002Fgyarmati.dev","AI Solutions Engineer \r\n\r\nData Science Enthusiast & Python Dev\r\n\r\nLancaster University Alumni","2026-10-24 08:10:02",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add edgyarmati\u002Fgedpi --skill brainstorming",{"tool":56,"command":57},"bunx","bunx skills add edgyarmati\u002Fgedpi --skill brainstorming",{"tool":59,"command":60},"pnpm","pnpm dlx skills add edgyarmati\u002Fgedpi --skill brainstorming","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fbrainstorming\u002FSKILL.md",true,[64,70,76,80,84,88,92],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"builder-check-prompt.md","REFERENCE","参考文档",881,"https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fbrainstorming\u002Fbuilder-check-prompt.md",{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"scripts\u002Fframe-template.html","SCRIPT","脚本",8094,"https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fbrainstorming\u002Fscripts\u002Fframe-template.html",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"scripts\u002Fhelper.js",5615,"https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fbrainstorming\u002Fscripts\u002Fhelper.js",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"scripts\u002Fserver.cjs",25699,"https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fbrainstorming\u002Fscripts\u002Fserver.cjs",{"path":85,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":86,"sourceHtmlUrl":87},"scripts\u002Fstart-server.sh",6908,"https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fbrainstorming\u002Fscripts\u002Fstart-server.sh",{"path":89,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":90,"sourceHtmlUrl":91},"scripts\u002Fstop-server.sh",3263,"https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fbrainstorming\u002Fscripts\u002Fstop-server.sh",{"path":93,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":94,"sourceHtmlUrl":95},"visual-companion.md",14312,"https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fbrainstorming\u002Fvisual-companion.md",[97,127,145,162,171,191],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":114,"publishedAt":35},"01M6HRFSJP1SF0T9ZBE8V4HAG6","skill-creator","Create and revise reusable agent skills when the user asks to author or improve a skill. Includes skill structure, writing guidance, and manual review; Claude-only evaluations are unsupported.","https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fskill-creator\u002FSKILL.md",[103,106,109],{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":107,"categoryName":108,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[115,116,117,118,119,120,121,122,123,27,124,125,126],"creator","skill creator","improve","manual","revise","structure","reusable","guidance","only","create","review","writing",{"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":35},"01M6HRFPB6DP4DAT6BSRQEPSP4","grilling","Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.","https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fgrilling\u002FSKILL.md",[],[129,134,135,136,137,138,27,139,140,141,142,143,144],"thinking","stress-test","idea","grill","use","decision","plan","test","about","stress","trigger",{"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":35},"01M6HRFJ8M1BK8HS7ZSPP4CFNK","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\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fgrill-with-docs\u002FSKILL.md",[],[33,137,152,153,154,155,156,157,158,24,159,140,160,161],"grill with docs","docs","which","true","as","glossary","interview","go","sharpen","adr",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":35},"01M6HRFGBAAPHQDTRSMMH1APVN","grill-me","A relentless interview to sharpen a plan or design.","https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fgrill-me\u002FSKILL.md",[],[169,137,170,24,140,160,158,155],"me","grill me",{"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":178,"publishedAt":35},"01M6HRFCCW0HC57MVHHBZ946H7","find-skills","Helps users discover and install agent skills when they ask questions like \"how do I do X\", \"find a skill for X\", \"is there a skill that can...\", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.","https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Ffind-skills\u002FSKILL.md",[177],{"categoryNo":107,"categoryName":108,"taxonomyType":21,"taxonomyTypeDesc":22},[179,180,181,182,183,184,27,185,186,187,188,156,189,190,34],"find","find skills","can","capabilities","how","ask","install","do","discover","express","users","questions",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":35},"01M6HRF90ENGKEQMF1BX841VNW","domain-modeling","Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.","https:\u002F\u002Fgithub.com\u002Fedgyarmati\u002Fgedpi\u002Fblob\u002Fmain\u002Fskills\u002Fdomain-modeling\u002FSKILL.md",[],[198,199,200,201,161,157,126,160,202,203,204,205,206,207,138,208],"domain modeling","modeling","domain","model","recording","codebase","project","domain model","terminology","build","editing"]