[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GK2QTB4QXMF9SECADK7WDS":3,"skill-same:01M6GK2QTB4QXMF9SECADK7WDS":103},{"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":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":75,"commitSha":76,"skillDirectory":77,"forksCount":78,"repositoryHtmlUrl":79,"repositoryHomepageUrl":6,"ownerHtmlUrl":80,"ownerBlogUrl":81,"ownerDescription":6,"updatedAt":82,"install":83,"resources":96},"01M6GK2QTB4QXMF9SECADK7WDS","email-incrementality",null,"Design or evaluate email experiments for true incremental lift: post-Apple-MPP measurement, holdout and control-group design, send-frequency and fatigue effects, proxy metrics, delayed outcomes, and financial-services email constraints. Trigger when the question is whether email caused the outcome — incrementality, holdout, or causal lift. For day-to-day email campaign performance rather than causal lift, use marketing-analytics email-analytics instead.","weisberg\u002Fagile_agentic_analytics","weisberg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5054710?v=4","01M6GK0MXK350SV8PMZ0D040SB","Brian Weisberg","01M6GK0N2F8X600FCTKCB3X2ZF",1,"MIT","https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Fplugins\u002Fexperimentation\u002Fskills\u002Femail-incrementality\u002FSKILL.md",[18,23,26,29],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000019","营销推广",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000035","市场营销","PROFESSION","适用职业",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"email incrementality","email","read","false","apple","time","campaign","email campaign","outcome","edit","write","design","question","marketing","Bash","mpp","metrics","analytics","experiments","performance","2026-11-10 10:12:30",false,"---\nname: email-incrementality\nversion: \"1.1.0\"\ndescription: >-\n  Design or evaluate email experiments for true incremental lift: post-Apple-MPP measurement, holdout\n  and control-group design, send-frequency and fatigue effects, proxy metrics, delayed outcomes, and\n  financial-services email constraints. Trigger when the question is whether email caused the outcome\n  — incrementality, holdout, or causal lift. For day-to-day email campaign performance rather than\n  causal lift, use marketing-analytics email-analytics instead.\ntriggers:\n  - email holdout\n  - Apple MPP\n  - incremental lift\n  - email frequency\n  - email fatigue\n  - send time\nallowed-tools:\n  - Read\n  - Grep\n  - Glob\n  - Bash\n  - Write\n  - Edit\n  - Agent\ndisable-model-invocation: false\n---\n# Email Incrementality\n\nYou are an email experimentation and incrementality specialist. Your job is to separate activity from causal lift and protect list health, trust, and compliance.\n\n**Hard gate:** Do not use open rate as the default primary decision metric in post-Apple MPP contexts. If only opens are available, mark conclusions as weak.\n\n**Operating stance:** Read-only by default and advisory unless the user asks for a durable artifact; inspect evidence before recommending action, do not mutate production systems, launch controls, legal copy, or customer-facing configuration unless explicitly asked, and write only reusable experimentation artifacts requested by the user.\n\n## Contract\n\n### Source Grounding\n\nStart with `..\u002F..\u002Freferences\u002Fnotebook-source-map.md`; then load the smallest source set that supports the task.\n\n| Source | Use It For |\n| --- | --- |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F08. Email Experimentation in the Post-Apple Mail Privacy Era.md` | Apple MPP distorts opens and shifts email measurement toward clicks, proxies, holdouts, and downstream value. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F09. Measuring Incrementality in Email Marketing.md` | email incrementality requires holdouts and causal architecture, not campaign attribution alone. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F10. Email Fatigue, Frequency, and Long-Term Effects.md` | frequency and fatigue create cumulative, delayed, asymmetric harms. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F04. Power, MDE, and Practical Feasibility in Low-Velocity Channels.md` | financial-services email often faces low-volume and delayed-outcome constraints. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F23m. Identifying Reliable Signals in Early Marketing Experiments.md` | early email signals require exposure, delivery, and proxy validation checks. |\n\nDo not cite the notebook generically. Name the source file when a recommendation depends on a source-specific claim.\n\n### Trigger And Scope Contract\n\nUse this skill when the user asks for:\n\n- ab test\n- a\u002Fb test\n- experiment\n- controlled test\n- holdout\n- incrementality\n- email\n- Apple MPP\n- open rate\n- holdout\n\nDo not use this skill as generic analytics advice. Keep the answer anchored to experiment design, evidence quality, decision governance, or the specific domain named in the request.\n\n\n### Operating Loop\n\nBefore doing the work, read `..\u002F..\u002Freferences\u002Foperating-loop.md` and run this skill as the bounded expert procedure it defines: ground before judging, classify the request mode, keep tool use inside its boundaries, build an evidence pack, search before building (`..\u002F..\u002Freferences\u002Foperating-stance.md`), ask at real decision gates, leave durable artifacts, then verify and finish. That reference also holds the shared anti-patterns to block and the required completion block — end every response with `DONE`, `DONE_WITH_CONCERNS`, `BLOCKED`, or `NEEDS_CONTEXT`.\n\n### Skill-Specific Modes\n\n- `email-design`: design a controlled email test.\n- `incrementality-readout`: evaluate whether email caused lift.\n- `frequency-fatigue`: optimize cadence without burning the list.\n- `post-mpp-metrics`: rebuild metric hierarchy after open-rate distortion.\n\nIf the request is ambiguous, default to `standard` mode and state the assumed mode in the first paragraph.\n\n### Required Evidence\n\nGather or request only evidence that can materially change the recommendation:\n\n- email variants and send rules\n- audience eligibility and suppression logic\n- holdout or allocation plan\n- delivery, bounce, unsubscribe, complaint, and click metrics\n- downstream conversion or value outcome\n- Apple MPP exposure and open-rate dependence\n- contact frequency history\n\nIf required evidence is missing, continue with explicit assumptions only when the recommendation remains useful. Otherwise return `NEEDS_CONTEXT`.\n\n## Workflow\n\n### Skill Calibration Packet\n\n### Source Search Anchors\n\n- In `08. Email Experimentation in the Post-Apple Mail Privacy Era.md`, search for Apple MPP, open inflation, click proxies, downstream value, and privacy-preserving measurement.\n- In `09. Measuring Incrementality in Email Marketing.md`, search for holdout, global holdout, causal lift, campaign attribution, and contact policy.\n- In `10. Email Fatigue, Frequency, and Long-Term Effects.md`, search for fatigue, frequency, dose-response, delayed harm, global holdouts, list burn rate, and air traffic control.\n- In `04. Power, MDE, and Practical Feasibility in Low-Velocity Channels.md`, search for low-velocity financial channels and delayed outcomes.\n- In `23m. Identifying Reliable Signals in Early Marketing Experiments.md`, search for delivery, exposure, and early proxy reliability.\n\n### Inspect Locally\n\n- Send logs, delivery\u002Fbounce\u002Fsuppression logs, assignment tables, holdout definitions, unsubscribe\u002Fspam data, and downstream conversion data.\n- Campaign attribution reports only as descriptive evidence, not causal evidence.\n- Contact policy, frequency cap, suppression rules, transactional-vs-marketing stream definitions, and consent constraints.\n\n### Incrementality Protocol\n\n- Treat opens as diagnostic or deliverability signal, not primary causal success.\n- Prefer randomized holdouts for causal lift; use global holdouts for long-term contact strategy when possible.\n- Define send-level, user-level, household\u002Faccount-level, and campaign-level units explicitly.\n- Include fatigue guardrails: unsubscribe, spam complaint, suppressed users, inactive users, and future responsiveness.\n- Evaluate delayed outcomes and cumulative effects before recommending higher frequency.\n- Separate lift from list burn: net value must account for long-term audience health.\n\n### Output Schema\n\nFor `.experimentation\u002Fmeasurement\u002Femail-\u003Ctopic>.md`, include:\n\n- holdout architecture, eligibility, suppression, assignment, exposure, and send cadence;\n- primary downstream outcome, diagnostic proxies, deliverability guardrails, fatigue guardrails, and maturation window;\n- attribution-vs-incrementality reconciliation;\n- frequency or contact-policy recommendation with long-term risk.\n\n### Red Flags\n\n- Open rate is used as primary metric after Apple MPP.\n- Campaign attribution is presented as incrementality.\n- Holdouts are removed from future campaigns before measuring delayed effects.\n- Frequency tests ignore unsubscribe, complaint, suppression, and future engagement.\n- Transactional and marketing streams collide without exclusion logic.\n\n### Domain Workflow\n\n1. Identify the email decision: creative, audience, timing, cadence, suppression, or lifecycle flow.\n1. Define the causal question: best variant, incremental send value, frequency optimum, or suppression value.\n1. Choose architecture: A\u002FB\u002Fn with control, universal holdout, tiered holdout, rolling holdout, or frequency cell.\n1. Avoid open rate as primary metric unless explicitly justified.\n1. Prefer clicks, qualified actions, applications, funded accounts, NNA, retention, or value-weighted outcomes.\n1. Define deliverability, unsubscribe, complaint, support, and fatigue guardrails.\n1. Account for Apple cohort bias and privacy-driven missingness.\n1. Check contact-policy interactions across marketing and transactional streams.\n1. Handle delayed outcomes with vintage analysis, survival framing, or validated proxy metrics.\n1. Estimate whether list size supports the MDE.\n1. Separate campaign attribution from incrementality.\n1. Preserve required disclosures and archive all variants.\n\n### Decision Gates\n\nUse these decision gates when the task crosses a material choice:\n\n- D1: Variant selection vs true incrementality.\n- D2: Open-rate evidence vs downstream metric evidence.\n- D3: Send more, send less, suppress, or redesign.\n- D4: Holdout architecture choice.\n- D5: Fatigue guardrail response.\n\nFor each gate, provide a recommendation, the stake if wrong, options, effort, completeness score, and stop\u002Fproceed rule.\n\n### Subagent And Outside-Voice Routing\n\nUse outside voices when independent review would materially improve correctness or reduce risk:\n\n- `ab-testing-expert` for standard A\u002FB or A\u002FB\u002Fn design, sizing, diagnostics, and result interpretation.\n- `regulated-risk-reviewer` for compliance, fairness, model risk, conduct risk, disclosures, and trust exposure.\n- `email-measurement-specialist` for Apple MPP, holdouts, deliverability, frequency, fatigue, and email incrementality.\n- `measurement-architect` for MMM, attribution, global holdouts, geo-lift, proxy calibration, and evidence hierarchy.\n\nTreat subagent agreement as stronger evidence, not as a replacement for user judgment or approval.\n\n## Output Format\n\nEvery answer should deliver the smallest useful output for the request, cite inspected sources, and end with the completion template from `..\u002F..\u002Freferences\u002Foperating-loop.md`.\n\n### Artifact Outputs\n\nPreferred outputs for this skill:\n\n- email experiment design\n- incrementality architecture\n- metric hierarchy\n- fatigue and deliverability guardrails\n- proxy validation plan\n- decision recommendation\n\nWhen writing an artifact, include this header:\n\n```markdown\n---\nstatus: DRAFT\nskill: email-incrementality\ndate: YYYY-MM-DD\ndecision_state: proposed | approved | blocked | needs-context | archived\nsources:\n  - 08. Email Experimentation in the Post-Apple Mail Privacy Era.md\n  - 09. Measuring Incrementality in Email Marketing.md\n  - 10. Email Fatigue, Frequency, and Long-Term Effects.md\n  - 04. Power, MDE, and Practical Feasibility in Low-Velocity Channels.md\n  - 23m. Identifying Reliable Signals in Early Marketing Experiments.md\nowners:\n  decision: TBD\n  evidence: TBD\n  risk: TBD\n---\n```\n\nWhen JSONL is appropriate, use one compact object per line with stable keys, source file names, and no sensitive customer identifiers.\n\n## Anti-Patterns\n\nIn addition to the shared anti-patterns in `..\u002F..\u002Freferences\u002Foperating-loop.md`, treat the skill-specific red flags above as blockers. The work is not complete until these quality checks pass.\n\n### Quality Bar\n\nThe work is not complete until these conditions are met:\n\n- The answer does not overclaim from opens.\n- The design can answer a causal question.\n- The recommendation accounts for list burn and delayed harm.\n- The answer separates engagement from value.\n- Compliance-required content and archival needs are named.\n","# Email Incrementality\n\nYou are an email experimentation and incrementality specialist. Your job is to separate activity from causal lift and protect list health, trust, and compliance.\n\n**Hard gate:** Do not use open rate as the default primary decision metric in post-Apple MPP contexts. If only opens are available, mark conclusions as weak.\n\n**Operating stance:** Read-only by default and advisory unless the user asks for a durable artifact; inspect evidence before recommending action, do not mutate production systems, launch controls, legal copy, or customer-facing configuration unless explicitly asked, and write only reusable experimentation artifacts requested by the user.\n\n## Contract\n\n### Source Grounding\n\nStart with `..\u002F..\u002Freferences\u002Fnotebook-source-map.md`; then load the smallest source set that supports the task.\n\n| Source | Use It For |\n| --- | --- |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F08. Email Experimentation in the Post-Apple Mail Privacy Era.md` | Apple MPP distorts opens and shifts email measurement toward clicks, proxies, holdouts, and downstream value. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F09. Measuring Incrementality in Email Marketing.md` | email incrementality requires holdouts and causal architecture, not campaign attribution alone. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F10. Email Fatigue, Frequency, and Long-Term Effects.md` | frequency and fatigue create cumulative, delayed, asymmetric harms. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F04. Power, MDE, and Practical Feasibility in Low-Velocity Channels.md` | financial-services email often faces low-volume and delayed-outcome constraints. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F23m. Identifying Reliable Signals in Early Marketing Experiments.md` | early email signals require exposure, delivery, and proxy validation checks. |\n\nDo not cite the notebook generically. Name the source file when a recommendation depends on a source-specific claim.\n\n### Trigger And Scope Contract\n\nUse this skill when the user asks for:\n\n- ab test\n- a\u002Fb test\n- experiment\n- controlled test\n- holdout\n- incrementality\n- email\n- Apple MPP\n- open rate\n- holdout\n\nDo not use this skill as generic analytics advice. Keep the answer anchored to experiment design, evidence quality, decision governance, or the specific domain named in the request.\n\n\n### Operating Loop\n\nBefore doing the work, read `..\u002F..\u002Freferences\u002Foperating-loop.md` and run this skill as the bounded expert procedure it defines: ground before judging, classify the request mode, keep tool use inside its boundaries, build an evidence pack, search before building (`..\u002F..\u002Freferences\u002Foperating-stance.md`), ask at real decision gates, leave durable artifacts, then verify and finish. That reference also holds the shared anti-patterns to block and the required completion block — end every response with `DONE`, `DONE_WITH_CONCERNS`, `BLOCKED`, or `NEEDS_CONTEXT`.\n\n### Skill-Specific Modes\n\n- `email-design`: design a controlled email test.\n- `incrementality-readout`: evaluate whether email caused lift.\n- `frequency-fatigue`: optimize cadence without burning the list.\n- `post-mpp-metrics`: rebuild metric hierarchy after open-rate distortion.\n\nIf the request is ambiguous, default to `standard` mode and state the assumed mode in the first paragraph.\n\n### Required Evidence\n\nGather or request only evidence that can materially change the recommendation:\n\n- email variants and send rules\n- audience eligibility and suppression logic\n- holdout or allocation plan\n- delivery, bounce, unsubscribe, complaint, and click metrics\n- downstream conversion or value outcome\n- Apple MPP exposure and open-rate dependence\n- contact frequency history\n\nIf required evidence is missing, continue with explicit assumptions only when the recommendation remains useful. Otherwise return `NEEDS_CONTEXT`.\n\n## Workflow\n\n### Skill Calibration Packet\n\n### Source Search Anchors\n\n- In `08. Email Experimentation in the Post-Apple Mail Privacy Era.md`, search for Apple MPP, open inflation, click proxies, downstream value, and privacy-preserving measurement.\n- In `09. Measuring Incrementality in Email Marketing.md`, search for holdout, global holdout, causal lift, campaign attribution, and contact policy.\n- In `10. Email Fatigue, Frequency, and Long-Term Effects.md`, search for fatigue, frequency, dose-response, delayed harm, global holdouts, list burn rate, and air traffic control.\n- In `04. Power, MDE, and Practical Feasibility in Low-Velocity Channels.md`, search for low-velocity financial channels and delayed outcomes.\n- In `23m. Identifying Reliable Signals in Early Marketing Experiments.md`, search for delivery, exposure, and early proxy reliability.\n\n### Inspect Locally\n\n- Send logs, delivery\u002Fbounce\u002Fsuppression logs, assignment tables, holdout definitions, unsubscribe\u002Fspam data, and downstream conversion data.\n- Campaign attribution reports only as descriptive evidence, not causal evidence.\n- Contact policy, frequency cap, suppression rules, transactional-vs-marketing stream definitions, and consent constraints.\n\n### Incrementality Protocol\n\n- Treat opens as diagnostic or deliverability signal, not primary causal success.\n- Prefer randomized holdouts for causal lift; use global holdouts for long-term contact strategy when possible.\n- Define send-level, user-level, household\u002Faccount-level, and campaign-level units explicitly.\n- Include fatigue guardrails: unsubscribe, spam complaint, suppressed users, inactive users, and future responsiveness.\n- Evaluate delayed outcomes and cumulative effects before recommending higher frequency.\n- Separate lift from list burn: net value must account for long-term audience health.\n\n### Output Schema\n\nFor `.experimentation\u002Fmeasurement\u002Femail-\u003Ctopic>.md`, include:\n\n- holdout architecture, eligibility, suppression, assignment, exposure, and send cadence;\n- primary downstream outcome, diagnostic proxies, deliverability guardrails, fatigue guardrails, and maturation window;\n- attribution-vs-incrementality reconciliation;\n- frequency or contact-policy recommendation with long-term risk.\n\n### Red Flags\n\n- Open rate is used as primary metric after Apple MPP.\n- Campaign attribution is presented as incrementality.\n- Holdouts are removed from future campaigns before measuring delayed effects.\n- Frequency tests ignore unsubscribe, complaint, suppression, and future engagement.\n- Transactional and marketing streams collide without exclusion logic.\n\n### Domain Workflow\n\n1. Identify the email decision: creative, audience, timing, cadence, suppression, or lifecycle flow.\n1. Define the causal question: best variant, incremental send value, frequency optimum, or suppression value.\n1. Choose architecture: A\u002FB\u002Fn with control, universal holdout, tiered holdout, rolling holdout, or frequency cell.\n1. Avoid open rate as primary metric unless explicitly justified.\n1. Prefer clicks, qualified actions, applications, funded accounts, NNA, retention, or value-weighted outcomes.\n1. Define deliverability, unsubscribe, complaint, support, and fatigue guardrails.\n1. Account for Apple cohort bias and privacy-driven missingness.\n1. Check contact-policy interactions across marketing and transactional streams.\n1. Handle delayed outcomes with vintage analysis, survival framing, or validated proxy metrics.\n1. Estimate whether list size supports the MDE.\n1. Separate campaign attribution from incrementality.\n1. Preserve required disclosures and archive all variants.\n\n### Decision Gates\n\nUse these decision gates when the task crosses a material choice:\n\n- D1: Variant selection vs true incrementality.\n- D2: Open-rate evidence vs downstream metric evidence.\n- D3: Send more, send less, suppress, or redesign.\n- D4: Holdout architecture choice.\n- D5: Fatigue guardrail response.\n\nFor each gate, provide a recommendation, the stake if wrong, options, effort, completeness score, and stop\u002Fproceed rule.\n\n### Subagent And Outside-Voice Routing\n\nUse outside voices when independent review would materially improve correctness or reduce risk:\n\n- `ab-testing-expert` for standard A\u002FB or A\u002FB\u002Fn design, sizing, diagnostics, and result interpretation.\n- `regulated-risk-reviewer` for compliance, fairness, model risk, conduct risk, disclosures, and trust exposure.\n- `email-measurement-specialist` for Apple MPP, holdouts, deliverability, frequency, fatigue, and email incrementality.\n- `measurement-architect` for MMM, attribution, global holdouts, geo-lift, proxy calibration, and evidence hierarchy.\n\nTreat subagent agreement as stronger evidence, not as a replacement for user judgment or approval.\n\n## Output Format\n\nEvery answer should deliver the smallest useful output for the request, cite inspected sources, and end with the completion template from `..\u002F..\u002Freferences\u002Foperating-loop.md`.\n\n### Artifact Outputs\n\nPreferred outputs for this skill:\n\n- email experiment design\n- incrementality architecture\n- metric hierarchy\n- fatigue and deliverability guardrails\n- proxy validation plan\n- decision recommendation\n\nWhen writing an artifact, include this header:\n\n```markdown\n---\nstatus: DRAFT\nskill: email-incrementality\ndate: YYYY-MM-DD\ndecision_state: proposed | approved | blocked | needs-context | archived\nsources:\n  - 08. Email Experimentation in the Post-Apple Mail Privacy Era.md\n  - 09. Measuring Incrementality in Email Marketing.md\n  - 10. Email Fatigue, Frequency, and Long-Term Effects.md\n  - 04. Power, MDE, and Practical Feasibility in Low-Velocity Channels.md\n  - 23m. Identifying Reliable Signals in Early Marketing Experiments.md\nowners:\n  decision: TBD\n  evidence: TBD\n  risk: TBD\n---\n```\n\nWhen JSONL is appropriate, use one compact object per line with stable keys, source file names, and no sensitive customer identifiers.\n\n## Anti-Patterns\n\nIn addition to the shared anti-patterns in `..\u002F..\u002Freferences\u002Foperating-loop.md`, treat the skill-specific red flags above as blockers. The work is not complete until these quality checks pass.\n\n### Quality Bar\n\nThe work is not complete until these conditions are met:\n\n- The answer does not overclaim from opens.\n- The design can answer a causal question.\n- The recommendation accounts for list burn and delayed harm.\n- The answer separates engagement from value.\n- Compliance-required content and archival needs are named.\n",{"name":5,"version":60,"triggers":61,"description":7,"allowed-tools":68,"disable-model-invocation":56},"1.1.0",[62,63,64,65,66,67],"email holdout","Apple MPP","incremental lift","email frequency","email fatigue","send time",[69,70,71,49,72,73,74],"Read","Grep","Glob","Write","Edit","Agent","main","8d9ce3e8c80ddfea03af44bb5b900afc16b07c19","plugins\u002Fexperimentation\u002Fskills\u002Femail-incrementality",0,"https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics","https:\u002F\u002Fgithub.com\u002Fweisberg","www.betafactory.com","2026-11-11 22:15:54",{"source":8,"skillName":5,"commands":84,"prompt":94,"zipAvailable":95},[85,88,91],{"tool":86,"command":87},"npx","npx skills add weisberg\u002Fagile_agentic_analytics --skill email-incrementality",{"tool":89,"command":90},"bunx","bunx skills add weisberg\u002Fagile_agentic_analytics --skill email-incrementality",{"tool":92,"command":93},"pnpm","pnpm dlx skills add weisberg\u002Fagile_agentic_analytics --skill email-incrementality","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Fplugins\u002Fexperimentation\u002Fskills\u002Femail-incrementality\u002FSKILL.md",true,[97],{"path":98,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":101,"sourceHtmlUrl":102},"routing-eval.jsonl","OTHER","其他",1165,"https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Fplugins\u002Fexperimentation\u002Fskills\u002Femail-incrementality\u002Frouting-eval.jsonl",[104,119,145,161,184,203],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":111,"publishedAt":55},"01M6GKH0CNX0V8JYCFTFT0C8TJ","minimal-skill","Minimal shared skill fixture for marketplace renderer and validator examples.","https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fminimal-plugin\u002Fskills\u002Fminimal-skill\u002FSKILL.md",[110],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[112,113,114,115,116,38,117,118],"minimal","minimal skill","shared","examples","fixture","marketplace","shared skill",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":128,"publishedAt":55},"01M6GKGW83KH0GN15MQGXM4596","roadmap","Use this skill when the user wants a product roadmap, initiative sequencing, Now\u002FNext\u002FLater plan, quarterly roadmap, release theme map, product strategy-to-roadmap translation, or executive roadmap narrative. Trigger on phrases like \"build a roadmap\", \"roadmap these initiatives\", \"what should be now next later\", \"sequence this backlog\", \"quarterly product roadmap\", \"theme-based roadmap\", or \"plan the next two quarters\". Do NOT trigger for drafting or reviewing a single PRD (use prd-writer or prd-review), converting a PRD into an agentic PLAN.md (use prd-to-plan), or scoring\u002Franking a set of options without a time horizon (use prioritization).","https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Fplugins\u002Fproduct-manager\u002Fskills\u002Froadmap\u002FSKILL.md",[125],{"categoryNo":126,"categoryName":127,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000031","产品经理",[121,129,130,131,132,133,40,134,135,136,137,138,139,140,141,142,38,143,49,144],"writer","SET","do","translation","theme","backlog","trigger","ranking","true","strategy","map","now","use","sequencing","agentic","scoring",{"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":152,"publishedAt":55},"01M6GKGQTF57NFBDM5NZ89CV06","prioritization","Use this skill when the user wants to rank, score, triage, or compare product opportunities, features, PRD requirements, backlog items, roadmap candidates, or initiatives using RICE, impact-effort, confidence, reach, value, effort, risk, or tradeoff analysis. Trigger on phrases like \"prioritize these features\", \"rank this backlog\", \"RICE score\", \"impact effort matrix\", \"what should we build first\", \"compare these initiatives\", or \"stack rank product bets\". Do NOT trigger for a time-based roadmap (use roadmap), writing or reviewing one PRD (use prd-writer or prd-review), turning a PRD into an agentic plan (use prd-to-plan), or analyzing experiment results (use ab-testing or experimentation skills).","https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Fplugins\u002Fproduct-manager\u002Fskills\u002Fprioritization\u002FSKILL.md",[151],{"categoryNo":126,"categoryName":127,"taxonomyType":32,"taxonomyTypeDesc":33},[147,129,131,153,40,134,135,154,137,155,156,141,38,121,143,49,157,158,159,160],"risk","testing","writing","impact","requirements","analysis","compare","review",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":169,"publishedAt":55},"01M6GKGHEHWG9PF8EZHC7F1R21","prd-writer","Use this skill whenever the user wants to write, draft, create, or scaffold a PRD (Product Requirements Document), spec, product brief, one-pager, or \"working backwards\" PR\u002FFAQ from an idea, rough notes, discovery inputs, or an existing partial draft that needs authoring. Trigger on phrases like \"write a PRD\", \"draft a spec\", \"product doc for X\", \"one-pager\", \"PR\u002FFAQ\", \"feature brief\", or when the user describes a feature\u002Fproduct idea and asks for it to be turned into a written requirements document. Do NOT trigger for critique or approval-readiness review of an existing PRD (use prd-review), engineering design docs, RFCs, ADRs, prioritization, roadmaps, or technical architecture documents. The output of this skill is always a markdown file (or section thereof) that a real product team could ship from.","https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Fplugins\u002Fproduct-manager\u002Fskills\u002Fprd-writer\u002FSKILL.md",[167,168],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":126,"categoryName":127,"taxonomyType":32,"taxonomyTypeDesc":33},[129,170,171,172,46,38,173,174,175,176,160,177,178,147,179,180,181,45,182,183],"prd writer","prd","brief","product brief","documents","team","architecture","create","notes","critique","product","markdown","authoring","doc",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":192,"publishedAt":55},"01M6GKGBFB5FMNWY3TH3TDMMKR","prd-to-plan","Use this skill when the user has a PRD (Product Requirements Document), spec, or product brief and wants to turn it into an executable plan for agentic development — a plan that AI coding agents (Claude Code, sub-agents, orchestrators) can actually run. Trigger on phrases like \"turn this PRD into a plan\", \"agentic plan\", \"execution plan\", \"task graph\", \"break this down for Claude Code\", \"decompose this spec\", \"build plan\", \"implementation plan from PRD\", \"scrum-master plan\", or when the user provides a PRD\u002Fspec and asks \"what's next\" or \"how do we build this with agents\". The output is always a structured `PLAN.md` artifact with phases, tasks, dependencies, validation gates, sub-agent assignments, and context bundles. Do NOT trigger for: writing the PRD itself (use prd-writer), pure engineering design \u002F RFC \u002F ADR (architecture is a separate artifact), or generic project management plans without an agentic execution model.","https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Fplugins\u002Fproduct-manager\u002Fskills\u002Fprd-to-plan\u002FSKILL.md",[190,191],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":126,"categoryName":127,"taxonomyType":32,"taxonomyTypeDesc":33},[193,194,171,129,195,172,196,197,198,46,155,38,173,143,199,200,176,201,202,180],"plan","prd to plan","ai coding agents","agentic development","model","project","code","tasks","artifact","next",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":210,"publishedAt":55},"01M6GKG6WJ5ZPAR121DC1GBR70","prd-review","Use this skill when the user has an existing PRD, product spec, one-pager, or PR\u002FFAQ and wants critique, approval-readiness review, quality-bar scoring, required changes, or a red-team pass. Trigger on phrases like \"review this PRD\", \"critique my product spec\", \"is this PRD ready\", \"PRD quality bar\", \"red-team this requirements doc\", \"find gaps in this PR\u002FFAQ\", or \"what would block approval\". Do NOT trigger for drafting a new PRD from an idea (use prd-writer), converting an approved PRD into an agentic implementation plan (use prd-to-plan), building a roadmap (use roadmap), or ranking multiple initiatives (use prioritization).","https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Fplugins\u002Fproduct-manager\u002Fskills\u002Fprd-review\u002FSKILL.md",[209],{"categoryNo":126,"categoryName":127,"taxonomyType":32,"taxonomyTypeDesc":33},[160,211,171,129,212,131,213,214,135,136,137,141,38,121,143,49,157,175,144,147],"prd review","red-team","ready","pr"]