[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C69Q97BQRDAV6RZ3K05K2H":3,"skill-same:01M6C69Q97BQRDAV6RZ3K05K2H":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":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":36,"repositoryHtmlUrl":37,"repositoryHomepageUrl":6,"ownerHtmlUrl":38,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":39,"install":40,"resources":53},"01M6C69Q97BQRDAV6RZ3K05K2H","idea-refinement",null,"Refines ideas iteratively. Refine ideas through structured divergent and convergent thinking. Use \"idea-refine\" or \"ideate\" to trigger.","dsj1984\u002Fmandrel","dsj1984","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F20933070?v=4","01M6C69AY3555XWE3QAXETZH6W","01M6C69B26E25DHM9NTPQ7TZQ9",7,"MIT","https:\u002F\u002Fgithub.com\u002Fdsj1984\u002Fmandrel\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcore\u002Fidea-refinement\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27],"idea refinement","idea","refinement","ideate","use","thinking","refine","ideas","structured","trigger","2026-11-10 10:12:30",false,"---\nname: idea-refinement\ndescription:\n  Refines ideas iteratively. Refine ideas through structured divergent and\n  convergent thinking. Use \"idea-refine\" or \"ideate\" to trigger.\n---\n\n# Idea Refine\n\n## Policy Capsule\n\n- Drive the three-phase loop in order: **Understand & Expand → Evaluate & Converge (grill) → Sharpen & Ship**. Never jump straight to Phase 3 output.\n- Phase 1 MUST restate the idea as a \"How Might We\" statement, ask 3–5 sharpening questions via `AskUserQuestion`, and generate 5–8 variations (never 20+ shallow ones) — each carrying a reason it exists, told as a short story, not a bare bullet. Do not proceed until target user and success criteria are explicit.\n- Phase 2 grill loop poses **one** question at a time, each with a recommended answer + one-line rationale grounded in user input \u002F codebase \u002F first principles; never batch questions and never omit the recommendation.\n- Re-enumerate open branches after every grill answer; stop only when no unresolved decisions remain. Take the off-ramp directly to Phase 3 when the idea is already crisply scoped. A branch consciously deferred rather than resolved records its deferral reason.\n- Phase 3 emits a markdown one-pager with the canonical five planning headings exactly: `## Context`, `## Goal`, `## Non-Goals`, `## Scope`, `## Acceptance Criteria` (plus optional `## Open Questions`). No alternate heading text — the `\u002Fmandrel-plan` clarity gate depends on this verbatim.\n- Surface every key assumption inside `## Context` (or `## Scope`); assumptions do not get their own heading. Unresolved decisions MUST NOT carry into the one-pager.\n- The `## Non-Goals` list is mandatory and each entry includes a reason — focus is created by explicit exclusion.\n- Be honest, not supportive: push back on weak ideas with kindness; never function as a yes-machine.\n- Save the one-pager to `docs\u002Fideas\u002F[idea-name].md` **only after** the user explicitly confirms the direction; never write to disk silently.\n- When invoked inside a codebase, ground variations in real files\u002Fpatterns via `Glob` \u002F `Grep` \u002F `Read`; do not invent architecture that ignores existing constraints.\n\n## Activation\n\nInvoked directly by the operator (`idea-refine` \u002F `ideate`), ahead of\nplanning — it is not a step of\n[`\u002Fmandrel-plan`](..\u002F..\u002F..\u002Fworkflows\u002Fmandrel-plan.md), whose Gate #1 stops only\nfor a HITL unknown or a duplicate. The skill sharpens freeform intent into the\ncanonical planning sections, so a saved one-pager feeds\n`\u002Fmandrel-plan \u003Cpath>` (seed-file mode) directly.\n\n## Detailed Instructions\n\nYou are an ideation partner. Your job is to help refine raw ideas into sharp,\nactionable concepts worth building.\n\n### Process\n\nWhen the user invokes this skill with an idea (`$ARGUMENTS`), guide them through\nthree phases. Adapt your approach based on what they say — this is a\nconversation, not a template.\n\n#### Phase 1: Understand & Expand (Divergent)\n\n**Goal:** Take the raw idea and open it up.\n\n1. **Restate the idea** as a crisp \"How Might We\" problem statement. This forces\n   clarity on what's actually being solved.\n\n2. **Ask 3-5 sharpening questions** — no more — via the `AskUserQuestion` tool.\n   Focus on: who this is for specifically, what success looks like, the real\n   constraints (time, tech, resources), what's been tried, and why now. Do NOT\n   proceed until you understand who this is for and what success looks like.\n\n3. **Generate 5-8 idea variations** using lenses that fit the idea — inversion,\n   constraint removal, audience shift, combination, simplification, 10x\n   version, expert lens. Push beyond what the user initially asked for; each\n   variation should have a reason it exists, not just be a bullet point. Don't\n   run every lens mechanically.\n\n**If running inside a codebase:** Use `Glob`, `Grep`, and `Read` to scan for\nrelevant context — existing architecture, patterns, constraints, prior art.\nGround your variations in what actually exists, and reference specific files\nwhen relevant.\n\n#### Phase 2: Evaluate & Converge (Grill)\n\nAfter the user reacts to Phase 1, shift to convergent mode. The job here is not\njust to *list* open questions — it is to **resolve** them, one at a time,\nbefore anything lands in the Phase 3 one-pager.\n\n> **Off-ramp.** Before starting the grill loop, restate the chosen direction in\n> one sentence and check whether any decision branches remain unresolved. If the\n> idea is already crisply scoped — target user clear, MVP boundary obvious, no\n> architectural forks, no hidden assumptions — skip directly to Phase 3. Don't\n> grill trivial ideas for the sake of process.\n\n1. **Cluster** the ideas that resonated into 2-3 distinct directions. Get the\n   user's pick (or a tentative lean) before enumerating branches — the grill\n   loop runs against the *chosen* direction, not the full set.\n\n2. **Enumerate open branches.** List every unresolved decision the chosen\n   direction depends on: user-value branches (who benefits, painkiller vs.\n   vitamin), feasibility branches (cost, hardest part, build vs. buy,\n   sequencing), differentiation branches (why switch), and hidden assumptions\n   (what you're betting is true, what could kill this, what you're ignoring and\n   why that's okay for now). If the list is empty after enumeration, take the\n   off-ramp.\n\n3. **Interrogate sequentially.** For each branch, in priority order\n   (highest-leverage \u002F most blocking first):\n\n   - Pose **one** question at a time. Never batch.\n   - State your **recommended answer** with a one-line rationale grounded in\n     what the user has told you, the codebase if you're inside one, or\n     first-principles reasoning. The recommendation is a forcing function —\n     accepting it should be the easy path; the user pushes back only when they\n     actually disagree.\n   - Use `AskUserQuestion` so the recommendation surfaces as the first option.\n   - **Wait for the response** (accept, modify, or reject) before moving on.\n     Record the resolution inline so it's available when you author Phase 3.\n\n4. **Re-enumerate after each answer.** A resolved branch may collapse other\n   branches (a \"build\" decision moots the \"buy\" follow-ups) or expand the tree\n   (a new constraint surfaces fresh forks). Re-derive the list after each\n   answer and pick the next highest-leverage branch.\n\n5. **Stop condition.** Phase 2 ends when no branches remain unresolved.\n   Resolutions feed the Phase 3 one-pager: confirmed bets land in **Context**\n   with their validation strategy inline; rejected branches become **Non-Goals**\n   entries with the reason; chosen scope becomes the **Scope** section;\n   verifiable outcomes become **Acceptance Criteria**. A branch consciously\n   deferred rather than resolved records the deferral reason.\n\n**Be honest, not supportive.** If an idea is weak, say so with kindness. Push\nback on complexity, question real value, and point out when the emperor has no\nclothes — inside the grill loop, not after the one-pager is written.\n\n> The Phase 2 interrogation discipline is inspired by Matt Pocock's\n> [`grill-me`](https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrill-me\u002FSKILL.md)\n> skill (one question at a time, recommended answer per question, walk the\n> decision tree to resolution).\n\n#### Phase 3: Sharpen & Ship\n\nProduce a markdown one-pager that moves work forward. The five canonical\nheadings below match `.agents\u002Ftemplates\u002Fepic-from-idea.md` and the `\u002Fmandrel-plan`\nclarity gate; emit them verbatim so the renderer can substitute the body into a\n`\u002Fmandrel-plan` Story seed without translation.\n\n```markdown\n# [Idea Name]\n\n## Context\n\n[One-sentence \"How Might We\" framing followed by the current-state pain or\nmotivation in 1-2 short paragraphs. Surface the key assumptions you are betting\non inline — assumptions live here, not in a separate heading.]\n\n## Goal\n\n[The chosen direction and the outcome it produces — 2-3 paragraphs max. Frame in\nterms of the end-state the user reaches, not the implementation path.]\n\n## Non-Goals\n\n- [Thing 1] — [reason]\n- [Thing 2] — [reason]\n\n## Scope\n\n[The minimum version that tests the core assumption. What's in, what's out, and\nhow it sequences into stories.]\n\n## Acceptance Criteria\n\n- [ ] [Verifiable outcome 1 — phrased so a reviewer can check it]\n- [ ] [Verifiable outcome 2]\n\n## Open Questions\n\n- [Question that needs answering before building]\n```\n\n**The \"Non-Goals\" list is arguably the most valuable part.** Focus is about\nsaying no to good ideas. Make the trade-offs explicit.\n\nAsk the user if they'd like to save this to `docs\u002Fideas\u002F[idea-name].md` (or a\nlocation of their choosing). Only save if they confirm.\n","# Idea Refine\n\n## Policy Capsule\n\n- Drive the three-phase loop in order: **Understand & Expand → Evaluate & Converge (grill) → Sharpen & Ship**. Never jump straight to Phase 3 output.\n- Phase 1 MUST restate the idea as a \"How Might We\" statement, ask 3–5 sharpening questions via `AskUserQuestion`, and generate 5–8 variations (never 20+ shallow ones) — each carrying a reason it exists, told as a short story, not a bare bullet. Do not proceed until target user and success criteria are explicit.\n- Phase 2 grill loop poses **one** question at a time, each with a recommended answer + one-line rationale grounded in user input \u002F codebase \u002F first principles; never batch questions and never omit the recommendation.\n- Re-enumerate open branches after every grill answer; stop only when no unresolved decisions remain. Take the off-ramp directly to Phase 3 when the idea is already crisply scoped. A branch consciously deferred rather than resolved records its deferral reason.\n- Phase 3 emits a markdown one-pager with the canonical five planning headings exactly: `## Context`, `## Goal`, `## Non-Goals`, `## Scope`, `## Acceptance Criteria` (plus optional `## Open Questions`). No alternate heading text — the `\u002Fmandrel-plan` clarity gate depends on this verbatim.\n- Surface every key assumption inside `## Context` (or `## Scope`); assumptions do not get their own heading. Unresolved decisions MUST NOT carry into the one-pager.\n- The `## Non-Goals` list is mandatory and each entry includes a reason — focus is created by explicit exclusion.\n- Be honest, not supportive: push back on weak ideas with kindness; never function as a yes-machine.\n- Save the one-pager to `docs\u002Fideas\u002F[idea-name].md` **only after** the user explicitly confirms the direction; never write to disk silently.\n- When invoked inside a codebase, ground variations in real files\u002Fpatterns via `Glob` \u002F `Grep` \u002F `Read`; do not invent architecture that ignores existing constraints.\n\n## Activation\n\nInvoked directly by the operator (`idea-refine` \u002F `ideate`), ahead of\nplanning — it is not a step of\n[`\u002Fmandrel-plan`](..\u002F..\u002F..\u002Fworkflows\u002Fmandrel-plan.md), whose Gate #1 stops only\nfor a HITL unknown or a duplicate. The skill sharpens freeform intent into the\ncanonical planning sections, so a saved one-pager feeds\n`\u002Fmandrel-plan \u003Cpath>` (seed-file mode) directly.\n\n## Detailed Instructions\n\nYou are an ideation partner. Your job is to help refine raw ideas into sharp,\nactionable concepts worth building.\n\n### Process\n\nWhen the user invokes this skill with an idea (`$ARGUMENTS`), guide them through\nthree phases. Adapt your approach based on what they say — this is a\nconversation, not a template.\n\n#### Phase 1: Understand & Expand (Divergent)\n\n**Goal:** Take the raw idea and open it up.\n\n1. **Restate the idea** as a crisp \"How Might We\" problem statement. This forces\n   clarity on what's actually being solved.\n\n2. **Ask 3-5 sharpening questions** — no more — via the `AskUserQuestion` tool.\n   Focus on: who this is for specifically, what success looks like, the real\n   constraints (time, tech, resources), what's been tried, and why now. Do NOT\n   proceed until you understand who this is for and what success looks like.\n\n3. **Generate 5-8 idea variations** using lenses that fit the idea — inversion,\n   constraint removal, audience shift, combination, simplification, 10x\n   version, expert lens. Push beyond what the user initially asked for; each\n   variation should have a reason it exists, not just be a bullet point. Don't\n   run every lens mechanically.\n\n**If running inside a codebase:** Use `Glob`, `Grep`, and `Read` to scan for\nrelevant context — existing architecture, patterns, constraints, prior art.\nGround your variations in what actually exists, and reference specific files\nwhen relevant.\n\n#### Phase 2: Evaluate & Converge (Grill)\n\nAfter the user reacts to Phase 1, shift to convergent mode. The job here is not\njust to *list* open questions — it is to **resolve** them, one at a time,\nbefore anything lands in the Phase 3 one-pager.\n\n> **Off-ramp.** Before starting the grill loop, restate the chosen direction in\n> one sentence and check whether any decision branches remain unresolved. If the\n> idea is already crisply scoped — target user clear, MVP boundary obvious, no\n> architectural forks, no hidden assumptions — skip directly to Phase 3. Don't\n> grill trivial ideas for the sake of process.\n\n1. **Cluster** the ideas that resonated into 2-3 distinct directions. Get the\n   user's pick (or a tentative lean) before enumerating branches — the grill\n   loop runs against the *chosen* direction, not the full set.\n\n2. **Enumerate open branches.** List every unresolved decision the chosen\n   direction depends on: user-value branches (who benefits, painkiller vs.\n   vitamin), feasibility branches (cost, hardest part, build vs. buy,\n   sequencing), differentiation branches (why switch), and hidden assumptions\n   (what you're betting is true, what could kill this, what you're ignoring and\n   why that's okay for now). If the list is empty after enumeration, take the\n   off-ramp.\n\n3. **Interrogate sequentially.** For each branch, in priority order\n   (highest-leverage \u002F most blocking first):\n\n   - Pose **one** question at a time. Never batch.\n   - State your **recommended answer** with a one-line rationale grounded in\n     what the user has told you, the codebase if you're inside one, or\n     first-principles reasoning. The recommendation is a forcing function —\n     accepting it should be the easy path; the user pushes back only when they\n     actually disagree.\n   - Use `AskUserQuestion` so the recommendation surfaces as the first option.\n   - **Wait for the response** (accept, modify, or reject) before moving on.\n     Record the resolution inline so it's available when you author Phase 3.\n\n4. **Re-enumerate after each answer.** A resolved branch may collapse other\n   branches (a \"build\" decision moots the \"buy\" follow-ups) or expand the tree\n   (a new constraint surfaces fresh forks). Re-derive the list after each\n   answer and pick the next highest-leverage branch.\n\n5. **Stop condition.** Phase 2 ends when no branches remain unresolved.\n   Resolutions feed the Phase 3 one-pager: confirmed bets land in **Context**\n   with their validation strategy inline; rejected branches become **Non-Goals**\n   entries with the reason; chosen scope becomes the **Scope** section;\n   verifiable outcomes become **Acceptance Criteria**. A branch consciously\n   deferred rather than resolved records the deferral reason.\n\n**Be honest, not supportive.** If an idea is weak, say so with kindness. Push\nback on complexity, question real value, and point out when the emperor has no\nclothes — inside the grill loop, not after the one-pager is written.\n\n> The Phase 2 interrogation discipline is inspired by Matt Pocock's\n> [`grill-me`](https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fgrill-me\u002FSKILL.md)\n> skill (one question at a time, recommended answer per question, walk the\n> decision tree to resolution).\n\n#### Phase 3: Sharpen & Ship\n\nProduce a markdown one-pager that moves work forward. The five canonical\nheadings below match `.agents\u002Ftemplates\u002Fepic-from-idea.md` and the `\u002Fmandrel-plan`\nclarity gate; emit them verbatim so the renderer can substitute the body into a\n`\u002Fmandrel-plan` Story seed without translation.\n\n```markdown\n# [Idea Name]\n\n## Context\n\n[One-sentence \"How Might We\" framing followed by the current-state pain or\nmotivation in 1-2 short paragraphs. Surface the key assumptions you are betting\non inline — assumptions live here, not in a separate heading.]\n\n## Goal\n\n[The chosen direction and the outcome it produces — 2-3 paragraphs max. Frame in\nterms of the end-state the user reaches, not the implementation path.]\n\n## Non-Goals\n\n- [Thing 1] — [reason]\n- [Thing 2] — [reason]\n\n## Scope\n\n[The minimum version that tests the core assumption. What's in, what's out, and\nhow it sequences into stories.]\n\n## Acceptance Criteria\n\n- [ ] [Verifiable outcome 1 — phrased so a reviewer can check it]\n- [ ] [Verifiable outcome 2]\n\n## Open Questions\n\n- [Question that needs answering before building]\n```\n\n**The \"Non-Goals\" list is arguably the most valuable part.** Focus is about\nsaying no to good ideas. Make the trade-offs explicit.\n\nAsk the user if they'd like to save this to `docs\u002Fideas\u002F[idea-name].md` (or a\nlocation of their choosing). Only save if they confirm.\n",{"name":5,"description":7},"main","1ebd42c768218cb54c92d3dfd25b42c9ec41c85c",".agents\u002Fskills\u002Fcore\u002Fidea-refinement",1,"https:\u002F\u002Fgithub.com\u002Fdsj1984\u002Fmandrel","https:\u002F\u002Fgithub.com\u002Fdsj1984","2026-11-13 20:41:44",{"source":8,"skillName":5,"commands":41,"prompt":51,"zipAvailable":52},[42,45,48],{"tool":43,"command":44},"npx","npx skills add dsj1984\u002Fmandrel --skill idea-refinement",{"tool":46,"command":47},"bunx","bunx skills add dsj1984\u002Fmandrel --skill idea-refinement",{"tool":49,"command":50},"pnpm","pnpm dlx skills add dsj1984\u002Fmandrel --skill idea-refinement","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdsj1984\u002Fmandrel\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcore\u002Fidea-refinement\u002FSKILL.md",true,[54,59,65],{"path":55,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":57,"sourceHtmlUrl":58},"LICENSE","许可证",1068,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fianalloway-crypto-price\u002FLICENSE",{"path":60,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":63,"sourceHtmlUrl":64},"SOURCE.md","REFERENCE","参考文档",347,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fianalloway-crypto-price\u002FSOURCE.md",{"path":66,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":67,"sourceHtmlUrl":68},"TRUST.auto.yaml",2250,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fianalloway-crypto-price\u002FTRUST.auto.yaml",[70,86,124,160,182,203],{"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":28},"01M6C6A5QVWE0AEWJYC362G9BY","no-capsule-skill","Fixture without a Policy Capsule section.","https:\u002F\u002Fgithub.com\u002Fdsj1984\u002Fmandrel\u002Fblob\u002Fmain\u002Ftests\u002Forchestration\u002Ffixtures\u002Fskill-capsule\u002Fno-capsule-skill\u002FSKILL.md",[76],{"categoryNo":77,"categoryName":78,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[82,83,84,85],"no capsule skill","policy","fixture","section",{"skillNo":87,"name":88,"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":96,"publishedAt":28},"01M6C6A2VK7QVY7H5NC6SG89DT","qa-harness","Conventions for agent-driven QA driving — the one driving-conventions reference behind both `\u002Fqa-run` (the known-scenario sweep through a real browser) and `\u002Fqa-explore` (agent-led exploratory driving). Use when instrumenting a live surface — covers navigation-first execution, per-surface console and network capture, design-token visual checks, the `F#` finding shape, per-environment resolution, and static driving as the documented interim. The run procedures live in `.agents\u002Fworkflows\u002Fqa-run.md` and `.agents\u002Fworkflows\u002Fqa-explore.md`; this skill is the conventions reference they lean on.","https:\u002F\u002Fgithub.com\u002Fdsj1984\u002Fmandrel\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fstack\u002Fqa\u002Fqa-harness\u002FSKILL.md",[92,95],{"categoryNo":93,"categoryName":94,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":77,"categoryName":78,"taxonomyType":79,"taxonomyTypeDesc":80},[97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,22,113,114,115,116,117,118,119,120,121,122,123],"qa","harness","qa harness","design","workflows","run","console","browser","network","execution","first","explore","sweep","capture","environment","lean","shape","reference","navigation","real browser","token","live","scenario","as","for","static","when",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":138,"publishedAt":28},"01M6C6A01GDNYJWG3647322JR3","playwright","Robust E2E browser testing with Playwright. Use when writing browser-driven tests — leverage auto-waiting (no `waitForTimeout`), prefer user-visible locators (`getByRole`, `getByText`, `getByLabel`) over CSS\u002FXPath, reuse `storageState` for auth, and enable trace-on-first-retry for CI debugging. Also carries the `data-testid` contract a UI change states in its acceptance criteria.","https:\u002F\u002Fgithub.com\u002Fdsj1984\u002Fmandrel\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fstack\u002Fqa\u002Fplaywright\u002FSKILL.md",[130,133],{"categoryNo":131,"categoryName":132,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":134,"categoryName":135,"taxonomyType":136,"taxonomyTypeDesc":137},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[126,139,140,141,142,143,144,145,104,146,147,148,149,150,107,151,152,22,153,154,155,156,157,158,159,121,123],"testing","writing","css","change","auth","debugging","acceptance","browser testing","ui","ci","data","e2e","trace","user","auto","contract","tests","leverage","reuse","states","retry",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":167,"publishedAt":28},"01M6C69Y3SR8BJ8XRT0E0S6Z4S","playwright-bdd","Wires Gherkin `.feature` files to Playwright via the `playwright-bdd` library. Use when running BDD scenarios on a Playwright runtime — pairs with the `gherkin-authoring` skill (scenario prose) and the `playwright` skill (browser conventions). Drives execution by tag expression with trace-first debugging and Playwright-native sharding.","https:\u002F\u002Fgithub.com\u002Fdsj1984\u002Fmandrel\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fstack\u002Fqa\u002Fplaywright-bdd\u002FSKILL.md",[166],{"categoryNo":131,"categoryName":132,"taxonomyType":79,"taxonomyTypeDesc":80},[126,168,169,144,104,170,106,107,151,22,171,172,173,174,175,176,177,178,179,180,123,181],"bdd","playwright bdd","library","bdd scenarios","files","runtime","feature","authoring","expression","via","native","with","Sharding","running",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":28},"01M6C69VESMZC07ACCXGJ1MQ8W","gherkin-authoring","Authors `.feature` files that stay business-readable, translate cleanly from PRD acceptance criteria, and reuse a shared step-definition library. Use when writing or editing scenarios — the SSOT enforcement rules live in `.agents\u002Frules\u002Fgherkin-standards.md`; this skill shows authors how to apply them.","https:\u002F\u002Fgithub.com\u002Fdsj1984\u002Fmandrel\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fstack\u002Fqa\u002Fgherkin-authoring\u002FSKILL.md",[],[189,175,140,190,145,170,191,192,193,194,195,22,196,197,172,198,199,174,200,157,201,202,123],"gherkin authoring","translate","prd","how","Rules","editing","business","standards","enforcement","acceptance criteria","shared","how to","definition","apply",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":209,"publishedAt":28},"01M6C69RYKQDPM0C1QGJZ8B4ZV","security-and-hardening","Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. The non-negotiable security MUSTs live in `.agents\u002Frules\u002Fsecurity-baseline.md`; this skill shows how to apply them, with the project's surfacing and validation-response process.","https:\u002F\u002Fgithub.com\u002Fdsj1984\u002Fmandrel\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcore\u002Fsecurity-and-hardening\u002FSKILL.md",[],[210,211,212,213,214,215,216,217,149,218,192,219,193,152,220,22,221,222,200,179,202,123],"security","hardening","security and hardening","vulnerabilities","storage","code","authentication","validation","baseline","integrations","process","project","data storage"]