[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M718AHZNEE1VEZ072YRDSVZ5":3,"skill-same:01M718AHZNEE1VEZ072YRDSVZ5":77},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M718AHZNEE1VEZ072YRDSVZ5","validate-data",null,"QA an analysis before sharing -- methodology, accuracy, and bias checks. Use when reviewing an analysis before a stakeholder presentation, spot-checking calculations and aggregation logic, verifying a SQL query's results look right, or assessing whether conclusions are actually supported by the data.","anthropics\u002Fknowledge-work-plugins","anthropics","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F76263028?v=4","01M697XGDPXJAVQ8391V2BCYTE","Anthropic","01M7188MPC48111TN566QNQE3X",35660,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fvalidate-data\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"data","validate","validate data","methodology","sharing","aggregation","spot","logic","results","use","bias","accuracy","presentation","sql","review","analysis","query","sql query","when","qa","2026-11-10 10:12:30",false,"---\nname: validate-data\ndescription: QA an analysis before sharing -- methodology, accuracy, and bias checks. Use when reviewing an analysis before a stakeholder presentation, spot-checking calculations and aggregation logic, verifying a SQL query's results look right, or assessing whether conclusions are actually supported by the data.\nargument-hint: \"\u003Canalysis to review>\"\n---\n\n# \u002Fvalidate-data - Validate Analysis Before Sharing\n\n> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](..\u002F..\u002FCONNECTORS.md).\n\nReview an analysis for accuracy, methodology, and potential biases before sharing with stakeholders. Generates a confidence assessment and improvement suggestions.\n\n## Usage\n\n```\n\u002Fvalidate-data \u003Canalysis to review>\n```\n\nThe analysis can be:\n- A document or report in the conversation\n- A file (markdown, notebook, spreadsheet)\n- SQL queries and their results\n- Charts and their underlying data\n- A description of methodology and findings\n\n## Workflow\n\n### 1. Review Methodology and Assumptions\n\nExamine:\n\n- **Question framing**: Is the analysis answering the right question? Could the question be interpreted differently?\n- **Data selection**: Are the right tables\u002Fdatasets being used? Is the time range appropriate?\n- **Population definition**: Is the analysis population correctly defined? Are there unintended exclusions?\n- **Metric definitions**: Are metrics defined clearly and consistently? Do they match how stakeholders understand them?\n- **Baseline and comparison**: Is the comparison fair? Are time periods, cohort sizes, and contexts comparable?\n\n### 2. Run the Pre-Delivery QA Checklist\n\nWork through the checklist below — data quality, calculation, reasonableness, and presentation checks.\n\n### 3. Check for Common Analytical Pitfalls\n\nSystematically review against the detailed pitfall catalog below (join explosion, survivorship bias, incomplete period comparison, denominator shifting, average of averages, timezone mismatches, selection bias).\n\n### 4. Verify Calculations and Aggregations\n\nWhere possible, spot-check:\n\n- Recalculate a few key numbers independently\n- Verify that subtotals sum to totals\n- Check that percentages sum to 100% (or close to it) where expected\n- Confirm that YoY\u002FMoM comparisons use the correct base periods\n- Validate that filters are applied consistently across all metrics\n\nApply the result sanity-checking techniques below (magnitude checks, cross-validation, red-flag detection).\n\n### 5. Assess Visualizations\n\nIf the analysis includes charts:\n\n- Do axes start at appropriate values (zero for bar charts)?\n- Are scales consistent across comparison charts?\n- Do chart titles accurately describe what's shown?\n- Could the visualization mislead a quick reader?\n- Are there truncated axes, inconsistent intervals, or 3D effects that distort perception?\n\n### 6. Evaluate Narrative and Conclusions\n\nReview whether:\n\n- Conclusions are supported by the data shown\n- Alternative explanations are acknowledged\n- Uncertainty is communicated appropriately\n- Recommendations follow logically from findings\n- The level of confidence matches the strength of evidence\n\n### 7. Suggest Improvements\n\nProvide specific, actionable suggestions:\n\n- Additional analyses that would strengthen the conclusions\n- Caveats or limitations that should be noted\n- Better visualizations or framings for key points\n- Missing context that stakeholders would want\n\n### 8. Generate Confidence Assessment\n\nRate the analysis on a 3-level scale:\n\n**Ready to share** -- Analysis is methodologically sound, calculations verified, caveats noted. Minor suggestions for improvement but nothing blocking.\n\n**Share with noted caveats** -- Analysis is largely correct but has specific limitations or assumptions that must be communicated to stakeholders. List the required caveats.\n\n**Needs revision** -- Found specific errors, methodological issues, or missing analyses that should be addressed before sharing. List the required changes with priority order.\n\n## Output Format\n\n```\n## Validation Report\n\n### Overall Assessment: [Ready to share | Share with caveats | Needs revision]\n\n### Methodology Review\n[Findings about approach, data selection, definitions]\n\n### Issues Found\n1. [Severity: High\u002FMedium\u002FLow] [Issue description and impact]\n2. ...\n\n### Calculation Spot-Checks\n- [Metric]: [Verified \u002F Discrepancy found]\n- ...\n\n### Visualization Review\n[Any issues with charts or visual presentation]\n\n### Suggested Improvements\n1. [Improvement and why it matters]\n2. ...\n\n### Required Caveats for Stakeholders\n- [Caveat that must be communicated]\n- ...\n```\n\n---\n\n## Pre-Delivery QA Checklist\n\nRun through this checklist before sharing any analysis with stakeholders.\n\n### Data Quality Checks\n\n- [ ] **Source verification**: Confirmed which tables\u002Fdata sources were used. Are they the right ones for this question?\n- [ ] **Freshness**: Data is current enough for the analysis. Noted the \"as of\" date.\n- [ ] **Completeness**: No unexpected gaps in time series or missing segments.\n- [ ] **Null handling**: Checked null rates in key columns. Nulls are handled appropriately (excluded, imputed, or flagged).\n- [ ] **Deduplication**: Confirmed no double-counting from bad joins or duplicate source records.\n- [ ] **Filter verification**: All WHERE clauses and filters are correct. No unintended exclusions.\n\n### Calculation Checks\n\n- [ ] **Aggregation logic**: GROUP BY includes all non-aggregated columns. Aggregation level matches the analysis grain.\n- [ ] **Denominator correctness**: Rate and percentage calculations use the right denominator. Denominators are non-zero.\n- [ ] **Date alignment**: Comparisons use the same time period length. Partial periods are excluded or noted.\n- [ ] **Join correctness**: JOIN types are appropriate (INNER vs LEFT). Many-to-many joins haven't inflated counts.\n- [ ] **Metric definitions**: Metrics match how stakeholders define them. Any deviations are noted.\n- [ ] **Subtotals sum**: Parts add up to the whole where expected. If they don't, explain why (e.g., overlap).\n\n### Reasonableness Checks\n\n- [ ] **Magnitude**: Numbers are in a plausible range. Revenue isn't negative. Percentages are between 0-100%.\n- [ ] **Trend continuity**: No unexplained jumps or drops in time series.\n- [ ] **Cross-reference**: Key numbers match other known sources (dashboards, previous reports, finance data).\n- [ ] **Order of magnitude**: Total revenue is in the right ballpark. User counts match known figures.\n- [ ] **Edge cases**: What happens at the boundaries? Empty segments, zero-activity periods, new entities.\n\n### Presentation Checks\n\n- [ ] **Chart accuracy**: Bar charts start at zero. Axes are labeled. Scales are consistent across panels.\n- [ ] **Number formatting**: Appropriate precision. Consistent currency\u002Fpercentage formatting. Thousands separators where needed.\n- [ ] **Title clarity**: Titles state the insight, not just the metric. Date ranges are specified.\n- [ ] **Caveat transparency**: Known limitations and assumptions are stated explicitly.\n- [ ] **Reproducibility**: Someone else could recreate this analysis from the documentation provided.\n\n## Common Data Analysis Pitfalls\n\n### Join Explosion\n\n**The problem**: A many-to-many join silently multiplies rows, inflating counts and sums.\n\n**How to detect**:\n```sql\n-- Check row count before and after join\nSELECT COUNT(*) FROM table_a;  -- 1,000\nSELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id;  -- 3,500 (uh oh)\n```\n\n**How to prevent**:\n- Always check row counts after joins\n- If counts increase, investigate the join relationship (is it really 1:1 or 1:many?)\n- Use `COUNT(DISTINCT a.id)` instead of `COUNT(*)` when counting entities through joins\n\n### Survivorship Bias\n\n**The problem**: Analyzing only entities that exist today, ignoring those that were deleted, churned, or failed.\n\n**Examples**:\n- Analyzing user behavior of \"current users\" misses churned users\n- Looking at \"companies using our product\" ignores those who evaluated and left\n- Studying properties of \"successful\" outcomes without \"unsuccessful\" ones\n\n**How to prevent**: Ask \"who is NOT in this dataset?\" before drawing conclusions.\n\n### Incomplete Period Comparison\n\n**The problem**: Comparing a partial period to a full period.\n\n**Examples**:\n- \"January revenue is $500K vs. December's $800K\" -- but January isn't over yet\n- \"This week's signups are down\" -- checked on Wednesday, comparing to a full prior week\n\n**How to prevent**: Always filter to complete periods, or compare same-day-of-month \u002F same-number-of-days.\n\n### Denominator Shifting\n\n**The problem**: The denominator changes between periods, making rates incomparable.\n\n**Examples**:\n- Conversion rate improves because you changed how you count \"eligible\" users\n- Churn rate changes because the definition of \"active\" was updated\n\n**How to prevent**: Use consistent definitions across all compared periods. Note any definition changes.\n\n### Average of Averages\n\n**The problem**: Averaging pre-computed averages gives wrong results when group sizes differ.\n\n**Example**:\n- Group A: 100 users, average revenue $50\n- Group B: 10 users, average revenue $200\n- Wrong: Average of averages = ($50 + $200) \u002F 2 = $125\n- Right: Weighted average = (100*$50 + 10*$200) \u002F 110 = $63.64\n\n**How to prevent**: Always aggregate from raw data. Never average pre-aggregated averages.\n\n### Timezone Mismatches\n\n**The problem**: Different data sources use different timezones, causing misalignment.\n\n**Examples**:\n- Event timestamps in UTC vs. user-facing dates in local time\n- Daily rollups that use different cutoff times\n\n**How to prevent**: Standardize all timestamps to a single timezone (UTC recommended) before analysis. Document the timezone used.\n\n### Selection Bias in Segmentation\n\n**The problem**: Segments are defined by the outcome you're measuring, creating circular logic.\n\n**Examples**:\n- \"Users who completed onboarding have higher retention\" -- obviously, they self-selected\n- \"Power users generate more revenue\" -- they became power users BY generating revenue\n\n**How to prevent**: Define segments based on pre-treatment characteristics, not outcomes.\n\n### Other Statistical Traps\n\n- **Simpson's paradox**: Trend reverses when data is aggregated vs. segmented\n- **Correlation presented as causation** without supporting evidence\n- **Small sample sizes** leading to unreliable conclusions\n- **Outliers disproportionately affecting averages** (should medians be used instead?)\n- **Multiple testing \u002F cherry-picking** significant results\n- **Look-ahead bias**: Using future information to explain past events\n- **Cherry-picked time ranges** that favor a particular narrative\n\n## Result Sanity Checking\n\n### Magnitude Checks\n\nFor any key number in your analysis, verify it passes the \"smell test\":\n\n| Metric Type | Sanity Check |\n|---|---|\n| User counts | Does this match known MAU\u002FDAU figures? |\n| Revenue | Is this in the right order of magnitude vs. known ARR? |\n| Conversion rates | Is this between 0% and 100%? Does it match dashboard figures? |\n| Growth rates | Is 50%+ MoM growth realistic, or is there a data issue? |\n| Averages | Is the average reasonable given what you know about the distribution? |\n| Percentages | Do segment percentages sum to ~100%? |\n\n### Cross-Validation Techniques\n\n1. **Calculate the same metric two different ways** and verify they match\n2. **Spot-check individual records** -- pick a few specific entities and trace their data manually\n3. **Compare to known benchmarks** -- match against published dashboards, finance reports, or prior analyses\n4. **Reverse engineer** -- if total revenue is X, does per-user revenue times user count approximately equal X?\n5. **Boundary checks** -- what happens when you filter to a single day, a single user, or a single category? Are those micro-results sensible?\n\n### Red Flags That Warrant Investigation\n\n- Any metric that changed by more than 50% period-over-period without an obvious cause\n- Counts or sums that are exact round numbers (suggests a filter or default value issue)\n- Rates exactly at 0% or 100% (may indicate incomplete data)\n- Results that perfectly confirm the hypothesis (reality is usually messier)\n- Identical values across time periods or segments (suggests the query is ignoring a dimension)\n\n## Documentation Standards for Reproducibility\n\n### Analysis Documentation Template\n\nEvery non-trivial analysis should include:\n\n```markdown\n## Analysis: [Title]\n\n### Question\n[The specific question being answered]\n\n### Data Sources\n- Table: [schema.table_name] (as of [date])\n- Table: [schema.other_table] (as of [date])\n- File: [filename] (source: [where it came from])\n\n### Definitions\n- [Metric A]: [Exactly how it's calculated]\n- [Segment X]: [Exactly how membership is determined]\n- [Time period]: [Start date] to [end date], [timezone]\n\n### Methodology\n1. [Step 1 of the analysis approach]\n2. [Step 2]\n3. [Step 3]\n\n### Assumptions and Limitations\n- [Assumption 1 and why it's reasonable]\n- [Limitation 1 and its potential impact on conclusions]\n\n### Key Findings\n1. [Finding 1 with supporting evidence]\n2. [Finding 2 with supporting evidence]\n\n### SQL Queries\n[All queries used, with comments]\n\n### Caveats\n- [Things the reader should know before acting on this]\n```\n\n### Code Documentation\n\nFor any code (SQL, Python) that may be reused:\n\n```python\n\"\"\"\nAnalysis: Monthly Cohort Retention\nAuthor: [Name]\nDate: [Date]\nData Source: events table, users table\nLast Validated: [Date] -- results matched dashboard within 2%\n\nPurpose:\n    Calculate monthly user retention cohorts based on first activity date.\n\nAssumptions:\n    - \"Active\" means at least one event in the month\n    - Excludes test\u002Finternal accounts (user_type != 'internal')\n    - Uses UTC dates throughout\n\nOutput:\n    Cohort retention matrix with cohort_month rows and months_since_signup columns.\n    Values are retention rates (0-100%).\n\"\"\"\n```\n\n### Version Control for Analyses\n\n- Save queries and code in version control (git) or a shared docs system\n- Note the date of the data snapshot used\n- If an analysis is re-run with updated data, document what changed and why\n- Link to prior versions of recurring analyses for trend comparison\n\n## Examples\n\n```\n\u002Fvalidate-data Review this quarterly revenue analysis before I send it to the exec team: [analysis]\n```\n\n```\n\u002Fvalidate-data Check my churn analysis -- I'm comparing Q4 churn rates to Q3 but Q4 has a shorter measurement window\n```\n\n```\n\u002Fvalidate-data Here's a SQL query and its results for our conversion funnel. Does the logic look right? [query + results]\n```\n\n## Tips\n\n- Run \u002Fvalidate-data before any high-stakes presentation or decision\n- Even quick analyses benefit from a sanity check -- it takes a minute and can save your credibility\n- If the validation finds issues, fix them and re-validate\n- Share the validation output alongside your analysis to build stakeholder confidence\n","# \u002Fvalidate-data - Validate Analysis Before Sharing\n\n> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](..\u002F..\u002FCONNECTORS.md).\n\nReview an analysis for accuracy, methodology, and potential biases before sharing with stakeholders. Generates a confidence assessment and improvement suggestions.\n\n## Usage\n\n```\n\u002Fvalidate-data \u003Canalysis to review>\n```\n\nThe analysis can be:\n- A document or report in the conversation\n- A file (markdown, notebook, spreadsheet)\n- SQL queries and their results\n- Charts and their underlying data\n- A description of methodology and findings\n\n## Workflow\n\n### 1. Review Methodology and Assumptions\n\nExamine:\n\n- **Question framing**: Is the analysis answering the right question? Could the question be interpreted differently?\n- **Data selection**: Are the right tables\u002Fdatasets being used? Is the time range appropriate?\n- **Population definition**: Is the analysis population correctly defined? Are there unintended exclusions?\n- **Metric definitions**: Are metrics defined clearly and consistently? Do they match how stakeholders understand them?\n- **Baseline and comparison**: Is the comparison fair? Are time periods, cohort sizes, and contexts comparable?\n\n### 2. Run the Pre-Delivery QA Checklist\n\nWork through the checklist below — data quality, calculation, reasonableness, and presentation checks.\n\n### 3. Check for Common Analytical Pitfalls\n\nSystematically review against the detailed pitfall catalog below (join explosion, survivorship bias, incomplete period comparison, denominator shifting, average of averages, timezone mismatches, selection bias).\n\n### 4. Verify Calculations and Aggregations\n\nWhere possible, spot-check:\n\n- Recalculate a few key numbers independently\n- Verify that subtotals sum to totals\n- Check that percentages sum to 100% (or close to it) where expected\n- Confirm that YoY\u002FMoM comparisons use the correct base periods\n- Validate that filters are applied consistently across all metrics\n\nApply the result sanity-checking techniques below (magnitude checks, cross-validation, red-flag detection).\n\n### 5. Assess Visualizations\n\nIf the analysis includes charts:\n\n- Do axes start at appropriate values (zero for bar charts)?\n- Are scales consistent across comparison charts?\n- Do chart titles accurately describe what's shown?\n- Could the visualization mislead a quick reader?\n- Are there truncated axes, inconsistent intervals, or 3D effects that distort perception?\n\n### 6. Evaluate Narrative and Conclusions\n\nReview whether:\n\n- Conclusions are supported by the data shown\n- Alternative explanations are acknowledged\n- Uncertainty is communicated appropriately\n- Recommendations follow logically from findings\n- The level of confidence matches the strength of evidence\n\n### 7. Suggest Improvements\n\nProvide specific, actionable suggestions:\n\n- Additional analyses that would strengthen the conclusions\n- Caveats or limitations that should be noted\n- Better visualizations or framings for key points\n- Missing context that stakeholders would want\n\n### 8. Generate Confidence Assessment\n\nRate the analysis on a 3-level scale:\n\n**Ready to share** -- Analysis is methodologically sound, calculations verified, caveats noted. Minor suggestions for improvement but nothing blocking.\n\n**Share with noted caveats** -- Analysis is largely correct but has specific limitations or assumptions that must be communicated to stakeholders. List the required caveats.\n\n**Needs revision** -- Found specific errors, methodological issues, or missing analyses that should be addressed before sharing. List the required changes with priority order.\n\n## Output Format\n\n```\n## Validation Report\n\n### Overall Assessment: [Ready to share | Share with caveats | Needs revision]\n\n### Methodology Review\n[Findings about approach, data selection, definitions]\n\n### Issues Found\n1. [Severity: High\u002FMedium\u002FLow] [Issue description and impact]\n2. ...\n\n### Calculation Spot-Checks\n- [Metric]: [Verified \u002F Discrepancy found]\n- ...\n\n### Visualization Review\n[Any issues with charts or visual presentation]\n\n### Suggested Improvements\n1. [Improvement and why it matters]\n2. ...\n\n### Required Caveats for Stakeholders\n- [Caveat that must be communicated]\n- ...\n```\n\n---\n\n## Pre-Delivery QA Checklist\n\nRun through this checklist before sharing any analysis with stakeholders.\n\n### Data Quality Checks\n\n- [ ] **Source verification**: Confirmed which tables\u002Fdata sources were used. Are they the right ones for this question?\n- [ ] **Freshness**: Data is current enough for the analysis. Noted the \"as of\" date.\n- [ ] **Completeness**: No unexpected gaps in time series or missing segments.\n- [ ] **Null handling**: Checked null rates in key columns. Nulls are handled appropriately (excluded, imputed, or flagged).\n- [ ] **Deduplication**: Confirmed no double-counting from bad joins or duplicate source records.\n- [ ] **Filter verification**: All WHERE clauses and filters are correct. No unintended exclusions.\n\n### Calculation Checks\n\n- [ ] **Aggregation logic**: GROUP BY includes all non-aggregated columns. Aggregation level matches the analysis grain.\n- [ ] **Denominator correctness**: Rate and percentage calculations use the right denominator. Denominators are non-zero.\n- [ ] **Date alignment**: Comparisons use the same time period length. Partial periods are excluded or noted.\n- [ ] **Join correctness**: JOIN types are appropriate (INNER vs LEFT). Many-to-many joins haven't inflated counts.\n- [ ] **Metric definitions**: Metrics match how stakeholders define them. Any deviations are noted.\n- [ ] **Subtotals sum**: Parts add up to the whole where expected. If they don't, explain why (e.g., overlap).\n\n### Reasonableness Checks\n\n- [ ] **Magnitude**: Numbers are in a plausible range. Revenue isn't negative. Percentages are between 0-100%.\n- [ ] **Trend continuity**: No unexplained jumps or drops in time series.\n- [ ] **Cross-reference**: Key numbers match other known sources (dashboards, previous reports, finance data).\n- [ ] **Order of magnitude**: Total revenue is in the right ballpark. User counts match known figures.\n- [ ] **Edge cases**: What happens at the boundaries? Empty segments, zero-activity periods, new entities.\n\n### Presentation Checks\n\n- [ ] **Chart accuracy**: Bar charts start at zero. Axes are labeled. Scales are consistent across panels.\n- [ ] **Number formatting**: Appropriate precision. Consistent currency\u002Fpercentage formatting. Thousands separators where needed.\n- [ ] **Title clarity**: Titles state the insight, not just the metric. Date ranges are specified.\n- [ ] **Caveat transparency**: Known limitations and assumptions are stated explicitly.\n- [ ] **Reproducibility**: Someone else could recreate this analysis from the documentation provided.\n\n## Common Data Analysis Pitfalls\n\n### Join Explosion\n\n**The problem**: A many-to-many join silently multiplies rows, inflating counts and sums.\n\n**How to detect**:\n```sql\n-- Check row count before and after join\nSELECT COUNT(*) FROM table_a;  -- 1,000\nSELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id;  -- 3,500 (uh oh)\n```\n\n**How to prevent**:\n- Always check row counts after joins\n- If counts increase, investigate the join relationship (is it really 1:1 or 1:many?)\n- Use `COUNT(DISTINCT a.id)` instead of `COUNT(*)` when counting entities through joins\n\n### Survivorship Bias\n\n**The problem**: Analyzing only entities that exist today, ignoring those that were deleted, churned, or failed.\n\n**Examples**:\n- Analyzing user behavior of \"current users\" misses churned users\n- Looking at \"companies using our product\" ignores those who evaluated and left\n- Studying properties of \"successful\" outcomes without \"unsuccessful\" ones\n\n**How to prevent**: Ask \"who is NOT in this dataset?\" before drawing conclusions.\n\n### Incomplete Period Comparison\n\n**The problem**: Comparing a partial period to a full period.\n\n**Examples**:\n- \"January revenue is $500K vs. December's $800K\" -- but January isn't over yet\n- \"This week's signups are down\" -- checked on Wednesday, comparing to a full prior week\n\n**How to prevent**: Always filter to complete periods, or compare same-day-of-month \u002F same-number-of-days.\n\n### Denominator Shifting\n\n**The problem**: The denominator changes between periods, making rates incomparable.\n\n**Examples**:\n- Conversion rate improves because you changed how you count \"eligible\" users\n- Churn rate changes because the definition of \"active\" was updated\n\n**How to prevent**: Use consistent definitions across all compared periods. Note any definition changes.\n\n### Average of Averages\n\n**The problem**: Averaging pre-computed averages gives wrong results when group sizes differ.\n\n**Example**:\n- Group A: 100 users, average revenue $50\n- Group B: 10 users, average revenue $200\n- Wrong: Average of averages = ($50 + $200) \u002F 2 = $125\n- Right: Weighted average = (100*$50 + 10*$200) \u002F 110 = $63.64\n\n**How to prevent**: Always aggregate from raw data. Never average pre-aggregated averages.\n\n### Timezone Mismatches\n\n**The problem**: Different data sources use different timezones, causing misalignment.\n\n**Examples**:\n- Event timestamps in UTC vs. user-facing dates in local time\n- Daily rollups that use different cutoff times\n\n**How to prevent**: Standardize all timestamps to a single timezone (UTC recommended) before analysis. Document the timezone used.\n\n### Selection Bias in Segmentation\n\n**The problem**: Segments are defined by the outcome you're measuring, creating circular logic.\n\n**Examples**:\n- \"Users who completed onboarding have higher retention\" -- obviously, they self-selected\n- \"Power users generate more revenue\" -- they became power users BY generating revenue\n\n**How to prevent**: Define segments based on pre-treatment characteristics, not outcomes.\n\n### Other Statistical Traps\n\n- **Simpson's paradox**: Trend reverses when data is aggregated vs. segmented\n- **Correlation presented as causation** without supporting evidence\n- **Small sample sizes** leading to unreliable conclusions\n- **Outliers disproportionately affecting averages** (should medians be used instead?)\n- **Multiple testing \u002F cherry-picking** significant results\n- **Look-ahead bias**: Using future information to explain past events\n- **Cherry-picked time ranges** that favor a particular narrative\n\n## Result Sanity Checking\n\n### Magnitude Checks\n\nFor any key number in your analysis, verify it passes the \"smell test\":\n\n| Metric Type | Sanity Check |\n|---|---|\n| User counts | Does this match known MAU\u002FDAU figures? |\n| Revenue | Is this in the right order of magnitude vs. known ARR? |\n| Conversion rates | Is this between 0% and 100%? Does it match dashboard figures? |\n| Growth rates | Is 50%+ MoM growth realistic, or is there a data issue? |\n| Averages | Is the average reasonable given what you know about the distribution? |\n| Percentages | Do segment percentages sum to ~100%? |\n\n### Cross-Validation Techniques\n\n1. **Calculate the same metric two different ways** and verify they match\n2. **Spot-check individual records** -- pick a few specific entities and trace their data manually\n3. **Compare to known benchmarks** -- match against published dashboards, finance reports, or prior analyses\n4. **Reverse engineer** -- if total revenue is X, does per-user revenue times user count approximately equal X?\n5. **Boundary checks** -- what happens when you filter to a single day, a single user, or a single category? Are those micro-results sensible?\n\n### Red Flags That Warrant Investigation\n\n- Any metric that changed by more than 50% period-over-period without an obvious cause\n- Counts or sums that are exact round numbers (suggests a filter or default value issue)\n- Rates exactly at 0% or 100% (may indicate incomplete data)\n- Results that perfectly confirm the hypothesis (reality is usually messier)\n- Identical values across time periods or segments (suggests the query is ignoring a dimension)\n\n## Documentation Standards for Reproducibility\n\n### Analysis Documentation Template\n\nEvery non-trivial analysis should include:\n\n```markdown\n## Analysis: [Title]\n\n### Question\n[The specific question being answered]\n\n### Data Sources\n- Table: [schema.table_name] (as of [date])\n- Table: [schema.other_table] (as of [date])\n- File: [filename] (source: [where it came from])\n\n### Definitions\n- [Metric A]: [Exactly how it's calculated]\n- [Segment X]: [Exactly how membership is determined]\n- [Time period]: [Start date] to [end date], [timezone]\n\n### Methodology\n1. [Step 1 of the analysis approach]\n2. [Step 2]\n3. [Step 3]\n\n### Assumptions and Limitations\n- [Assumption 1 and why it's reasonable]\n- [Limitation 1 and its potential impact on conclusions]\n\n### Key Findings\n1. [Finding 1 with supporting evidence]\n2. [Finding 2 with supporting evidence]\n\n### SQL Queries\n[All queries used, with comments]\n\n### Caveats\n- [Things the reader should know before acting on this]\n```\n\n### Code Documentation\n\nFor any code (SQL, Python) that may be reused:\n\n```python\n\"\"\"\nAnalysis: Monthly Cohort Retention\nAuthor: [Name]\nDate: [Date]\nData Source: events table, users table\nLast Validated: [Date] -- results matched dashboard within 2%\n\nPurpose:\n    Calculate monthly user retention cohorts based on first activity date.\n\nAssumptions:\n    - \"Active\" means at least one event in the month\n    - Excludes test\u002Finternal accounts (user_type != 'internal')\n    - Uses UTC dates throughout\n\nOutput:\n    Cohort retention matrix with cohort_month rows and months_since_signup columns.\n    Values are retention rates (0-100%).\n\"\"\"\n```\n\n### Version Control for Analyses\n\n- Save queries and code in version control (git) or a shared docs system\n- Note the date of the data snapshot used\n- If an analysis is re-run with updated data, document what changed and why\n- Link to prior versions of recurring analyses for trend comparison\n\n## Examples\n\n```\n\u002Fvalidate-data Review this quarterly revenue analysis before I send it to the exec team: [analysis]\n```\n\n```\n\u002Fvalidate-data Check my churn analysis -- I'm comparing Q4 churn rates to Q3 but Q4 has a shorter measurement window\n```\n\n```\n\u002Fvalidate-data Here's a SQL query and its results for our conversion funnel. Does the logic look right? [query + results]\n```\n\n## Tips\n\n- Run \u002Fvalidate-data before any high-stakes presentation or decision\n- Even quick analyses benefit from a sanity check -- it takes a minute and can save your credibility\n- If the validation finds issues, fix them and re-validate\n- Share the validation output alongside your analysis to build stakeholder confidence\n",{"name":5,"description":7,"argument-hint":54},"\u003Canalysis to review>","main","e605d8ddbfb688da57dfaaceebd93f12a64ef1d3","data\u002Fskills\u002Fvalidate-data",3944,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins","https:\u002F\u002Fgithub.com\u002Fanthropics","https:\u002F\u002Fanthropic.com","2026-11-14 06:21:52",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add anthropics\u002Fknowledge-work-plugins --skill validate-data",{"tool":69,"command":70},"bunx","bunx skills add anthropics\u002Fknowledge-work-plugins --skill validate-data",{"tool":72,"command":73},"pnpm","pnpm dlx skills add anthropics\u002Fknowledge-work-plugins --skill validate-data","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fdata\u002Fskills\u002Fvalidate-data\u002FSKILL.md",true,[],[78,104,129,152,179,205],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":49},"01M718Y97HCGW12Q53PSJDY03W","ticket-deflector","Reads a forwarded customer email or ticket, pulls order and refund status from a payments connector (PayPal, Square, or Stripe) or Shopify, account history from the CRM, and open tickets from a support desk (Zoho Desk), drafts a tone-matched reply in the owner's writing voice, and can issue a refund through the payments connector with explicit owner approval. With Shopify connected it also runs a proactive order-triage mode that surfaces orders needing attention — unfulfilled past the promised window, payment problems, pending refunds, stuck shipments — and drafts the next action for each before the customer has to ask. Use when the user says \"draft a response,\" \"answer this customer,\" \"where's my order,\" \"I want a refund,\" \"check my orders,\" or \"anything about to blow up.\"","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Fticket-deflector\u002FSKILL.md",[],[85,86,87,88,89,90,91,47,92,93,94,95,96,97,98,99,100,101,102,103],"ticket","ticket deflector","mode","up","payments","open","writing","workflow","ask","Connector","text","mail","window","next","customer","support","crm","past","read",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":49},"01M718Y55HFAN5705ME5VEDZ9K","tax-season-organizer","Prepares tax-season materials for the owner's accountant, not tax advice. US federal tax; a non-US business gets its closed-books packet instead. Two modes: (1) quarterly estimated tax from YTD net income in the ledger (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books); (2) year-end 1099 prep, scanning the ledger, PayPal, and Stripe for contractors paid over USD 600 into a 1099-NEC list with missing W-9 flags.\nAny tax request routes first to \u002Ftax-prep, which confirms the books are closed and reconciled before running this skill. Use this skill directly only when the owner says the period's books are already closed: \"books are closed, now do the 1099s,\" \"run the quarterly estimate off the closed numbers,\" or \"just the contractor W-9 list.\"","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Ftax-season-organizer\u002FSKILL.md",[],[111,112,113,114,115,116,117,118,119,120,47,121,122,123,124,125,103,126,127,128],"tax season organizer","tax","us federal","which","netsuite","paid","end","usd","only","now","books","xero","scanning","run","request","flags","list","stripe",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":49},"01M718Y13VVPHDD9NTDBVFJ2AZ","tax-prep","Prepares tax materials as a two-link chain — month-end-prep confirms the books are closed and reconciled first, then tax-season-organizer calculates the quarterly estimated payment or builds the year-end 1099-NEC list and accountant packet from those closed numbers. Requires a ledger (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books); uses Gusto, PayPal, and Stripe when connected, else CSV upload. US federal tax math; a non-US business gets the closed-books packet. Prep material for a CPA, never tax advice, nothing filed. Trigger on \"quarterly taxes,\" \"estimated tax payment,\" \"how much should I set aside,\" \"1099s,\" \"1099-NEC,\" \"W-9s,\" \"year-end tax prep,\" \"get my books ready for my accountant,\" any phrasing that suggests a tax deadline is coming, or a question about net profit or YTD income that sounds like worry about a tax bill. An owner who says the period's books are already closed routes to tax-season-organizer directly.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Ftax-prep\u002FSKILL.md",[],[136,112,137,138,113,139,140,115,141,142,143,144,145,146,147,117,148,149,150,151],"tax prep","prep","SET","as","ready","never","zoho books","get","chain","profit","for","trigger","material","question","paypal","business",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":161,"publishedAt":49},"01M718XWTWQZ01GYSG9T8RW8TW","speed-to-lead","Makes sure no inbound lead goes unanswered. Watches web forms, the shared inbox, and the CRM for new inquiries, qualifies each one against the owner's criteria, drafts a reply in the owner's voice with real meeting times for the owner to approve and send, routes anything hot to a human right away, and logs the whole thing to the CRM. Never sends on its own. Built to run on a schedule so overnight inquiries are drafted and sorted by morning, and works from forwarded or pasted inquiries when no connector is available. Use this whenever the owner is worried about inbound leads or response time — including phrasings like \"leads are going cold,\" \"did anyone answer that inquiry,\" \"I keep missing form submissions,\" \"nothing falls through the cracks,\" \"handle my inbound,\" \"respond to this lead,\" or \"we lose people because nobody gets back fast enough.\" Reach for it for a single unanswered inquiry as readily as for a standing setup.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Fspeed-to-lead\u002FSKILL.md",[158],{"categoryNo":159,"categoryName":160,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000034","行政与办公人员",[162,163,164,165,166,167,141,168,169,170,171,172,173,174,47,175,176,94,177,178],"speed to lead","lead","speed","shared","back","cold","time","inbox","send","respond","new","web forms","people","schedule","logs","sure","human",{"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":188,"publishedAt":49},"01M718XQYMN1KY3TPS33967FK0","social-content-engine","Runs the owner's content operation as a standing thing rather than a one-off: keeps a rolling posting calendar, learns the owner's voice, generates on-brand Canva graphics, writes captions that sound like them, repurposes one asset into every channel format, and stages posts for approval instead of publishing on its own. Pulls product photos and prices from Shopify when connected; with no connectors, drafts the calendar and asset briefs for manual posting. Use this whenever the owner talks about posting, content, or social — including \"I need to post more,\" \"we've gone quiet on Instagram,\" \"what should we post this month,\" \"make the content,\" \"give me a month of posts,\" \"write this in my voice,\" \"repurpose this,\" or \"set up our content calendar.\" Reach for it for a single post as readily as for a full quarter. One handoff: a finished, approved campaign brief goes to canva-creator; this skill owns the standing operation.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Fsocial-content-engine\u002FSKILL.md",[185],{"categoryNo":186,"categoryName":187,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[189,190,191,192,193,194,138,195,196,197,198,88,199,47,200,201,202,103,203,204],"social","social content engine","engine","content engine","social content","content","brief","posts","Captions","prices","campaign","me","product","calendar","write","drafts",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":211,"publishedAt":49},"01M718XMPJVH0EVRVP998BVZPC","smb-router","The front door to the Small Business plugin. Listens to what the owner needs right now — vague or specific — and routes them to the best skill or slash command for the moment. Also serves as a guide: explains what's available, suggests what to try next, and adapts recommendations based on stored business context. Trigger whenever the owner asks \"what can you do,\" \"help me with my business,\" \"what should I focus on,\" \"I don't know where to start,\" or any open-ended business request that doesn't clearly match a single skill.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\u002Fblob\u002Fmain\u002Fsmall-business\u002Fskills\u002Fsmb-router\u002FSKILL.md",[],[212,213,214,139,215,146,147,216,90,217,120,151,218,219,220,221,222,200,223,98],"router","smb","smb router","do","front","single","you","vague","can","with","plugin","focus"]