[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CSASWSVPDAZT5MSXZ5D8FX":3,"skill-same:01M7CSASWSVPDAZT5MSXZ5D8FX":48},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M7CSASWSVPDAZT5MSXZ5D8FX","audience-gate",null,"Use when a delivery request is about to become board tasks and its success depends on how people react to it (new paid or user-facing feature, pricing, onboarding, landing or product copy, positioning) - offer an audience test before opening the work, run it on yes, let the stakeholder revise the plan and re-run to compare, then open the tasks; open them at once whenever the stakeholder says so","makifbaysal\u002Ftasktrooper","makifbaysal","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F25031940?v=4","01M7CRG3ZCSYZSSEVDMW3DEYC8","Mehmet Akif Baysal","01M7CRG401FJ8YAXH5ER730XYV",122,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fproduct-manager\u002Fskills\u002Faudience-gate\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: audience-gate\ncategory: pm\ndescription: Use when a delivery request is about to become board tasks and its success depends on how people react to it (new paid or user-facing feature, pricing, onboarding, landing or product copy, positioning) - offer an audience test before opening the work, run it on yes, let the stakeholder revise the plan and re-run to compare, then open the tasks; open them at once whenever the stakeholder says so\n---\n# Audience gate\n\n## Overview\n\nSome requests are cheap to build and expensive to get wrong with people: a price change, a new paid tier, a reworded landing page, an onboarding step. For those, a synthetic audience study before the first task costs a few model calls and can catch a plan people would reject. The stakeholder decides; you only offer.\n\n**Core principle:** offer the test once, before any task exists. The stakeholder can test, revise and re-test as often as they like, or skip it and open the work at any moment.\n\n## Offer the test when ALL of\n\n- It is a DELIVERY request (build or change something), and\n- Whether it works depends on how users, buyers or visitors react, not on whether the code works. Typical: a new user-facing or paid feature whose demand is unproven, a price or plan change, landing page, onboarding or product copy, positioning or naming, removing or limiting something people use, and\n- An agent runtime is connected (`audience_list` answers; if audience research reports no runtime, skip the offer silently and go on with the board flow).\n\n## Do NOT offer it for\n\n- Bugs, `technical` work, refactors, infra, CI, internal tools, small UI fixes, anything the stakeholder already decided after research.\n- A request the stakeholder framed as \"just build it\", \"skip the test\", \"open the tasks\", or an urgent fix.\n- A plan already tested in this conversation and not changed since.\n- A request whose open question is technical (that is `analiz-gate`, not this).\n\nWhen in doubt, do not offer. An offer on every request becomes noise the stakeholder learns to click away.\n\n## Flow\n\n1. **Offer, before creating anything.** One `ask_user` single-choice question (`allow_multiple: false`), in the stakeholder's language, with one sentence of why (\"this changes what people pay, so a quick synthetic audience test could catch a price they reject\"). Options:\n   - Test it with an audience first (state the rough cost: reuse of an existing audience vs a new build, about N model calls)\n   - Open the tasks now\n   Create no task, no analiz and no design task until they answer.\n2. **\"Open the tasks now\"** → go straight to the normal board flow (`analiz-gate`, `implementation-task-spec`). Do not offer again for this request.\n3. **\"Test it first\"** → run `audience-research` with the request as its subject. Write the brief honestly: the planned change is a plan, not a shipped feature (\"we are considering adding X at Y per month\"), put the plan in the study goal and questions, and pick the kind from what is being decided: `user_interviews` for a feature or price, `landing_page_test` or `message_testing` for copy, `ab_test` for the current page against the proposed one. Every approval step of `audience-research` still applies (build, script, start each need a yes with the call count).\n4. **Report against the request.** When the study is done, present the report as `audience-research` says, then add three things about the plan itself: what in the plan the people supported, what they rejected or missed, and your recommendation in one line (go as planned, change these points first, or do not build). Then ask what they want: revise the plan, open the tasks as they are, or drop it.\n5. **Revise and re-run.** When the stakeholder changes the plan (a price, a step, the copy, a feature cut), restate the revised plan in a few lines, then call `study_rerun` on the finished study with `changes` = the revisions in plain sentences, still framed as a plan. It reuses the same people and script; never rebuild the audience in between. Show the script and the call count and wait for the yes as for any study, then run it.\n6. **Show what moved.** When the re-run is done call `study_compare` and present it: the verdict score before and after, how many people scored higher, lower or the same, the objections that went away and the new ones. Then say plainly whether the change did what the stakeholder wanted it to do (the objection they targeted is gone or not, the score moved or not). The loop repeats from step 5 as often as they want; compare the latest run with the one before it.\n7. **Open the work on their OK.** When the stakeholder is satisfied, open the tasks through the normal board flow for the final plan, not the original one. Carry the evidence in the task's `description` context: the study title (and the re-run's), the verdict before and after, the one or two findings that shaped the plan, labelled as synthetic research. Never write \"audience tested\" or similar as an acceptance criterion.\n\n## Override, at any point\n\nThe stakeholder can stop the gate whenever they want: \"open it anyway\", \"skip the rest\", \"build what I asked\". Then open the tasks at once for the plan they name (the original or the revised one), in this turn. You may say the report's concern in one sentence, once; do not argue, re-offer or ask them to confirm again. Note in the task's `description` that the work was opened against the study's recommendation and which concern it raised, so the team sees it. A study still running is left to finish (or cancelled with `study_cancel` if they ask); it never blocks the tasks.\n\n## Rules\n\n- No task before the stakeholder answers the offer, and no task during the test unless they override.\n- The offer is one question, once per request. Never offer again after \"open the tasks now\".\n- A \"yes, test it\" is not a yes to spend: building, the script and the start each keep their own yes and call count.\n- Never present synthetic findings as customer evidence, and never make the study sound more decisive than it is to win the argument for your recommendation.\n- The final tasks describe the plan as it stands after the last revision; the original plan does not reappear unless the stakeholder chose it.\n\n## Worked example\n\n- \"Add a yearly plan at 99 dollars\" → offer: price and plan change. Yes → `user_interviews` with price points 49, 99, 199 on the reused audience. Report: most say 99 is fine but want a free trial first. Stakeholder: \"add a 14-day trial\" → `study_rerun` with changes \"The yearly plan now starts with a 14-day free trial.\" → `study_compare`: verdict 5.8 → 7.1, the \"no trial\" objection is gone. Stakeholder: \"OK, open it\" → tasks for the yearly plan with the trial, the evidence in the description.\n- \"Fix the crash on the settings page\" → bug, no offer, task straight away.\n- \"Rewrite the landing hero\" → offer. \"No, just open it\" → task now, no second offer.\n","# Audience gate\n\n## Overview\n\nSome requests are cheap to build and expensive to get wrong with people: a price change, a new paid tier, a reworded landing page, an onboarding step. For those, a synthetic audience study before the first task costs a few model calls and can catch a plan people would reject. The stakeholder decides; you only offer.\n\n**Core principle:** offer the test once, before any task exists. The stakeholder can test, revise and re-test as often as they like, or skip it and open the work at any moment.\n\n## Offer the test when ALL of\n\n- It is a DELIVERY request (build or change something), and\n- Whether it works depends on how users, buyers or visitors react, not on whether the code works. Typical: a new user-facing or paid feature whose demand is unproven, a price or plan change, landing page, onboarding or product copy, positioning or naming, removing or limiting something people use, and\n- An agent runtime is connected (`audience_list` answers; if audience research reports no runtime, skip the offer silently and go on with the board flow).\n\n## Do NOT offer it for\n\n- Bugs, `technical` work, refactors, infra, CI, internal tools, small UI fixes, anything the stakeholder already decided after research.\n- A request the stakeholder framed as \"just build it\", \"skip the test\", \"open the tasks\", or an urgent fix.\n- A plan already tested in this conversation and not changed since.\n- A request whose open question is technical (that is `analiz-gate`, not this).\n\nWhen in doubt, do not offer. An offer on every request becomes noise the stakeholder learns to click away.\n\n## Flow\n\n1. **Offer, before creating anything.** One `ask_user` single-choice question (`allow_multiple: false`), in the stakeholder's language, with one sentence of why (\"this changes what people pay, so a quick synthetic audience test could catch a price they reject\"). Options:\n   - Test it with an audience first (state the rough cost: reuse of an existing audience vs a new build, about N model calls)\n   - Open the tasks now\n   Create no task, no analiz and no design task until they answer.\n2. **\"Open the tasks now\"** → go straight to the normal board flow (`analiz-gate`, `implementation-task-spec`). Do not offer again for this request.\n3. **\"Test it first\"** → run `audience-research` with the request as its subject. Write the brief honestly: the planned change is a plan, not a shipped feature (\"we are considering adding X at Y per month\"), put the plan in the study goal and questions, and pick the kind from what is being decided: `user_interviews` for a feature or price, `landing_page_test` or `message_testing` for copy, `ab_test` for the current page against the proposed one. Every approval step of `audience-research` still applies (build, script, start each need a yes with the call count).\n4. **Report against the request.** When the study is done, present the report as `audience-research` says, then add three things about the plan itself: what in the plan the people supported, what they rejected or missed, and your recommendation in one line (go as planned, change these points first, or do not build). Then ask what they want: revise the plan, open the tasks as they are, or drop it.\n5. **Revise and re-run.** When the stakeholder changes the plan (a price, a step, the copy, a feature cut), restate the revised plan in a few lines, then call `study_rerun` on the finished study with `changes` = the revisions in plain sentences, still framed as a plan. It reuses the same people and script; never rebuild the audience in between. Show the script and the call count and wait for the yes as for any study, then run it.\n6. **Show what moved.** When the re-run is done call `study_compare` and present it: the verdict score before and after, how many people scored higher, lower or the same, the objections that went away and the new ones. Then say plainly whether the change did what the stakeholder wanted it to do (the objection they targeted is gone or not, the score moved or not). The loop repeats from step 5 as often as they want; compare the latest run with the one before it.\n7. **Open the work on their OK.** When the stakeholder is satisfied, open the tasks through the normal board flow for the final plan, not the original one. Carry the evidence in the task's `description` context: the study title (and the re-run's), the verdict before and after, the one or two findings that shaped the plan, labelled as synthetic research. Never write \"audience tested\" or similar as an acceptance criterion.\n\n## Override, at any point\n\nThe stakeholder can stop the gate whenever they want: \"open it anyway\", \"skip the rest\", \"build what I asked\". Then open the tasks at once for the plan they name (the original or the revised one), in this turn. You may say the report's concern in one sentence, once; do not argue, re-offer or ask them to confirm again. Note in the task's `description` that the work was opened against the study's recommendation and which concern it raised, so the team sees it. A study still running is left to finish (or cancelled with `study_cancel` if they ask); it never blocks the tasks.\n\n## Rules\n\n- No task before the stakeholder answers the offer, and no task during the test unless they override.\n- The offer is one question, once per request. Never offer again after \"open the tasks now\".\n- A \"yes, test it\" is not a yes to spend: building, the script and the start each keep their own yes and call count.\n- Never present synthetic findings as customer evidence, and never make the study sound more decisive than it is to win the argument for your recommendation.\n- The final tasks describe the plan as it stands after the last revision; the original plan does not reappear unless the stakeholder chose it.\n\n## Worked example\n\n- \"Add a yearly plan at 99 dollars\" → offer: price and plan change. Yes → `user_interviews` with price points 49, 99, 199 on the reused audience. Report: most say 99 is fine but want a free trial first. Stakeholder: \"add a 14-day trial\" → `study_rerun` with changes \"The yearly plan now starts with a 14-day free trial.\" → `study_compare`: verdict 5.8 → 7.1, the \"no trial\" objection is gone. Stakeholder: \"OK, open it\" → tasks for the yearly plan with the trial, the evidence in the description.\n- \"Fix the crash on the settings page\" → bug, no offer, task straight away.\n- \"Rewrite the landing hero\" → offer. \"No, just open it\" → task now, no second offer.\n",{"name":5,"category":24,"description":7},"pm","main","910394a0b6db9fc8c9a8f36328ec421d3ebd8b38","catalog\u002Fagents\u002Fproduct-manager\u002Fskills\u002Faudience-gate",18,"https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper","https:\u002F\u002Ftasktrooper.ai","https:\u002F\u002Fgithub.com\u002Fmakifbaysal","Senior Software Developer","2026-11-15 04:50:29",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add makifbaysal\u002Ftasktrooper --skill audience-gate",{"tool":40,"command":41},"bunx","bunx skills add makifbaysal\u002Ftasktrooper --skill audience-gate",{"tool":43,"command":44},"pnpm","pnpm dlx skills add makifbaysal\u002Ftasktrooper --skill audience-gate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fproduct-manager\u002Fskills\u002Faudience-gate\u002FSKILL.md",true,[],[49,55,62,69,76,83],{"skillNo":50,"name":51,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":52,"categories":53,"keywords":54,"publishedAt":19},"01M7CSVEPQW6J6TD6CS2T5FPNZ","visual-craft","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fvisual-craft\u002FSKILL.md",[],[],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":19},"01M7CSVAQG91ETHQ0HBNZDG5FR","ux-copy","Use when you write any words a user reads in a mockup or a hand-off - content language and voice, buttons, labels, errors, empty states, confirmations, numbers and dates, and the longest-string check","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fux-copy\u002FSKILL.md",[],[],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":19},"01M7CSV6H0J38659NDXHJQ8396","screen-mockup-html","Use when you draw screens as the design task's HTML mockup - ONE canvas document holding every screen and every variant side by side, the sanitizer-safe recipe, phone and wide frames, the states grid, static control states, and the loopback self-check with screenshots at 375, 768 and 1440 attached to the task","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fscreen-mockup-html\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M7CSV3JFRF3BM3XK52M7YEYR","performance-awareness","How the performance score moves for your role. Use when the score context shows a declining trend, or before handing off work you have not self-checked against every criterion.","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fperformance-awareness\u002FSKILL.md",[],[],{"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":82,"publishedAt":19},"01M7CSTZDH00YRF5SCT7BRT9QD","design-variants","Use when a screen design needs variants - how many, variants as side-by-side rows on the one canvas, what makes two variants genuinely different, recommending one, how the human's choice is read, and narrowing to the chosen one in revision","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fdesign-variants\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M7CSTV6P3SM3PAE28DB0RF77","design-system-authoring","Use when you derive, change or extend a design system - where tokens live per stack, the DTCG token tree, role-based names for both themes, base vs layer vs drift, the DESIGN.md section order, the inventory format, the contrast check and the lint every proposal returns","https:\u002F\u002Fgithub.com\u002Fmakifbaysal\u002Ftasktrooper\u002Fblob\u002Fmain\u002Fcatalog\u002Fagents\u002Fui-designer\u002Fskills\u002Fdesign-system-authoring\u002FSKILL.md",[],[]]