profiling-tables
Deep-dive data profiling for a specific table. Use when the user asks to profile a table, wants statistics about a dataset, asks about data quality, or needs to understand a table's structure and content. Requires a table name.
78
73%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/profiling-tables/SKILL.mdQuality
Discovery
82%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description with a clear 'Use when...' clause and good trigger terms that users would naturally employ. Its main weakness is that the specific capabilities are somewhat vague—'deep-dive data profiling' doesn't enumerate what concrete outputs or analyses are performed. It could also be more distinctive to avoid overlap with general data analysis skills.
Suggestions
List specific concrete actions the skill performs, e.g., 'Computes column-level statistics (nulls, uniqueness, distributions), detects data type mismatches, and summarizes value ranges.'
Add differentiating language to reduce overlap with general data analysis skills, e.g., 'Focuses on single-table profiling rather than cross-table analysis or visualization.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain ('data profiling') and mentions some actions like 'statistics about a dataset' and 'understand a table's structure and content', but doesn't list specific concrete actions (e.g., compute null counts, detect outliers, generate histograms, check data types). 'Deep-dive data profiling' is somewhat vague. | 2 / 3 |
Completeness | Clearly answers both 'what' (deep-dive data profiling for a specific table) and 'when' (explicit 'Use when...' clause listing multiple trigger scenarios). Also includes a prerequisite ('Requires a table name'), which adds useful context. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'profile a table', 'statistics about a dataset', 'data quality', 'table's structure and content', 'table name'. These are terms users would naturally use when requesting this kind of analysis. | 3 / 3 |
Distinctiveness Conflict Risk | While 'data profiling' and 'table' help narrow the scope, this could overlap with general data analysis, data exploration, or schema inspection skills. The description doesn't strongly differentiate from broader data analysis or EDA skills. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, actionable data profiling skill with well-structured SQL examples covering the full profiling workflow. Its main weaknesses are the lack of validation/error-handling checkpoints (e.g., handling very large tables, query failures, or permission issues) and some verbosity in the explanatory sections that Claude doesn't need. The content could benefit from being more concise in its prose while maintaining its strong executable SQL examples.
Suggestions
Add validation checkpoints: e.g., check row count first and adjust strategy for very large tables (sampling instead of full scans), handle permission errors gracefully.
Trim the Data Quality Assessment section (Step 6) — the rhetorical questions ('Are NULLs expected or problematic?') could be replaced with concise directives like 'Flag columns with >10% NULLs'.
Consider extracting the column-level statistics SQL templates (Step 3) and the output template (Step 7) into referenced files to keep the main skill focused on the workflow.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with concrete SQL examples, but includes some unnecessary explanatory text (e.g., 'This reveals:' bullet points explaining what cardinality analysis shows, and the data quality assessment dimensions are somewhat verbose with rhetorical questions Claude could infer). The output template section is also somewhat lengthy. | 2 / 3 |
Actionability | Every step includes fully executable SQL queries with clear column selections and patterns. The queries are copy-paste ready with only placeholder substitution needed (<table>, column_name). The output format is specified with a concrete markdown table template. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced (1-7) with a logical progression from metadata to statistics to quality assessment to output. However, there are no validation checkpoints or feedback loops — no guidance on what to do if queries fail, if the table is too large for certain operations, or how to handle errors in the profiling process. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and sub-sections, but it's a fairly long monolithic document (~120 lines). The data quality assessment dimensions and output template could potentially be split into referenced files, and the column-level statistics by type could be a reference document to keep the main skill leaner. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- astronomer/agents
- Commit
166c98a
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.