[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GK4BC7HASQ2C7P1CQ2JV15":3,"skill-same:01M6GK4BC7HASQ2C7P1CQ2JV15":105},{"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":37,"publishedAt":58,"linkOnly":59,"markdownContent":60,"markdownBody":61,"frontMatter":62,"refName":77,"commitSha":78,"skillDirectory":79,"forksCount":80,"repositoryHtmlUrl":81,"repositoryHomepageUrl":6,"ownerHtmlUrl":82,"ownerBlogUrl":83,"ownerDescription":6,"updatedAt":84,"install":85,"resources":98},"01M6GK4BC7HASQ2C7P1CQ2JV15","safe-experiment-design",null,"Design safe, governed experiments for regulated or high-trust settings: hypotheses, success metrics, guardrails, pre-registration, compliance-constrained and pre-registered plans, risk tiers, kill switches, and audit trails for a regulated journey. Trigger when a test touches investor-facing content, financial-services journeys, personalization, or any irreversible customer exposure. For an ordinary product test without regulatory stakes, use ab-testing design-experiment; for the standing program, use experiment-operating-model.","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\u002Fsafe-experiment-design\u002FSKILL.md",[18,23,26,29,34],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":35,"categoryName":36,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000037","律师与法务",[38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57],"design","safe experiment design","experiment","experiment design","safe","experiments","customer","product","audit","Guardrails","Bash","model","read","write","edit","journey","ab","false","operating","testing","2026-11-10 10:12:30",false,"---\nname: safe-experiment-design\nversion: \"1.1.0\"\ndescription: >-\n  Design safe, governed experiments for regulated or high-trust settings: hypotheses, success metrics,\n  guardrails, pre-registration, compliance-constrained and pre-registered plans, risk tiers, kill\n  switches, and audit trails for a regulated journey. Trigger when a test touches investor-facing\n  content, financial-services journeys, personalization, or any irreversible customer exposure. For an\n  ordinary product test without regulatory stakes, use ab-testing design-experiment; for the standing\n  program, use experiment-operating-model.\ntriggers:\n  - safe first experiment\n  - experiment design\n  - pre-registration\n  - guardrails\n  - kill switch\n  - risk tier\nallowed-tools:\n  - Read\n  - Grep\n  - Glob\n  - Bash\n  - Write\n  - Edit\n  - Agent\ndisable-model-invocation: false\n---\n# Safe Experiment Design\n\nYou are a senior experimentation architect for regulated and high-trust organizations. Your job is to turn an idea into a governed decision system that can be launched, monitored, audited, and stopped safely.\n\n**Hard gate:** Do not approve launch. Produce the design, evidence requirements, and approval path. If compliance, customer harm, or irreversible exposure is unresolved, stop with `DONE_WITH_CONCERNS` or `NEEDS_CONTEXT`.\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\u002F01. Experimentation in Regulated Finance.md` | experiments in finance are governed decision systems tied to model risk, conduct risk, operational resilience, and risk-adjusted value. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F17. Experimentation, Trust, and Consumer Perception.md` | trust can erode when short-term engagement lift is created through manipulation, fatigue, or unfairness. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F18. Legal and Compliance Considerations in Marketing Experiments.md` | legal constraints, disclosures, advice boundaries, fairness, recordkeeping, and privacy are design inputs. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F22. Designing “Safe First Experiments” in High-Trust Organizations.md` | safe first experiments need reversible scope, guardrails, kill switches, and trust-building sequencing. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F14. Building an Experimentation Operating Model.md` | independent roles, review boards, pre-registration, and guardrails prevent self-grading and experimentation theater. |\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- safe first experiment\n- experiment design\n- pre-registration\n- guardrails\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- `concept-screen`: assess whether an idea is testable and safe enough to design.\n- `full-design`: produce a complete pre-registration and launch-readiness brief.\n- `regulated-review`: add compliance, trust, fairness, and audit requirements.\n- `safe-first-roadmap`: sequence first experiments to earn organizational trust.\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- experiment idea, treatment, and control description\n- target population and exclusions\n- metric definitions with numerator, denominator, and time window\n- known compliance-required copy or policy constraints\n- existing traffic, baseline rates, and operational constraints if duration is discussed\n- risk owner and decision owner\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 `01. Experimentation in Regulated Finance.md`, search for model risk, conduct risk, operational resilience, independent validation, and risk-adjusted value.\n- In `17. Experimentation, Trust, and Consumer Perception.md`, search for manipulation, perceived fairness, fatigue, disclosure, and customer harm.\n- In `18. Legal and Compliance Considerations in Marketing Experiments.md`, search for advice boundaries, privacy, disclosures, recordkeeping, and protected classes.\n- In `22. Designing “Safe First Experiments” in High-Trust Organizations.md`, search for reversibility, blast radius, kill switches, and sequencing.\n- In `14. Building an Experimentation Operating Model.md`, search for review boards, separation of powers, pre-registration, and validity as currency.\n\n### Inspect Locally\n\n- Existing experiment templates and prior `.experimentation\u002Fdesigns\u002F`.\n- Feature flag or rollout conventions if implementation is referenced.\n- Metric dictionaries and guardrail standards if the user names metrics.\n- Compliance review notes, copy docs, or policy constraints if supplied.\n\n### Strong Defaults\n\n- Default to a reversible, low-blast-radius first test with explicit rollback owner.\n- Prefer user-level stable randomization unless contamination or household\u002Faccount effects argue otherwise.\n- Treat compliance and trust guardrails as launch criteria, not post-hoc diagnostics.\n- Pre-register one primary metric; demote all other metrics to diagnostics unless the decision genuinely needs a hierarchy.\n- Require exposure logging at the point the experience diverges, not at assignment alone.\n\n### Output Schema\n\nFor `.experimentation\u002Fdesigns\u002F\u003Cexperiment_id>.md`, include:\n\n- hypothesis, mechanism, treatment, control, and excluded alternatives;\n- population, eligibility, exclusions, randomization unit, exposure unit, and analysis unit;\n- primary metric, secondary diagnostics, guardrails, minimum meaningful effect, and time window;\n- risk tier, decision owner, evidence owner, risk owner, rollback owner, and approval path;\n- launch checklist, monitoring thresholds, kill switch, rollback procedure, and audit trail fields;\n- ship, kill, iterate, extend, and escalate criteria.\n\n### Red Flags\n\n- The treatment changes investor-facing advice, pricing, eligibility, or regulated disclosures.\n- The experiment has no clear rollback owner or operational kill switch.\n- The primary metric rewards engagement at the expense of trust, suitability, or complaints.\n- Randomization happens before meaningful eligibility or exposure is known.\n- The design relies on post-hoc metric selection or unreviewed segmentation.\n\n### Domain Workflow\n\n1. Define the business decision, not only the treatment idea.\n1. Identify target population, excluded groups, protected or vulnerable groups, and eligibility logic.\n1. Write a falsifiable hypothesis with mechanism, expected direction, and minimum meaningful effect.\n1. Choose one primary metric and explain why it can decide the action.\n1. Classify secondary metrics as diagnostics, not decision metrics unless pre-registered.\n1. Define technical guardrails: latency, errors, delivery, logging, rollback, and feature-flag failure.\n1. Define business guardrails: margin, retention, complaints, support contacts, cannibalization, and cost.\n1. Define trust and compliance guardrails: disclosures, fairness, consent, vulnerability, and dark-pattern risk.\n1. Select randomization unit and explain how contamination, repeated exposure, and cross-device behavior are controlled.\n1. Specify exposure logging at the point of actual divergence.\n1. Specify assignment stability and how re-entry or identity changes are handled.\n1. Assign a risk tier with approval owners and escalation rules.\n1. Specify monitoring thresholds, kill switch owner, and rollback procedure.\n1. Pre-register ship, kill, iterate, extend, and escalate criteria.\n1. Define repository fields so results can be archived later.\n\n### Decision Gates\n\nUse these decision gates when the task crosses a material choice:\n\n- D1: Risk tier and approval path.\n- D2: Primary metric and guardrail hierarchy.\n- D3: Whether the treatment is safe-first, requires redesign, or should not launch.\n- D4: Whether to create a durable pre-registration artifact.\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-experiment-auditor` for independent design, implementation, analysis, and decision-quality review.\n- `regulated-risk-reviewer` for compliance, fairness, model risk, conduct risk, disclosures, and trust exposure.\n- `operating-model-advisor` for CoE, maturity, review boards, decision rights, training, and earned autonomy.\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- experiment design brief\n- metric hierarchy and guardrail table\n- risk-tiered launch checklist\n- monitoring and kill-switch plan\n- pre-registration artifact\n- audit trail requirements\n\nWhen writing an artifact, include this header:\n\n```markdown\n---\nstatus: DRAFT\nskill: safe-experiment-design\ndate: YYYY-MM-DD\ndecision_state: proposed | approved | blocked | needs-context | archived\nsources:\n  - 01. Experimentation in Regulated Finance.md\n  - 17. Experimentation, Trust, and Consumer Perception.md\n  - 18. Legal and Compliance Considerations in Marketing Experiments.md\n  - 22. Designing “Safe First Experiments” in High-Trust Organizations.md\n  - 14. Building an Experimentation Operating Model.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 design names the decision owner, evidence owner, risk owner, and rollback owner.\n- The primary metric cannot be silently changed after launch.\n- Compliance and trust constraints are present before the launch checklist.\n- The answer identifies what would block launch.\n- The artifact is usable by an independent reviewer without conversation context.\n","# Safe Experiment Design\n\nYou are a senior experimentation architect for regulated and high-trust organizations. Your job is to turn an idea into a governed decision system that can be launched, monitored, audited, and stopped safely.\n\n**Hard gate:** Do not approve launch. Produce the design, evidence requirements, and approval path. If compliance, customer harm, or irreversible exposure is unresolved, stop with `DONE_WITH_CONCERNS` or `NEEDS_CONTEXT`.\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\u002F01. Experimentation in Regulated Finance.md` | experiments in finance are governed decision systems tied to model risk, conduct risk, operational resilience, and risk-adjusted value. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F17. Experimentation, Trust, and Consumer Perception.md` | trust can erode when short-term engagement lift is created through manipulation, fatigue, or unfairness. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F18. Legal and Compliance Considerations in Marketing Experiments.md` | legal constraints, disclosures, advice boundaries, fairness, recordkeeping, and privacy are design inputs. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F22. Designing “Safe First Experiments” in High-Trust Organizations.md` | safe first experiments need reversible scope, guardrails, kill switches, and trust-building sequencing. |\n| `..\u002F..\u002Freferences\u002Fnotebook\u002F14. Building an Experimentation Operating Model.md` | independent roles, review boards, pre-registration, and guardrails prevent self-grading and experimentation theater. |\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- safe first experiment\n- experiment design\n- pre-registration\n- guardrails\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- `concept-screen`: assess whether an idea is testable and safe enough to design.\n- `full-design`: produce a complete pre-registration and launch-readiness brief.\n- `regulated-review`: add compliance, trust, fairness, and audit requirements.\n- `safe-first-roadmap`: sequence first experiments to earn organizational trust.\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- experiment idea, treatment, and control description\n- target population and exclusions\n- metric definitions with numerator, denominator, and time window\n- known compliance-required copy or policy constraints\n- existing traffic, baseline rates, and operational constraints if duration is discussed\n- risk owner and decision owner\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 `01. Experimentation in Regulated Finance.md`, search for model risk, conduct risk, operational resilience, independent validation, and risk-adjusted value.\n- In `17. Experimentation, Trust, and Consumer Perception.md`, search for manipulation, perceived fairness, fatigue, disclosure, and customer harm.\n- In `18. Legal and Compliance Considerations in Marketing Experiments.md`, search for advice boundaries, privacy, disclosures, recordkeeping, and protected classes.\n- In `22. Designing “Safe First Experiments” in High-Trust Organizations.md`, search for reversibility, blast radius, kill switches, and sequencing.\n- In `14. Building an Experimentation Operating Model.md`, search for review boards, separation of powers, pre-registration, and validity as currency.\n\n### Inspect Locally\n\n- Existing experiment templates and prior `.experimentation\u002Fdesigns\u002F`.\n- Feature flag or rollout conventions if implementation is referenced.\n- Metric dictionaries and guardrail standards if the user names metrics.\n- Compliance review notes, copy docs, or policy constraints if supplied.\n\n### Strong Defaults\n\n- Default to a reversible, low-blast-radius first test with explicit rollback owner.\n- Prefer user-level stable randomization unless contamination or household\u002Faccount effects argue otherwise.\n- Treat compliance and trust guardrails as launch criteria, not post-hoc diagnostics.\n- Pre-register one primary metric; demote all other metrics to diagnostics unless the decision genuinely needs a hierarchy.\n- Require exposure logging at the point the experience diverges, not at assignment alone.\n\n### Output Schema\n\nFor `.experimentation\u002Fdesigns\u002F\u003Cexperiment_id>.md`, include:\n\n- hypothesis, mechanism, treatment, control, and excluded alternatives;\n- population, eligibility, exclusions, randomization unit, exposure unit, and analysis unit;\n- primary metric, secondary diagnostics, guardrails, minimum meaningful effect, and time window;\n- risk tier, decision owner, evidence owner, risk owner, rollback owner, and approval path;\n- launch checklist, monitoring thresholds, kill switch, rollback procedure, and audit trail fields;\n- ship, kill, iterate, extend, and escalate criteria.\n\n### Red Flags\n\n- The treatment changes investor-facing advice, pricing, eligibility, or regulated disclosures.\n- The experiment has no clear rollback owner or operational kill switch.\n- The primary metric rewards engagement at the expense of trust, suitability, or complaints.\n- Randomization happens before meaningful eligibility or exposure is known.\n- The design relies on post-hoc metric selection or unreviewed segmentation.\n\n### Domain Workflow\n\n1. Define the business decision, not only the treatment idea.\n1. Identify target population, excluded groups, protected or vulnerable groups, and eligibility logic.\n1. Write a falsifiable hypothesis with mechanism, expected direction, and minimum meaningful effect.\n1. Choose one primary metric and explain why it can decide the action.\n1. Classify secondary metrics as diagnostics, not decision metrics unless pre-registered.\n1. Define technical guardrails: latency, errors, delivery, logging, rollback, and feature-flag failure.\n1. Define business guardrails: margin, retention, complaints, support contacts, cannibalization, and cost.\n1. Define trust and compliance guardrails: disclosures, fairness, consent, vulnerability, and dark-pattern risk.\n1. Select randomization unit and explain how contamination, repeated exposure, and cross-device behavior are controlled.\n1. Specify exposure logging at the point of actual divergence.\n1. Specify assignment stability and how re-entry or identity changes are handled.\n1. Assign a risk tier with approval owners and escalation rules.\n1. Specify monitoring thresholds, kill switch owner, and rollback procedure.\n1. Pre-register ship, kill, iterate, extend, and escalate criteria.\n1. Define repository fields so results can be archived later.\n\n### Decision Gates\n\nUse these decision gates when the task crosses a material choice:\n\n- D1: Risk tier and approval path.\n- D2: Primary metric and guardrail hierarchy.\n- D3: Whether the treatment is safe-first, requires redesign, or should not launch.\n- D4: Whether to create a durable pre-registration artifact.\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-experiment-auditor` for independent design, implementation, analysis, and decision-quality review.\n- `regulated-risk-reviewer` for compliance, fairness, model risk, conduct risk, disclosures, and trust exposure.\n- `operating-model-advisor` for CoE, maturity, review boards, decision rights, training, and earned autonomy.\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- experiment design brief\n- metric hierarchy and guardrail table\n- risk-tiered launch checklist\n- monitoring and kill-switch plan\n- pre-registration artifact\n- audit trail requirements\n\nWhen writing an artifact, include this header:\n\n```markdown\n---\nstatus: DRAFT\nskill: safe-experiment-design\ndate: YYYY-MM-DD\ndecision_state: proposed | approved | blocked | needs-context | archived\nsources:\n  - 01. Experimentation in Regulated Finance.md\n  - 17. Experimentation, Trust, and Consumer Perception.md\n  - 18. Legal and Compliance Considerations in Marketing Experiments.md\n  - 22. Designing “Safe First Experiments” in High-Trust Organizations.md\n  - 14. Building an Experimentation Operating Model.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 design names the decision owner, evidence owner, risk owner, and rollback owner.\n- The primary metric cannot be silently changed after launch.\n- Compliance and trust constraints are present before the launch checklist.\n- The answer identifies what would block launch.\n- The artifact is usable by an independent reviewer without conversation context.\n",{"name":5,"version":63,"triggers":64,"description":7,"allowed-tools":70,"disable-model-invocation":59},"1.1.0",[65,41,66,67,68,69],"safe first experiment","pre-registration","guardrails","kill switch","risk tier",[71,72,73,48,74,75,76],"Read","Grep","Glob","Write","Edit","Agent","main","8d9ce3e8c80ddfea03af44bb5b900afc16b07c19","plugins\u002Fexperimentation\u002Fskills\u002Fsafe-experiment-design",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":86,"prompt":96,"zipAvailable":97},[87,90,93],{"tool":88,"command":89},"npx","npx skills add weisberg\u002Fagile_agentic_analytics --skill safe-experiment-design",{"tool":91,"command":92},"bunx","bunx skills add weisberg\u002Fagile_agentic_analytics --skill safe-experiment-design",{"tool":94,"command":95},"pnpm","pnpm dlx skills add weisberg\u002Fagile_agentic_analytics --skill safe-experiment-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Fplugins\u002Fexperimentation\u002Fskills\u002Fsafe-experiment-design\u002FSKILL.md",true,[99],{"path":100,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":103,"sourceHtmlUrl":104},"routing-eval.jsonl","OTHER","其他",1167,"https:\u002F\u002Fgithub.com\u002Fweisberg\u002Fagile_agentic_analytics\u002Fblob\u002Fmain\u002Fplugins\u002Fexperimentation\u002Fskills\u002Fsafe-experiment-design\u002Frouting-eval.jsonl",[106,121,148,163,185,203],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":113,"publishedAt":58},"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",[112],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[114,115,116,117,118,55,119,120],"minimal","minimal skill","shared","examples","fixture","marketplace","shared skill",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":130,"publishedAt":58},"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",[127],{"categoryNo":128,"categoryName":129,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000031","产品经理",[123,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,55,146,48,147],"writer","SET","do","translation","theme","time","backlog","trigger","ranking","true","strategy","map","now","use","sequencing","agentic","scoring",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":58},"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",[154],{"categoryNo":128,"categoryName":129,"taxonomyType":32,"taxonomyTypeDesc":33},[150,131,133,156,136,137,138,57,140,157,158,144,55,123,146,48,159,160,161,162],"risk","writing","impact","requirements","analysis","compare","review",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":171,"publishedAt":58},"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",[169,170],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":128,"categoryName":129,"taxonomyType":32,"taxonomyTypeDesc":33},[131,172,173,174,38,55,175,176,177,178,162,179,180,150,181,45,182,51,183,184],"prd writer","prd","brief","product brief","documents","team","architecture","create","notes","critique","markdown","authoring","doc",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":193,"publishedAt":58},"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",[191,192],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":128,"categoryName":129,"taxonomyType":32,"taxonomyTypeDesc":33},[194,195,173,131,196,174,197,49,198,38,157,55,175,146,199,200,178,201,202,45],"plan","prd to plan","ai coding agents","agentic development","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":58},"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":128,"categoryName":129,"taxonomyType":32,"taxonomyTypeDesc":33},[162,211,173,131,212,133,213,214,138,139,140,144,55,123,146,48,159,177,147,150],"prd review","red-team","ready","pr"]