terra-data

Terra API health data retrieval and management. Use when fetching activity, sleep, body, daily, nutrition, menstruation, or athlete data from wearables.

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

High

Do not use without reviewing

Fix and improve this skill with Tessl

tessl review fix ./skills/terra-data/SKILL.md

Quality

Content

65%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.

A highly actionable, information-dense reference: executable Terra calls, realistic payloads with exact field names, and useful operational guidance (overwrite semantics, provider history limits, async webhook behavior). Its weaknesses are structural — it is a self-contained monolith with sample responses and DB schema inlined, and its batch/backfill workflows lack validation checkpoints. The Quick Start also embeds what appear to be real dev credentials rather than placeholders.

Suggestions

Add validation checkpoints to the batch workflows: after a >28-day backfill (which returns {"status": "processing"}), confirm webhook delivery and verify expected record counts before declaring the backfill complete, rather than ending the flow with no verification.

Move the per-type sample JSON responses and the SQL DDL into a references/ file (e.g., references/response-schemas.md and references/db-schema.md), keeping SKILL.md as a concise overview with clearly signaled one-level-deep links.

Trim the seven repeated "def get_*" wrapper blocks (keep the client call and field summary) and replace the hard-coded dev_id/api_key in Quick Start with placeholders pointing to the terra-auth skill.

Dimension	Reasoning	Score
Conciseness	Dense Terra-specific material with no padding explaining concepts Claude already knows, but the seven repeated "def get_*" wrapper blocks each duplicate the client call shown inside them — trimmable boilerplate that keeps this below anchor 5.	4 / 5
Actionability	The Quick Start and every "client.activity.get(user_id=..., start_date=..., end_date=...)" call are copy-paste ready with realistic sample responses showing exact field names. Minor gaps keep it below anchor 5: "handle_data_update" depends on an undefined "db" object (pseudocode), and "get_all_user_data" is declared "async" but makes synchronous calls.	4 / 5
Workflow Clarity	The backfill branch "if days_back > 28 ... to_webhook=True" is a clear decision point and the overwrite vs. insert-or-ignore update strategy is stated, but batch operations (historical backfill, bulk upserts) include no validation or verification steps — no webhook-delivery confirmation, no check that expected data arrived — which caps this dimension at 3 per the batch-operations guideline.	3 / 5
Progressive Disclosure	Section headers are well organized, but roughly 300 lines of inline sample JSON responses plus the SQL DDL are reference material that belongs in separate bundle files; no references/ directory exists and SKILL.md carries everything, matching anchor 3's 'content that should be separate is inline'.	3 / 5
	Total	14 / 20 Passed

Description

87%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.

A strong description: it explicitly answers both what and when, enumerates seven concrete data types, and uses natural wearable/health trigger terms in third person. The only weaknesses are the vague word "management" and missing common synonyms like fitness tracker, heart rate, or provider names.

Dimension	Reasoning	Score
Specificity	"retrieval and management" plus "fetching activity, sleep, body, daily, nutrition, menstruation, or athlete data" enumerates seven concrete data types with near-comprehensive coverage, above anchor 3's 'not comprehensive' — but below anchor 5 because "management" is generic and other concrete actions (e.g., writing data back to providers) go unnamed.	4 / 5
Completeness	"Terra API health data retrieval and management" states the what, and "Use when fetching activity, sleep, body, daily, nutrition, menstruation, or athlete data from wearables" is an explicit when with concrete trigger phrases, mirroring the anchor-5 example structure exactly. Third-person voice throughout.	5 / 5
Trigger Term Quality	Natural terms users would say appear: "health data", "activity", "sleep", "wearables". Below anchor 5 because common synonyms and specifics — "fitness tracker", "heart rate", provider names like Garmin/Oura — are missing.	4 / 5
Distinctiveness Conflict Risk	The Terra API niche with wearable-data triggers is clearly distinct; the only overlap is with complementary sibling terra-* skills, so conflict risk is minimal.	5 / 5
	Total	18 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (553 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

Repository: fernandezbaptiste/Skrillz
Path: skills/terra-data/SKILL.md
Commit: 93ed392

Reviewed: 14 hours ago

Table of Contents

Discovery Implementation Validation

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.