CtrlK
BlogDocsLog inGet started
Tessl Logo

copying-endpoints-across-projects

Copy a PostHog endpoint (a saved HogQL/insight query exposed as an API route) to another project in the same organization, or duplicate it under a new name in the same project. Use when the user wants to duplicate an endpoint, promote an endpoint from staging to production, replicate an endpoint's query/variables/freshness config in another workspace, or clone an endpoint to iterate on it. Unlike feature flags and experiments, endpoints have NO native cross-project copy tool — this skill covers the read-then-recreate flow (endpoint-get then endpoint-create), the active-project switching it requires, name-collision checks, and the safe defaults (land unmaterialised in the target, verify with endpoint-run). Does not cover editing endpoint versions (see managing-endpoint-versions) or authoring a brand-new endpoint from scratch (see creating-an-endpoint).

72

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

77%

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

The body is a well-sequenced, highly actionable workflow with strong validation checkpoints and clear tool/field guidance for an instruction-only skill. It is mostly concise, though a few mechanics are restated across sections, and progressive disclosure is limited by the absence of any bundle/reference files to offload detailed manifests.

Suggestions

Dedupe the 'query carried verbatim preserves variables' point: state it once (step 2 or Important notes) and reference it elsewhere rather than restating it in steps 2, 6, and Important notes.

Tighten step 5's materialisation rationale: keep the safe default and the non-materialisable caveat, but trim the comparative narrative to a line or two.

Consider extracting the full endpoint field manifests (capture list in step 2 and create list in step 6) into a reference file so SKILL.md stays a lean overview with one-level-deep references.

DimensionReasoningScore

Conciseness

Mostly lean and it assumes Claude's competence (no primers on PostHog/HogQL), but the 'Important notes' section and step 6 restate mechanics already covered in steps 2 and 5 (e.g. copying query verbatim carries variables), and step 5's safe-default rationale is somewhat discursive. Not a 3 because a few passages restate prior content and could be tightened.

2 / 3

Actionability

Every step names the exact tool and the concrete field set to capture and pass (name, query, description, data_freshness_seconds, is_materialized, tags) plus precise naming rules ('Snake_case, URL-safe, starts with a letter, max 128 chars'). Not a 2 because there is no vague or abstract guidance; the instruction-only skill is fully actionable without code.

3 / 3

Workflow Clarity

An explicit 8-step sequence with validation checkpoints: confirm active project is source before reading (step 1), name-collision check before creating (step 3), present summary before copying (step 2), and a verification run (step 7). The 'No undo' create op has a feedback loop via the collision check and 'stop and ask' handling, so it is not capped at 2.

3 / 3

Progressive Disclosure

Well-organized into clear sections with one-level conceptual cross-links to sibling skills and no nested file references, so it is not a 1. But no bundle files exist and the skill is a single ~120-line file with detailed reference-like content (full field manifests, materialisation caveats) inline rather than split into reference files, so it does not reach the well-signaled multi-file structure of a 3.

2 / 3

Total

10

/

12

Passed

Description

100%

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 specific, trigger-rich, and complete, with explicit scope boundaries that sharply distinguish it from neighboring skills. It uses third-person voice and avoids fluff or over-claims. This is a strong, well-targeted description.

DimensionReasoningScore

Specificity

Enumerates concrete actions rather than naming only the domain: 'Copy a PostHog endpoint...to another project', 'duplicate it under a new name', and the 'read-then-recreate flow (endpoint-get then endpoint-create)' with 'active-project switching', 'name-collision checks', and 'verify with endpoint-run'.

3 / 3

Completeness

Clearly answers both what (read-then-recreate copy/duplicate of an endpoint) and when (explicit 'Use when...' clause), plus scope boundaries ('Does not cover...'). The 'Use when' trigger is present, so it is not capped at 2.

3 / 3

Trigger Term Quality

The explicit 'Use when the user wants to duplicate an endpoint, promote an endpoint from staging to production, replicate...in another workspace, or clone an endpoint to iterate on it' covers the natural phrasings a user would say. Not a 2 because multiple common variations (duplicate, promote, clone) are all present.

3 / 3

Distinctiveness Conflict Risk

A clear, narrow niche (PostHog endpoint cross-project/same-project copy) explicitly distinguished from feature flags/experiments ('endpoints have NO native cross-project copy tool') and from sibling skills (managing-endpoint-versions, creating-an-endpoint), so it is unlikely to trigger for the wrong skill.

3 / 3

Total

12

/

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.

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.