[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71P8Z7QKJBH6YF3GW8FCAX2":3,"skill-same:01M71P8Z7QKJBH6YF3GW8FCAX2":87},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":15,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":66,"ownerDescription":6,"updatedAt":67,"install":68,"resources":81},"01M71P8Z7QKJBH6YF3GW8FCAX2","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.","monoes\u002Fmonomind","monoes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276744696?v=4","01M71KWF37AJ2NJBP3KWBVSDGT","01M71KWF4CSF8ADH0M6HA09VD2",23,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fvalidate-data\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\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","aggregation","spot","logic","results","github","use","bias","accuracy","presentation","sql","work","analysis","query","sql query","when","qa","knowledge","2026-11-10 13:02:02",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.\"\ntags: []\ntools: []\nlicense: Apache-2.0\nsource: https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\nsource_path: \"data\u002Fskills\u002Fvalidate-data\"\nsource_commit: 8444efcd48f7012f09797778a36a33e73d0861f4\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,"tags":54,"tools":55,"source":56,"license":14,"description":7,"source_path":57,"source_commit":58},[],[],"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins","data\u002Fskills\u002Fvalidate-data","8444efcd48f7012f09797778a36a33e73d0861f4","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fvalidate-data",2,"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","https:\u002F\u002Fmonoes.github.io\u002Fmonomind\u002F","https:\u002F\u002Fgithub.com\u002Fmonoes","https:\u002F\u002Fmonoes.me","2026-11-10 01:53:48",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add monoes\u002Fmonomind --skill validate-data",{"tool":74,"command":75},"bunx","bunx skills add monoes\u002Fmonomind --skill validate-data",{"tool":77,"command":78},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill validate-data","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fvalidate-data\u002FSKILL.md",true,[82],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":15},"LICENSE.txt","LICENSE","许可证",11607,[88,113,145,170,190,217],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":49},"01M71PB3SHWKMNJM6MD65VX8D6","zk-steward","Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",[],[95,96,97,98,99,100,101,48,102,44,103,104,105,106,107,108,109,110,111,112],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","impact","snark","review","monomind","security review","stark","zettelkasten","cryptography","security","org","blockchain",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":117,"licenseFileUrl":118,"sourceHtmlUrl":119,"categories":120,"keywords":127,"publishedAt":49},"01M71PB18SDG28WBKPKJNB814K","writing-plans","Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.","MIT","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FSKILL.md",[121,124],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":125,"categoryName":126,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[128,129,130,99,131,132,46,133,44,134,135,136,137,138,139,140,141,142,143,144],"writing","writing plans","plans","superpowers","implementation plan","you","code","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":149,"sourceHtmlUrl":150,"categories":151,"keywords":155,"publishedAt":49},"01M71PAXFM488X9ARXK0T04TF5","write-spec","Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FSKILL.md",[152],{"categoryNo":153,"categoryName":154,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理",[138,156,157,158,159,48,160,46,161,162,42,137,163,164,165,166,167,168,37,169],"write spec","spec","user request","problem","acceptance","ask","vague","request","scoping","idea","metrics","feature","problem statement","document",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":174,"sourceHtmlUrl":175,"categories":176,"keywords":178,"publishedAt":49},"01M71PASSZY800C0RPEARBS918","write-query","Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FSKILL.md",[177],{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[44,138,179,180,181,182,48,37,46,183,184,185,186,42,36,41,187,188,189,29],"write query","postgres","for","snowflake","best practices","natural-language","with","multi","https","syntax","plugins",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":202,"publishedAt":49},"01M71PAPTX0T3PF6ETFVR96SJJ","workflow-automation","Org role guidance for workflow automation: build and maintain CI\u002FCD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-automation\u002FSKILL.md",[196,199],{"categoryNo":197,"categoryName":198,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":200,"categoryName":201,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[203,204,205,206,181,207,208,209,210,102,211,212,213,44,105,36,214,215,216,187],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":224,"publishedAt":49},"01M71PAM19Z1XTV9NPCFSE2MY8","workflow-architect","Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-architect\u002FSKILL.md",[223],{"categoryNo":200,"categoryName":201,"taxonomyType":21,"taxonomyTypeDesc":22},[205,225,226,227,228,229,230,181,231,232,134,233,234,235,105,36,236,237,187,238],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems"]