CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

physics-databases

Query physics databases — NIST CODATA constants, NIST Chemistry WebBook, Materials Project, Particle Data Group (PDG), OEIS sequences. Always use these instead of hardcoding physical constants.

53

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./backend/cli/skills/physics/physics-databases/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

56%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body delivers genuinely actionable, executable guidance for scipy.constants, CODATA searching, and the Materials Project API, organized into clear labeled workflows. Its weaknesses are verbosity — long print-demo blocks and a duplicated quick-reference table that teach Claude nothing it doesn't know — and structure: everything is inlined in one 225-line file when the PDG and quick-reference tables belong in separate reference files. It also promises NIST Chemistry WebBook and OEIS coverage in the description that the body never delivers, and its own 'never hardcode constants' rule is contradicted by the hardcoded PDG and astronomical values.

Suggestions

Replace the print-statement demonstrations in sections 1, 2, and 6 with a compact API summary — Claude can call `const.c` without seeing 20 example print lines — and cut the duplicated Quick Reference table.

Move the PDG particle table and the constants quick-reference into separate reference files (e.g., `references/pdg.md`, `references/constants.md`) and link them from SKILL.md, keeping the body a lean overview.

Either add workflows for NIST Chemistry WebBook and OEIS or remove them from the description, and reconcile the 'never hardcode constants' rule with the inline PDG/astronomical values (e.g., point to `pdg.lbl.gov` lookup or an astropy-based method as the primary path).

DimensionReasoningScore

Conciseness

Sections 1–2 are ~80 lines of print-statement demonstrations that merely echo constant values Claude could obtain directly from `scipy.constants` — tutorial padding that teaches nothing new. The Quick Reference table then re-lists values already demonstrated, and the PDG section inlines a ~50-line hardcoded particle dict. This is noticeably verbose with several padded sections, matching anchor 2 rather than the 'minor instances of over-explanation' at 4.

2 / 5

Actionability

The guidance is mostly executable: concrete `scipy.constants` usage, a working `find_constant` search function, and a complete Materials Project query function with API-key handling and ImportError fallback. Minor gaps keep it from 5: section 5 is a data dict rather than runnable lookup code, section 6 relies on an earlier import without restating it, and two databases promised in the description (NIST Chemistry WebBook, OEIS) have no corresponding workflow at all.

4 / 5

Workflow Clarity

This is a reference/lookup skill rather than a multi-step process, and the content is organized as six clearly labeled, self-contained workflows with a tips section — the core action (query `scipy.constants`, never hardcode) is unambiguous. It sits at anchor 4 ('clear sequence with most checkpoints present; minor gaps') rather than 5 because there are no verification steps (e.g., checking the CODATA edition or confirming a value's uncertainty) and no stated decision path for which source to use when several overlap.

4 / 5

Progressive Disclosure

Section headers and numbered workflows give reasonable structure, but the ~225-line body is monolithic — the PDG particle table and the Quick Reference table are exactly the bulk reference material that belongs in separate files loaded on demand. With no references/, scripts/, or assets/ files at all, nothing is split out, matching anchor 3 ('some structure but content that should be separate is inline') rather than the well-signaled one-level-deep references at 5.

3 / 5

Total

13

/

20

Passed

Description

65%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is distinctive and keyword-rich, naming specific authoritative databases and natural search terms, which gives it strong trigger quality and near-zero conflict risk. However, it only weakly answers 'when should Claude use it' — the 'Always use these instead of hardcoding physical constants' clause is behavioral guidance rather than an explicit user-facing trigger — and it lists data sources rather than multiple concrete actions. Adding an explicit 'Use when...' trigger clause and naming the actual actions (look up constants, convert units, query material properties) would raise completeness and specificity.

Suggestions

Add an explicit trigger clause such as 'Use when the user asks for a physical constant, particle property, unit conversion, or material data, or before hardcoding any constant value.'

Enumerate the concrete actions the skill performs (look up constants, convert units, search CODATA by name, query material properties, cite particle data) rather than only listing the databases.

Include common user synonyms such as 'particle masses', 'unit conversions', and 'materials properties' to broaden natural trigger coverage.

DimensionReasoningScore

Specificity

The description names a clear domain ('Query physics databases — NIST CODATA constants, NIST Chemistry WebBook, Materials Project, Particle Data Group (PDG), OEIS sequences') but offers only one concrete action — 'query'. It lists several data sources rather than several distinct actions, so it matches the 'names domain and 1-2 concrete actions' anchor rather than the 'lists several specific actions' anchor at 4.

3 / 5

Completeness

The 'what' is clear (query authoritative physics databases), and 'Always use these instead of hardcoding physical constants' gestures at a usage condition, but there is no explicit 'Use when...' user-facing trigger clause — the trigger scenario is only weakly implied. Per the guideline that a missing 'Use when...' clause or equivalent caps completeness at 3, this fits anchor 3 ('clear what, when weakly implied') rather than 4.

3 / 5

Trigger Term Quality

Strong natural keywords users would actually say: 'NIST CODATA constants', 'Materials Project', 'PDG', 'physical constants', 'OEIS sequences'. A few common variations are missing — no synonyms like 'particle masses', 'unit conversions', 'materials properties', or file/extension cues — which keeps it below the 'comprehensive coverage including synonyms' anchor at 5.

4 / 5

Distinctiveness Conflict Risk

The description carves out a clear niche — querying named physics databases (NIST, Materials Project, PDG, OEIS) instead of hardcoding constants — with distinct, unlikely-to-collide trigger terms. This matches the 'clear niche with distinct triggers; minimal conflict risk' anchor.

5 / 5

Total

15

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

synthetic-sciences/openscience

Path

backend/cli/skills/physics/physics-databases/SKILL.md

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.