CtrlK
BlogDocsLog inGet started
Tessl Logo

warehouse-source-new-version

Add support for a new vendor API version to an existing Data warehouse import source, or deprecate an old one. Use when a vendor ships a new API version (Stripe date versions, Shopify quarterly versions, header-pinned revisions, /vN/ URL bumps), when implementing a version-update or deprecation task for a source under products/warehouse_sources/backend/temporal/data_imports/sources, or when repinning an ExternalDataSource to a different version. Covers deciding whether a newly announced version needs supporting at all, version declaration, dispatch, pinning semantics, deprecation metadata, and migration scripts.

65

Quality

77%

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 ./.agents/skills/warehouse-source-new-version/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%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 content is a thorough, concrete, well-sequenced workflow guide with strong actionability and built-in validation (a decision gate plus invariant tests). Its main weakness is conciseness: dense, over-long sentences and a monolithic single-file structure that could be tightened and partially split out.

Suggestions

Tighten the long compound sentences in 'How versioning works' and 'Common pitfalls' — break stacked qualifications into shorter clauses or bullets so each constraint reads on its own.

Consider splitting the extensive 'Common pitfalls' list into a references file (e.g. PITFALLS.md) referenced from the body, reducing the inline bulk of the monolithic SKILL.md.

Add an explicit validate-then-proceed loop to the 'Adding a new version' steps (e.g., run the invariant test, and if it fails, fix declarations and re-run before opening the PR) to reach a fuller feedback-loop structure.

DimensionReasoningScore

Conciseness

The body is information-dense with non-obvious codebase specifics and no padding of concepts Claude already knows, but it runs ~104 lines of heavily stacked, run-on sentences with deep parenthetical qualifications that could be tightened for clarity.

3 / 5

Actionability

Guidance is highly concrete — real file paths, class and method names, a Stripe dispatch-chain example, an exact PR-title format, and migration-number guards — giving mostly executable direction with only minor gaps typical of an instruction-only skill.

4 / 5

Workflow Clarity

Clear numbered sequences for adding (6 steps) and deprecating (6 steps) a version, with an explicit pass/fail decision gate, an auto-enforcing invariant test, and a test step that exercises both versions; it stops short of an explicit validate-fix-retry loop.

4 / 5

Progressive Disclosure

Clean section headers and a logical flow make the single-file body navigable, and inlining is defensible for a process skill, though the long monolithic document with no file-level splitting or references leaves minor organization gaps versus an ideal split.

4 / 5

Total

15

/

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.

The description is strong: it clearly states both the capability and multiple concrete usage triggers tied to a specific, narrow domain, with good keyword coverage and very low conflict risk. The only soft spot is that some trigger phrasing is jargon-heavy rather than user-plain, which keeps trigger quality and specificity just below a perfect mark.

DimensionReasoningScore

Specificity

Names the domain and lists several concrete actions ('version declaration, dispatch, pinning semantics, deprecation metadata, and migration scripts'; 'Add support for a new vendor API version... or deprecate an old one'), with only minor coverage gaps relative to the comprehensive 5 anchor.

4 / 5

Completeness

Explicitly answers both what (add/deprecate vendor API versions plus the covered scope) and when, with three concrete 'Use when...' trigger clauses including named version schemes and a file path.

5 / 5

Trigger Term Quality

Good natural-trigger coverage ('vendor ships a new API version', 'Stripe date versions, Shopify quarterly versions, header-pinned revisions, /vN/ URL bumps', 'repinning an ExternalDataSource'), though some phrasing leans into codebase-specific jargon rather than the plainest user phrasing.

4 / 5

Distinctiveness Conflict Risk

A clear narrow niche (warehouse-source vendor API versioning) pinned to a concrete codebase path with distinct triggers, giving minimal overlap with other skills.

5 / 5

Total

18

/

20

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
PostHog/posthog
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.