[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ACK9F2H02P3P93FAF464DQ":3,"skill-same:01M6ACK9F2H02P3P93FAF464DQ":78},{"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":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6ACK9F2H02P3P93FAF464DQ","hamilton-integrations",null,"Hamilton integration patterns for Airflow, Dagster, FastAPI, Streamlit, Jupyter notebooks, and other frameworks. Use when integrating Hamilton with other tools.","apache\u002Fhamilton","apache","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47359?v=4","01M6AC83E6K4FDKK7HZ8WNMQKE","The Apache Software Foundation","01M6ACK0BE2X7FDAV10PJHXW1W",2628,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fapache\u002Fhamilton\u002Fblob\u002Fmain\u002F.claude-plugin\u002Fskills\u002Fintegrations\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"hamilton integrations","integrations","jupyter","when","for","true","with","dagster","false","frameworks","patterns","use","fastapi","python","read","grep","Bash","Tools","integration","jupyter notebooks","airflow","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":50,"type":51,"version":52,"description":53,"argument-hint":54},"experiment","planning","v0.1","Design lean validation experiments — hypothesis, method, success criteria, sample size, timeline, and decision rules","\u003Chypothesis or assumption to test>","master","96e2912af886dd1606b1b97df707715aef062b02",".claude-plugin\u002Fskills\u002Fintegrations",231,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fhamilton","https:\u002F\u002Fhamilton.apache.org\u002F","https:\u002F\u002Fgithub.com\u002Fapache","https:\u002F\u002Fwww.apache.org\u002F","2026-11-10 01:52:20",{"source":8,"skillName":50,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add apache\u002Fhamilton --skill experiment",{"tool":70,"command":71},"bunx","bunx skills add apache\u002Fhamilton --skill experiment",{"tool":73,"command":74},"pnpm","pnpm dlx skills add apache\u002Fhamilton --skill experiment","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Fhamilton\u002Fblob\u002Fmain\u002F.claude-plugin\u002Fskills\u002Fintegrations\u002FSKILL.md",true,[],[79,100,116,138,159,179],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":86,"publishedAt":45},"01M6ACKMNJ1SZJESEPW7MABKW9","hamilton-scale","Performance and parallelization patterns for Hamilton including async I\u002FO, Spark, Ray, Dask, caching, and multithreading. Use for scaling Hamilton workflows.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fhamilton\u002Fblob\u002Fmain\u002F.claude-plugin\u002Fskills\u002Fscale\u002FSKILL.md",[85],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[87,88,37,89,90,91,92,93,40,94,38,35,95,96,34,97,98,32,29,28,99],"hamilton scale","scale","performance","workflows","spark","Ray","dask","parallelization","async","pytest","caching","scaling","multithreading",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":45},"01M6ACKHPW268MEH4MYY0Q91W1","hamilton-observability","Hamilton UI and SDK patterns for tracking, monitoring, and debugging dataflows. Use for observability, lineage tracking, and production monitoring.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fhamilton\u002Fblob\u002Fmain\u002F.claude-plugin\u002Fskills\u002Fobservability\u002FSKILL.md",[],[107,108,37,109,110,111,112,113,114,40,39,38,115,35,34,32,29,28],"observability","hamilton observability","sdk","debugging","lineage","ui","monitoring","Production","tracking",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":125,"publishedAt":45},"01M6ACKEWF1TGHNCVPTJ9HQTDQ","hamilton-mcp","Interactive Hamilton DAG development via MCP tools. Validate, visualize, scaffold, and execute Hamilton pipelines without leaving the conversation. Use when building or debugging Hamilton dataflows interactively.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fhamilton\u002Fblob\u002Fmain\u002F.claude-plugin\u002Fskills\u002Fmcp\u002FSKILL.md",[122],{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[126,127,37,128,129,130,131,110,132,133,41,40,39,38,134,35,135,32,136,29,137,27],"MCP","hamilton mcp","visualize","dag","validate","scaffold","development","mcp tools","interactive","conversation","via","pip",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":146,"publishedAt":45},"01M6ACKC8346RJXKRZE4KJRT3X","hamilton-llm","LLM and AI workflow patterns for Hamilton including RAG pipelines, embeddings, vector databases, and prompt engineering. Use for building AI applications with Hamilton.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fhamilton\u002Fblob\u002Fmain\u002F.claude-plugin\u002Fskills\u002Fllm\u002FSKILL.md",[144,145],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},[147,37,148,149,150,151,152,153,40,154,38,35,155,96,156,34,157,158,32,29,28],"hamilton llm","prompt engineering","workflow","rag","vector","embeddings","applications","prompt","databases","workflow patterns","AI workflow","vector databases",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":166,"publishedAt":45},"01M6ACK6JDEDAR8QMCHKJ7MD08","hamilton-dev-workflow","Systematic 5-step workflow for building Hamilton DAGs - DOT graphs, signatures, validation, TDD implementation. Use this workflow when creating new Hamilton modules from scratch.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fhamilton\u002Fblob\u002Fmain\u002F.claude-plugin\u002Fskills\u002Fhamilton-dev-workflow\u002FSKILL.md",[165],{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},[149,167,168,169,37,170,171,40,38,35,172,173,96,174,175,32,176,29,28,177,27,178],"dev","hamilton dev workflow","dev workflow","tdd","validation","dot","modules","signatures","systematic","From Scratch","scratch","new",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":189,"publishedAt":45},"01M6ACK3D2QMS55YDKB6QEMSQC","hamilton-core","Core Hamilton patterns for creating DAGs, applying decorators, testing, and debugging dataflows. Use for basic Hamilton development tasks.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fhamilton\u002Fblob\u002Fmain\u002F.claude-plugin\u002Fskills\u002Fcore\u002FSKILL.md",[185,188],{"categoryNo":186,"categoryName":187,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[190,191,192,37,110,193,132,40,39,38,35,96,34,194,32,195,29,28],"core","hamilton core","testing","tasks","basic","decorators"]