[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D4BVNBTH6CDFXG0SP9ZF70":3,"skill-same:01M6D4BVNBTH6CDFXG0SP9ZF70":67},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6D4BVNBTH6CDFXG0SP9ZF70","experiment",null,"Design lean validation experiments — hypothesis, method, success criteria, sample size, timeline, and decision rules","GeorgeQLe\u002Fagentic-skills","GeorgeQLe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F21134126?v=4","01M6D2JP418S0VGJGF8M93EC3H","George Le","01M6D2JPBAKYD82TA5FS6HKQ3D",1,"MIT","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fbusiness-growth\u002Fcodex\u002Fexperiment\u002Farchive\u002Fv0.1\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35],"design","test","experiments","planning","validation","hypothesis","timeline","decision","Rules","v0","lean","sample","2026-11-10 10:12:30",false,"---\nname: experiment\ndescription: Design lean validation experiments — hypothesis, method, success criteria, sample size, timeline, and decision rules\ntype: planning\nversion: v0.1\nargument-hint: \u003Chypothesis or assumption to test>\n---\n\n## Pack Availability Guard\n\nBefore telling the user to run a skill from another project-local pack, check `.agents\u002Fproject.json.enabled_packs`. If the target pack is not enabled, recommend `$pack install \u003Cpack>` instead of the target skill. Global skills are always valid. Skills from this same pack are valid because the current skill is already running from that pack.\n\n# Experiment — Lean Validation Design\n\nTakes a hypothesis (from `$assumption-tracker` or user) and designs a cheap, fast validation experiment. Covers landing page tests, fake-door tests, concierge MVPs, surveys, A\u002FB tests, pricing tests, and smoke tests. Outputs a structured plan with hypothesis, method, success criteria, sample size, timeline, and decision rules.\n\n## Soft Prerequisites\n\n- Read `research\u002Fassumption-tracker.md` if it exists — pulls the highest-priority unvalidated assumption\n- Read `research\u002Ficp.md` if it exists — grounds experiment design in who the target is\n- Read `research\u002Fmetrics.md` if it exists — aligns success criteria with existing metric definitions\n- Read `research\u002Fgtm.md` if it exists — leverages channel strategy for reaching test subjects\n\n## Process\n\n### 0. App Scope Resolution (Monorepo Support)\n\nBefore checking prerequisites, determine the app scope:\n\n1. If `$ARGUMENTS` specifies an app name matching a subdirectory of `research\u002F`, use it.\n2. If `research\u002F` contains subdirectories (excluding files), list them and ask the user which app to target. If the session is already in Plan mode and there are 2-3 concrete choices, prefer `request_user_input`; otherwise ask in plain text. If only one subdirectory exists, use it automatically.\n3. If no subdirectories exist, proceed with flat structure (single-product mode).\n\nWhen app scope `{app}` is active:\n- Read\u002Fwrite research from `research\u002F{app}\u002F` instead of `research\u002F`\n\n### 1. Parse Input & Load Context\n\n**Read `$ARGUMENTS`:**\n- If it's a specific hypothesis or assumption: use it directly\n- If it's a reference to an assumption number (e.g., \"#3\"): look it up in `research\u002Fassumption-tracker.md`\n- If empty: check `research\u002Fassumption-tracker.md` for the highest-priority unvalidated assumption. If no tracker exists, ask the user what they want to test. If the session is already in Plan mode and there are 2-3 concrete choices, prefer `request_user_input`.\n\n**Load context:** Read available research docs to understand the ICP, channels, metrics, and existing knowledge.\n\n### 2. Structure the Hypothesis\n\nConvert the input into a structured hypothesis:\n\n**Format**: \"We believe that [target segment] will [expected behavior] because [rationale]. We'll know this is true when [measurable outcome].\"\n\nPresent and refine with the user. If the session is already in Plan mode and there are 2-3 concrete choices, prefer `request_user_input`; otherwise ask in plain text:\n- \"Here's how I've structured the hypothesis. Does this capture what you want to test?\"\n- If the hypothesis is too broad, help narrow it to something testable in 1-2 weeks\n\n### 3. Research Experiment Methods\n\nUse WebSearch with **3-5 targeted queries** to find best practices for this type of validation:\n\n1. **Method-specific** — \"[experiment type] validation method\", \"how to test [hypothesis type]\"\n2. **Sample size** — \"[experiment type] sample size calculator\", \"minimum viable test size\"\n3. **Benchmarks** — \"[category] conversion rate benchmark\", \"[experiment type] typical results\"\n4. **Tools** — \"[experiment type] tools\", \"cheapest way to test [hypothesis]\"\n\n### 4. Design the Experiment — Present & Validate\n\nSelect the most appropriate experiment type and design the full plan:\n\n#### Experiment Types\n\n| Type | Best For | Timeline | Cost |\n|------|----------|----------|------|\n| **Landing page test** | Demand validation, messaging | 1-2 weeks | $50-200 (ads) |\n| **Fake-door test** | Feature demand, willingness to explore | 1 week | $0 (in-product) |\n| **Concierge MVP** | Value delivery, willingness to pay | 2-4 weeks | Time only |\n| **Survey** | Broad sentiment, preference ranking | 3-5 days | $0-100 |\n| **A\u002FB test** | Optimization, messaging variants | 1-2 weeks | $0 (in-product) |\n| **Pricing test** | Willingness to pay, price sensitivity | 1-2 weeks | $50-200 |\n| **Smoke test** | Demand for non-existent feature | 3-5 days | $0-50 |\n| **Pre-sale \u002F LOI** | B2B willingness to pay | 1-2 weeks | Time only |\n| **Wizard of Oz** | Complex feature viability | 2-4 weeks | Time only |\n\n**Present the experiment design to the user.** If the session is already in Plan mode, prefer `request_user_input`; otherwise ask in plain text. Show:\n- Recommended experiment type with rationale (why this method over alternatives)\n- Detailed plan with timeline and cost estimate\n- Success criteria with specific numbers (citing benchmarks from research)\n- Decision rules for both outcomes\n\nAsk:\n- \"Does this experiment design feel feasible? Too ambitious or too simple?\"\n- \"Any resource constraints I should know about? (budget, time, access to users)\"\n\nIncorporate feedback before proceeding.\n\n### 5. Define Decision Rules\n\nFor each possible outcome, define what happens next:\n\n- **If hypothesis is validated** (success criteria met): What's the next step? (e.g., build the feature, commit to the pricing, double down on the channel)\n- **If hypothesis is invalidated** (criteria not met): What's the pivot? (e.g., test alternative, revisit ICP, change approach)\n- **If results are inconclusive** (between thresholds): What additional data is needed? Run a follow-up experiment or extend the current one?\n\n### 6. Populate Next Steps\n\nInclude a **Recommended** item for the current design-stage next step, followed by **Other options**. Separate current next steps from outcome-specific next steps:\n\nUse this format in the output:\n\n```markdown\n## Next Steps\n\n**Recommended:** Run the experiment — the plan is only useful after the evidence is collected\n\nOther options:\n- [2-4 applicable alternatives]\n```\n\n- ALWAYS: Run the experiment (manual step — the plan tells you how)\n- For a newly designed experiment, do not list validation\u002Finvalidation commands as current top-level next steps; put those under `## Decision Rules` because they are only valid after results exist.\n- In `### If Validated`: include the next valid command, usually `$customer-feedback [results]` to log evidence, `$assumption-tracker` to mark the assumption validated, or `$roadmap` if the result commits the team to build.\n- In `### If Invalidated`: include `$assumption-tracker` to mark the assumption invalidated, plus `$brainstorm`, `$icp`, `$gtm`, or `$monetization` only when the failed assumption belongs to that domain.\n- In `### If Inconclusive`: include `$experiment [follow-up]` if the test needs another run, or `$customer-feedback` if qualitative evidence is the missing signal.\n- IF more assumptions remain untested after this design: `$experiment [next assumption]` — Design the next experiment\n- IF enough assumptions are validated after completed results: `$research-roadmap` — Check if research docs need updating based on learnings\n\n### 7. Write Output\n\nPresent final plan to user. Ask:\n- \"Ready to write this experiment plan? Anything to adjust?\"\n\nOnly after confirmation, write the output file.\n\n## Output\n\n### `research\u002Fexperiments\u002F[experiment-name].md` (or `research\u002F{app}\u002Fexperiments\u002F[experiment-name].md`)\n\n```markdown\n# Experiment: [Descriptive Name]\n\n> Date designed: [current date]\n> Status: Designed | Running | Completed\n> Assumption: [from assumption-tracker, if applicable — include # reference]\n> Priority: [from assumption-tracker score, if applicable]\n\n## Hypothesis\n\n**We believe that** [target segment]\n**will** [expected behavior]\n**because** [rationale from research]\n\n**We'll know this is true when** [measurable outcome with specific threshold]\n\n## Method\n\n**Type**: [Landing page test \u002F Fake-door \u002F Concierge MVP \u002F Survey \u002F A\u002FB test \u002F Pricing test \u002F Smoke test \u002F Pre-sale \u002F Wizard of Oz]\n**Why this method**: [rationale — why this is the cheapest\u002Ffastest way to test this hypothesis]\n\n### Setup\n[Step-by-step instructions for setting up the experiment]\n\n1. [Step 1]\n2. [Step 2]\n3. ...\n\n### Tools Needed\n- [Tool 1] — [purpose]\n- [Tool 2] — [purpose]\n\n### Audience\n**Who**: [specific segment from ICP]\n**How to reach them**: [channel — from GTM if available]\n**Sample size**: [number needed for statistical significance]\n**Recruitment method**: [how to get participants]\n\n## Success Criteria\n\n| Metric | Failure | Inconclusive | Success |\n|--------|---------|--------------|---------|\n| [Primary metric] | \u003C [threshold] | [range] | ≥ [threshold] |\n| [Secondary metric] | \u003C [threshold] | [range] | ≥ [threshold] |\n\n**Benchmarks**: [what industry\u002Fcompetitor data says is typical]\n\n## Timeline\n\n| Phase | Duration | Tasks |\n|-------|----------|-------|\n| Setup | [days] | [what to prepare] |\n| Run | [days] | [data collection period] |\n| Analyze | [days] | [how to analyze results] |\n| **Total** | **[days]** | |\n\n## Budget\n\n| Item | Cost |\n|------|------|\n| [item] | [amount] |\n| **Total** | **[amount]** |\n\n## Decision Rules\n\n### If Validated (success criteria met)\n[Specific next actions — what to build, commit to, or double down on]\n\n### If Invalidated (failure criteria met)\n[Specific pivot — what to change, test next, or abandon]\n\n### If Inconclusive\n[What additional data is needed, whether to extend or redesign]\n\n## Results\n\n> Fill this section after the experiment completes.\n\n**Status**: [Validated \u002F Invalidated \u002F Inconclusive]\n**Date completed**: [date]\n\n### Raw Data\n[Key numbers and observations]\n\n### Analysis\n[What the data shows — connect back to hypothesis]\n\n### Decision\n[What was decided based on the results]\n\n### Learnings\n[What was learned beyond the hypothesis — surprises, side findings]\n\n## Next Steps\n\n**Recommended:** [recommended next step] — [one-line reason grounded in this artifact]\n\nOther options:\n- [conditional items from step 6 — only include items whose conditions are met]\n```\n\nCreate the `research\u002Fexperiments\u002F` directory if it doesn't exist.\n\n## Task Classification\n\nWhen this skill produces follow-up work, file it by execution semantics:\n\n- Immediately actionable implementation or documentation work goes in `tasks\u002Ftodo.md`.\n- Human-only external actions tied to automated steps go in `tasks\u002Fmanual-todo.md` with `_(blocks: Step N.X)_` or `_(after: Step N.X)_`; repo edits, SDK wiring, generated assets, local commands, tests, audits, and authenticated CLI\u002FAPI work stay in `tasks\u002Ftodo.md`.\n- One-time condition-gated records, baselines, or future measurements go in `tasks\u002Frecord-todo.md` with source, condition, non-blocking reason, evidence, and promotion rule.\n- Cadence-based reviews, playtests, adoption checks, investor updates, retros, or docs-health checks go in `tasks\u002Frecurring-todo.md` with cadence, owner\u002Fagent, next due, evidence path, and escalation conditions.\n- Do not put non-blocking records or recurring obligations in `tasks\u002Ftodo.md` unless they have been explicitly promoted into current execution work.\n\n## Constraints\n\n- **One hypothesis per experiment.** If the user has multiple things to test, design separate experiments. Don't bundle.\n- **Cheap and fast.** Every experiment should be completable in 1-4 weeks with minimal budget. If the design is expensive or slow, simplify.\n- **Specific success criteria.** \"Users like it\" is not a success criterion. \"≥40% of landing page visitors click 'Get Early Access'\" is.\n- **Present before writing.** Never write output files until the experiment design has been presented and validated.\n- **Include decision rules.** Every experiment must specify what happens for each possible outcome. No experiment should end with \"we'll figure it out.\"\n- **Reference benchmarks.** Success thresholds should be grounded in industry benchmarks or competitor data, not arbitrary numbers.\n- **Don't overdesign.** A simple survey can validate an assumption just as well as an elaborate A\u002FB test. Recommend the simplest method that produces a clear signal.\n\n## Alignment Page\n\nFollow the shared Alignment Page convention in CLAUDE.md. Output: `alignment\u002Fexperiment-{topic}.html`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","## Pack Availability Guard\n\nBefore telling the user to run a skill from another project-local pack, check `.agents\u002Fproject.json.enabled_packs`. If the target pack is not enabled, recommend `$pack install \u003Cpack>` instead of the target skill. Global skills are always valid. Skills from this same pack are valid because the current skill is already running from that pack.\n\n# Experiment — Lean Validation Design\n\nTakes a hypothesis (from `$assumption-tracker` or user) and designs a cheap, fast validation experiment. Covers landing page tests, fake-door tests, concierge MVPs, surveys, A\u002FB tests, pricing tests, and smoke tests. Outputs a structured plan with hypothesis, method, success criteria, sample size, timeline, and decision rules.\n\n## Soft Prerequisites\n\n- Read `research\u002Fassumption-tracker.md` if it exists — pulls the highest-priority unvalidated assumption\n- Read `research\u002Ficp.md` if it exists — grounds experiment design in who the target is\n- Read `research\u002Fmetrics.md` if it exists — aligns success criteria with existing metric definitions\n- Read `research\u002Fgtm.md` if it exists — leverages channel strategy for reaching test subjects\n\n## Process\n\n### 0. App Scope Resolution (Monorepo Support)\n\nBefore checking prerequisites, determine the app scope:\n\n1. If `$ARGUMENTS` specifies an app name matching a subdirectory of `research\u002F`, use it.\n2. If `research\u002F` contains subdirectories (excluding files), list them and ask the user which app to target. If the session is already in Plan mode and there are 2-3 concrete choices, prefer `request_user_input`; otherwise ask in plain text. If only one subdirectory exists, use it automatically.\n3. If no subdirectories exist, proceed with flat structure (single-product mode).\n\nWhen app scope `{app}` is active:\n- Read\u002Fwrite research from `research\u002F{app}\u002F` instead of `research\u002F`\n\n### 1. Parse Input & Load Context\n\n**Read `$ARGUMENTS`:**\n- If it's a specific hypothesis or assumption: use it directly\n- If it's a reference to an assumption number (e.g., \"#3\"): look it up in `research\u002Fassumption-tracker.md`\n- If empty: check `research\u002Fassumption-tracker.md` for the highest-priority unvalidated assumption. If no tracker exists, ask the user what they want to test. If the session is already in Plan mode and there are 2-3 concrete choices, prefer `request_user_input`.\n\n**Load context:** Read available research docs to understand the ICP, channels, metrics, and existing knowledge.\n\n### 2. Structure the Hypothesis\n\nConvert the input into a structured hypothesis:\n\n**Format**: \"We believe that [target segment] will [expected behavior] because [rationale]. We'll know this is true when [measurable outcome].\"\n\nPresent and refine with the user. If the session is already in Plan mode and there are 2-3 concrete choices, prefer `request_user_input`; otherwise ask in plain text:\n- \"Here's how I've structured the hypothesis. Does this capture what you want to test?\"\n- If the hypothesis is too broad, help narrow it to something testable in 1-2 weeks\n\n### 3. Research Experiment Methods\n\nUse WebSearch with **3-5 targeted queries** to find best practices for this type of validation:\n\n1. **Method-specific** — \"[experiment type] validation method\", \"how to test [hypothesis type]\"\n2. **Sample size** — \"[experiment type] sample size calculator\", \"minimum viable test size\"\n3. **Benchmarks** — \"[category] conversion rate benchmark\", \"[experiment type] typical results\"\n4. **Tools** — \"[experiment type] tools\", \"cheapest way to test [hypothesis]\"\n\n### 4. Design the Experiment — Present & Validate\n\nSelect the most appropriate experiment type and design the full plan:\n\n#### Experiment Types\n\n| Type | Best For | Timeline | Cost |\n|------|----------|----------|------|\n| **Landing page test** | Demand validation, messaging | 1-2 weeks | $50-200 (ads) |\n| **Fake-door test** | Feature demand, willingness to explore | 1 week | $0 (in-product) |\n| **Concierge MVP** | Value delivery, willingness to pay | 2-4 weeks | Time only |\n| **Survey** | Broad sentiment, preference ranking | 3-5 days | $0-100 |\n| **A\u002FB test** | Optimization, messaging variants | 1-2 weeks | $0 (in-product) |\n| **Pricing test** | Willingness to pay, price sensitivity | 1-2 weeks | $50-200 |\n| **Smoke test** | Demand for non-existent feature | 3-5 days | $0-50 |\n| **Pre-sale \u002F LOI** | B2B willingness to pay | 1-2 weeks | Time only |\n| **Wizard of Oz** | Complex feature viability | 2-4 weeks | Time only |\n\n**Present the experiment design to the user.** If the session is already in Plan mode, prefer `request_user_input`; otherwise ask in plain text. Show:\n- Recommended experiment type with rationale (why this method over alternatives)\n- Detailed plan with timeline and cost estimate\n- Success criteria with specific numbers (citing benchmarks from research)\n- Decision rules for both outcomes\n\nAsk:\n- \"Does this experiment design feel feasible? Too ambitious or too simple?\"\n- \"Any resource constraints I should know about? (budget, time, access to users)\"\n\nIncorporate feedback before proceeding.\n\n### 5. Define Decision Rules\n\nFor each possible outcome, define what happens next:\n\n- **If hypothesis is validated** (success criteria met): What's the next step? (e.g., build the feature, commit to the pricing, double down on the channel)\n- **If hypothesis is invalidated** (criteria not met): What's the pivot? (e.g., test alternative, revisit ICP, change approach)\n- **If results are inconclusive** (between thresholds): What additional data is needed? Run a follow-up experiment or extend the current one?\n\n### 6. Populate Next Steps\n\nInclude a **Recommended** item for the current design-stage next step, followed by **Other options**. Separate current next steps from outcome-specific next steps:\n\nUse this format in the output:\n\n```markdown\n## Next Steps\n\n**Recommended:** Run the experiment — the plan is only useful after the evidence is collected\n\nOther options:\n- [2-4 applicable alternatives]\n```\n\n- ALWAYS: Run the experiment (manual step — the plan tells you how)\n- For a newly designed experiment, do not list validation\u002Finvalidation commands as current top-level next steps; put those under `## Decision Rules` because they are only valid after results exist.\n- In `### If Validated`: include the next valid command, usually `$customer-feedback [results]` to log evidence, `$assumption-tracker` to mark the assumption validated, or `$roadmap` if the result commits the team to build.\n- In `### If Invalidated`: include `$assumption-tracker` to mark the assumption invalidated, plus `$brainstorm`, `$icp`, `$gtm`, or `$monetization` only when the failed assumption belongs to that domain.\n- In `### If Inconclusive`: include `$experiment [follow-up]` if the test needs another run, or `$customer-feedback` if qualitative evidence is the missing signal.\n- IF more assumptions remain untested after this design: `$experiment [next assumption]` — Design the next experiment\n- IF enough assumptions are validated after completed results: `$research-roadmap` — Check if research docs need updating based on learnings\n\n### 7. Write Output\n\nPresent final plan to user. Ask:\n- \"Ready to write this experiment plan? Anything to adjust?\"\n\nOnly after confirmation, write the output file.\n\n## Output\n\n### `research\u002Fexperiments\u002F[experiment-name].md` (or `research\u002F{app}\u002Fexperiments\u002F[experiment-name].md`)\n\n```markdown\n# Experiment: [Descriptive Name]\n\n> Date designed: [current date]\n> Status: Designed | Running | Completed\n> Assumption: [from assumption-tracker, if applicable — include # reference]\n> Priority: [from assumption-tracker score, if applicable]\n\n## Hypothesis\n\n**We believe that** [target segment]\n**will** [expected behavior]\n**because** [rationale from research]\n\n**We'll know this is true when** [measurable outcome with specific threshold]\n\n## Method\n\n**Type**: [Landing page test \u002F Fake-door \u002F Concierge MVP \u002F Survey \u002F A\u002FB test \u002F Pricing test \u002F Smoke test \u002F Pre-sale \u002F Wizard of Oz]\n**Why this method**: [rationale — why this is the cheapest\u002Ffastest way to test this hypothesis]\n\n### Setup\n[Step-by-step instructions for setting up the experiment]\n\n1. [Step 1]\n2. [Step 2]\n3. ...\n\n### Tools Needed\n- [Tool 1] — [purpose]\n- [Tool 2] — [purpose]\n\n### Audience\n**Who**: [specific segment from ICP]\n**How to reach them**: [channel — from GTM if available]\n**Sample size**: [number needed for statistical significance]\n**Recruitment method**: [how to get participants]\n\n## Success Criteria\n\n| Metric | Failure | Inconclusive | Success |\n|--------|---------|--------------|---------|\n| [Primary metric] | \u003C [threshold] | [range] | ≥ [threshold] |\n| [Secondary metric] | \u003C [threshold] | [range] | ≥ [threshold] |\n\n**Benchmarks**: [what industry\u002Fcompetitor data says is typical]\n\n## Timeline\n\n| Phase | Duration | Tasks |\n|-------|----------|-------|\n| Setup | [days] | [what to prepare] |\n| Run | [days] | [data collection period] |\n| Analyze | [days] | [how to analyze results] |\n| **Total** | **[days]** | |\n\n## Budget\n\n| Item | Cost |\n|------|------|\n| [item] | [amount] |\n| **Total** | **[amount]** |\n\n## Decision Rules\n\n### If Validated (success criteria met)\n[Specific next actions — what to build, commit to, or double down on]\n\n### If Invalidated (failure criteria met)\n[Specific pivot — what to change, test next, or abandon]\n\n### If Inconclusive\n[What additional data is needed, whether to extend or redesign]\n\n## Results\n\n> Fill this section after the experiment completes.\n\n**Status**: [Validated \u002F Invalidated \u002F Inconclusive]\n**Date completed**: [date]\n\n### Raw Data\n[Key numbers and observations]\n\n### Analysis\n[What the data shows — connect back to hypothesis]\n\n### Decision\n[What was decided based on the results]\n\n### Learnings\n[What was learned beyond the hypothesis — surprises, side findings]\n\n## Next Steps\n\n**Recommended:** [recommended next step] — [one-line reason grounded in this artifact]\n\nOther options:\n- [conditional items from step 6 — only include items whose conditions are met]\n```\n\nCreate the `research\u002Fexperiments\u002F` directory if it doesn't exist.\n\n## Task Classification\n\nWhen this skill produces follow-up work, file it by execution semantics:\n\n- Immediately actionable implementation or documentation work goes in `tasks\u002Ftodo.md`.\n- Human-only external actions tied to automated steps go in `tasks\u002Fmanual-todo.md` with `_(blocks: Step N.X)_` or `_(after: Step N.X)_`; repo edits, SDK wiring, generated assets, local commands, tests, audits, and authenticated CLI\u002FAPI work stay in `tasks\u002Ftodo.md`.\n- One-time condition-gated records, baselines, or future measurements go in `tasks\u002Frecord-todo.md` with source, condition, non-blocking reason, evidence, and promotion rule.\n- Cadence-based reviews, playtests, adoption checks, investor updates, retros, or docs-health checks go in `tasks\u002Frecurring-todo.md` with cadence, owner\u002Fagent, next due, evidence path, and escalation conditions.\n- Do not put non-blocking records or recurring obligations in `tasks\u002Ftodo.md` unless they have been explicitly promoted into current execution work.\n\n## Constraints\n\n- **One hypothesis per experiment.** If the user has multiple things to test, design separate experiments. Don't bundle.\n- **Cheap and fast.** Every experiment should be completable in 1-4 weeks with minimal budget. If the design is expensive or slow, simplify.\n- **Specific success criteria.** \"Users like it\" is not a success criterion. \"≥40% of landing page visitors click 'Get Early Access'\" is.\n- **Present before writing.** Never write output files until the experiment design has been presented and validated.\n- **Include decision rules.** Every experiment must specify what happens for each possible outcome. No experiment should end with \"we'll figure it out.\"\n- **Reference benchmarks.** Success thresholds should be grounded in industry benchmarks or competitor data, not arbitrary numbers.\n- **Don't overdesign.** A simple survey can validate an assumption just as well as an elaborate A\u002FB test. Recommend the simplest method that produces a clear signal.\n\n## Alignment Page\n\nFollow the shared Alignment Page convention in CLAUDE.md. Output: `alignment\u002Fexperiment-{topic}.html`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":27,"version":41,"description":7,"argument-hint":42},"v0.1","\u003Chypothesis or assumption to test>","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fbusiness-growth\u002Fcodex\u002Fexperiment\u002Farchive\u002Fv0.1",0,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills","https:\u002F\u002Fagentic-skills-blush.vercel.app","https:\u002F\u002Fgithub.com\u002FGeorgeQLe","georgeqle.com","George Le is a futurist and serial tech entrepreneur who wants to work toward a world where humanity is free from robotic tasks.","2026-11-10 04:07:24",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill experiment",{"tool":59,"command":60},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill experiment",{"tool":62,"command":63},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill experiment","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fbusiness-growth\u002Fcodex\u002Fexperiment\u002Farchive\u002Fv0.1\u002FSKILL.md",true,[],[68,80,90,102,115,126],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":36},"01M6G0NJES15RJKZE6YZ0TSYGF","source-checkout-allowed","Valid source-checkout-only fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fsource-checkout-allowed\u002FSKILL.md",[],[75,76,77,78,33,79],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":36},"01M6G0NFZ3R1MNB1E3DVTM0WB7","deck-install-valid","Valid deck install fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fdeck-install\u002FSKILL.md",[],[87,88,89,79,77,33],"deck install valid","deck","install",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":36},"01M6G0ND3QZQC4MDZ9NVB97PT2","codex-pack-guard-valid","Valid Codex Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-pack-guard\u002FSKILL.md",[],[97,98,99,79,100,101,77,33],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":111,"publishedAt":36},"01M6G0NA9YB3NKGZKD3S96JMNB","codex-missing-skill-valid","Valid Codex missing skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-missing-skill-fallback\u002FSKILL.md",[108],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[112,113,79,100,33,114,77],"codex missing skill valid","missing","fallback",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":122,"publishedAt":36},"01M6G0N7PC0EKFD40ZWQAXSAQ9","codex-base-skill-fallback-valid","Valid Codex base skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-base-skill-fallback\u002FSKILL.md",[121],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[79,100,114,123,124,125,33,77],"base skill","codex base skill fallback valid","base",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":36},"01M6G0N4VRR2YKZQ6N3Y6S2BQA","claude-pack-guard-valid","Valid Claude Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fclaude-pack-guard\u002FSKILL.md",[],[79,99,98,133,101,33,77],"claude pack guard valid"]