[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JPCCC5C36DTH5292FDJHSS":3,"skill-same:01M6JPCCC5C36DTH5292FDJHSS":75},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":14,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6JPCCC5C36DTH5292FDJHSS","brainstorming",null,"Facilitate divergent ideation before committing to a spec — Socratic questioning, widening the option space, challenging assumptions and inherited constraints, then converging on candidates. Triggers: brainstorm, let's explore ideas, what are our options, help me think through, generate ideas, what could we build, not sure what I want, explore approaches, ideate. Once ideas converge, hand off to prd-writing (WHAT\u002FWHY) or feature-planning (breakdown) — this skill opens options; those close them.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Fbrainstorming\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"socratic questioning","writing","converge","hand","sure","close","triggers","feature","ideas","options","me","ideation","brainstorm","option","explore","why","ideate","planning","generate","2026-11-10 10:12:30",false,"---\nname: brainstorming\ndescription: \"Facilitate divergent ideation before committing to a spec — Socratic questioning, widening the option space, challenging assumptions and inherited constraints, then converging on candidates. Triggers: brainstorm, let's explore ideas, what are our options, help me think through, generate ideas, what could we build, not sure what I want, explore approaches, ideate. Once ideas converge, hand off to prd-writing (WHAT\u002FWHY) or feature-planning (breakdown) — this skill opens options; those close them.\"\n---\n\n# Brainstorming\n\nDivergent exploration *before* convergent specification. The most expensive\nfailure in product work is efficiently building the wrong thing — this skill\nexists to widen the option space and test the framing before anything gets\nspecced. It sits upstream of `prd-writing` and `feature-planning`: they converge\non one answer; this skill makes sure the right answers were on the table first.\n\nThe mode is **Socratic**: the user's tacit knowledge of their domain beats any\ngenerated list. Ask questions that surface it; generate to provoke, not to\nreplace their thinking.\n\n## Workflow\n\n### Step 1: Frame the Real Problem\n\nBefore generating anything, ask: what problem, for whom, why now, and what would\n\"solved\" look like? Then challenge the framing — the stated problem is often a\nsolution in disguise (\"we need a dashboard\" usually means \"someone can't answer\na question\"). Ask \"what does that get you?\" until you hit the underlying need.\nIf the user arrives with a solution already chosen, brainstorm the *problem\nbehind it* before brainstorming within it.\n\n### Step 2: Separate Real Constraints from Inherited Ones\n\nList the constraints, then interrogate each: is it physics\u002Fbudget\u002Flaw (real), or\nhabit\u002Fassumption\u002F\"we've always done it this way\" (inherited)? Explicitly mark\nwhich are negotiable. Most breakthrough options live behind a constraint that\nturned out to be assumed.\n\n### Step 3: Diverge — Quantity First, Judgment Deferred\n\nGenerate broadly, and do not evaluate mid-generation — criticism during\ndivergence kills the unusual options that make the exercise worthwhile. Mix\ntechniques rather than exhausting one:\n\n- **Vary the axes**: who else could this serve, what adjacent problem does it\n  solve, how else could it be delivered, when\u002Fwhere else does it apply?\n- **Invert**: how would we guarantee this fails? Each failure mode implies an option.\n- **Analogize**: how do other domains solve the structural equivalent?\n- **Recombine**: force-pair two existing ideas or systems.\n\nAlternate generating with asking — offer a batch, then ask a question that\nmines the user's context for the next batch.\n\n### Step 4: Widen Once More (the Wildcards)\n\nBefore converging, deliberately add the options nobody proposes on their own:\nthe **do-nothing \u002F process-change** option (no build at all), the **1\u002F10-scope**\nversion (what's the smallest thing that dents the problem?), the **10x**\nversion (what if this were the company's main bet?), and the\n**buy-instead-of-build** option (delegate that comparison to `build-vs-buy` if\nit becomes a contender).\n\n### Step 5: Converge with Explicit Criteria\n\nCluster related ideas, then name the selection criteria *before* scoring\n(typical set: impact, effort, reversibility, confidence) — criteria chosen after\nseeing favorites just rationalize them. Score roughly, pick 1–3 candidates, and\nkeep the rest in a **parking lot** with a one-line reason each — parked, not\ndeleted; today's reject is next quarter's answer.\n\n### Step 6: Hand Off\n\nWrite a one-paragraph brief per surviving candidate (problem, idea, why it won,\nopen questions) and route it onward: `prd-writing` for requirements,\n`feature-planning` for task breakdown, `project-proposal` for a business case,\n`architecture-design` if the open questions are structural.\n\n## Principles Applied\n\n- **Defer judgment during divergence; be ruthless during convergence** — mixing\n  the modes does both badly.\n- **Ask > tell**: a question that unlocks the user's knowledge outperforms ten\n  generated ideas.\n- **YAGNI applies at convergence, not divergence** — generating a wild option\n  costs a line; building it is what needs justification.\n\n## Cross-Skill References\n\n- `prd-writing` — turn the winning idea into WHAT\u002FWHY requirements\n- `feature-planning` — break the chosen idea into scoped tasks\n- `project-proposal` — wrap a candidate in a business case for a go\u002Fno-go\n- `build-vs-buy` — when a candidate could be bought or adopted instead of built\n- `architecture-design` — when the surviving questions are structural\n","# Brainstorming\n\nDivergent exploration *before* convergent specification. The most expensive\nfailure in product work is efficiently building the wrong thing — this skill\nexists to widen the option space and test the framing before anything gets\nspecced. It sits upstream of `prd-writing` and `feature-planning`: they converge\non one answer; this skill makes sure the right answers were on the table first.\n\nThe mode is **Socratic**: the user's tacit knowledge of their domain beats any\ngenerated list. Ask questions that surface it; generate to provoke, not to\nreplace their thinking.\n\n## Workflow\n\n### Step 1: Frame the Real Problem\n\nBefore generating anything, ask: what problem, for whom, why now, and what would\n\"solved\" look like? Then challenge the framing — the stated problem is often a\nsolution in disguise (\"we need a dashboard\" usually means \"someone can't answer\na question\"). Ask \"what does that get you?\" until you hit the underlying need.\nIf the user arrives with a solution already chosen, brainstorm the *problem\nbehind it* before brainstorming within it.\n\n### Step 2: Separate Real Constraints from Inherited Ones\n\nList the constraints, then interrogate each: is it physics\u002Fbudget\u002Flaw (real), or\nhabit\u002Fassumption\u002F\"we've always done it this way\" (inherited)? Explicitly mark\nwhich are negotiable. Most breakthrough options live behind a constraint that\nturned out to be assumed.\n\n### Step 3: Diverge — Quantity First, Judgment Deferred\n\nGenerate broadly, and do not evaluate mid-generation — criticism during\ndivergence kills the unusual options that make the exercise worthwhile. Mix\ntechniques rather than exhausting one:\n\n- **Vary the axes**: who else could this serve, what adjacent problem does it\n  solve, how else could it be delivered, when\u002Fwhere else does it apply?\n- **Invert**: how would we guarantee this fails? Each failure mode implies an option.\n- **Analogize**: how do other domains solve the structural equivalent?\n- **Recombine**: force-pair two existing ideas or systems.\n\nAlternate generating with asking — offer a batch, then ask a question that\nmines the user's context for the next batch.\n\n### Step 4: Widen Once More (the Wildcards)\n\nBefore converging, deliberately add the options nobody proposes on their own:\nthe **do-nothing \u002F process-change** option (no build at all), the **1\u002F10-scope**\nversion (what's the smallest thing that dents the problem?), the **10x**\nversion (what if this were the company's main bet?), and the\n**buy-instead-of-build** option (delegate that comparison to `build-vs-buy` if\nit becomes a contender).\n\n### Step 5: Converge with Explicit Criteria\n\nCluster related ideas, then name the selection criteria *before* scoring\n(typical set: impact, effort, reversibility, confidence) — criteria chosen after\nseeing favorites just rationalize them. Score roughly, pick 1–3 candidates, and\nkeep the rest in a **parking lot** with a one-line reason each — parked, not\ndeleted; today's reject is next quarter's answer.\n\n### Step 6: Hand Off\n\nWrite a one-paragraph brief per surviving candidate (problem, idea, why it won,\nopen questions) and route it onward: `prd-writing` for requirements,\n`feature-planning` for task breakdown, `project-proposal` for a business case,\n`architecture-design` if the open questions are structural.\n\n## Principles Applied\n\n- **Defer judgment during divergence; be ruthless during convergence** — mixing\n  the modes does both badly.\n- **Ask > tell**: a question that unlocks the user's knowledge outperforms ten\n  generated ideas.\n- **YAGNI applies at convergence, not divergence** — generating a wild option\n  costs a line; building it is what needs justification.\n\n## Cross-Skill References\n\n- `prd-writing` — turn the winning idea into WHAT\u002FWHY requirements\n- `feature-planning` — break the chosen idea into scoped tasks\n- `project-proposal` — wrap a candidate in a business case for a go\u002Fno-go\n- `build-vs-buy` — when a candidate could be bought or adopted instead of built\n- `architecture-design` — when the surviving questions are structural\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","plugins\u002Fem\u002Fskills\u002Fbrainstorming","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-12 00:14:33",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill brainstorming",{"tool":61,"command":62},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill brainstorming",{"tool":64,"command":65},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill brainstorming","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Fbrainstorming\u002FSKILL.md",true,[69],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"evals\u002Fevals.json","REFERENCE","参考文档",4642,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fem\u002Fskills\u002Fbrainstorming\u002Fevals\u002Fevals.json",[76,116,142,166,199,229],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":97,"publishedAt":43},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[82,85,88,89,94],{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":95,"categoryName":96,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000040","财务",[25,98,99,100,101,102,103,104,105,106,107,108,30,109,110,111,112,113,114,115],"writing skills","testing","eval","write","edit","Budget","authoring","new skill","library","frontmatter","editing","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":123,"publishedAt":43},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[122],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[124,125,126,127,128,129,130,131,132,133,29,134,135,136,137,138,139,140,30,141],"working agreement","project","definition of done","done","milestone","documentation","work","progress","how","contributing","run","sync","status","live","do","README","session","routines",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":149,"publishedAt":43},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[148],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[150,151,152,153,154,155,25,156,127,157,158,159,130,160,29,161,162,163,164,165],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":179,"publishedAt":43},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[172,175,176],{"categoryNo":173,"categoryName":174,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":177,"categoryName":178,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000032","设计师",[180,181,182,183,184,185,186,187,188,189,190,191,132,192,193,194,195,196,197,198],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":209,"publishedAt":43},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[205,206],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":207,"categoryName":208,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000030","开发工程师",[210,211,212,213,214,215,180,216,217,218,219,220,221,222,223,224,225,226,227,228],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","code","review","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":230,"name":231,"nameZh":6,"description":232,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":233,"categories":234,"keywords":240,"publishedAt":43},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[235,236,237,238,239],{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":173,"categoryName":174,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":207,"categoryName":208,"taxonomyType":92,"taxonomyTypeDesc":93},{"categoryNo":177,"categoryName":178,"taxonomyType":92,"taxonomyTypeDesc":93},[180,241,242,243,244,245,99,246,247,156,219,248,249,101,250,251,138,252,253,30],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan","for"]