CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

chainlink-cre-skill

Handles CRE (Chainlink Runtime Environment) Go and TypeScript workflows, the CRE CLI, simulate, and deploy. Sends CRE Connect watchers, gas-less Smart Accounts, and dta.v2 to chainlink-cre-connect-skill. Sends private-document LLM inference to chainlink-confidential-ai-attester-skill. Keeps enclave workflow logic with no document on this skill. It applies to CRON, HTTP, and EVM-log triggers, HTTP and EVM read/write, secrets, and monitoring, even when the user never says CRE.

Quality

89%

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

SKILL.md
Quality
Evals
Security

Quality

Content

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

An unusually disciplined routing-and-invariants skill: the body stays lean, pushes all executable detail into a verified, one-level-deep reference bundle, and gates every risky operation (deploy, delete, testnet writes, secrets) behind explicit validation steps. The main costs are redundancy across the Answer Contract and Operational Invariants and a few overloaded run-on rules that could be consolidated.

Suggestions

Consolidate the simulate-before-deploy requirement, currently restated in the Answer Contract, Operational Invariants 2 and 9, and the Preflight section, into a single authoritative statement.

Provide one filled-in example of the required literal simulate command (concrete workflow dir, target, and flags) alongside the placeholder template.

Split overloaded run-on rules (Operational Invariant 5, Artifact Fit rule 6) into short bullet clauses so each constraint is individually scannable.

DimensionReasoningScore

Conciseness

The body is telegraphic and assumes Claude's competence — zero tutorial filler or explanation of known concepts ("TypeScript is QuickJS/WASM, not Node.js" states the non-obvious fact only). Not 5 because there is noticeable redundancy: the simulate-before-deploy requirement is restated in the Answer Contract, Operational Invariants 2 and 9, and the Preflight section, and several rules (invariant 5, Artifact Fit rule 6) are run-on sentences dense enough that consolidation would trim tokens without losing content.

4 / 5

Actionability

Highly concrete: literal commands (`cre whoami`, `cre registry list`, `cre workflow list --registry <id>`), exact API shapes (`runtime.getSecret({ id }).result().value`, `.Await()`, batched `getSecrets`), a required literal simulate command template, and a concrete account URL. Not 5 because the key simulate command is a placeholder template (`<workflow-dir> --target <target-name> ...`) rather than a filled copy-paste example, and most executable detail is deferred to the reference files instead of shown inline.

4 / 5

Workflow Clarity

Multi-step flows are explicitly sequenced with validation checkpoints and error-recovery loops: the auth flow (`cre whoami` → failure → user chooses API key or `cre login` → confirm), simulate-first with the literal command before any deploy step, delete gated on confirming name/owner/registry via `cre workflow list`, testnet writes requiring preflight approval plus "immediate second confirmations", simulation-failure debug routing, and the ordered 7-step Freshness fallback chain with stop conditions and a three-page cap. Destructive and batch operations all carry verification, so no cap applies.

5 / 5

Progressive Disclosure

A need→reference routing table points to 16 reference files plus one asset index; all 17 referenced paths verified to exist in the bundle, and no reference file points to another (exactly one level deep). Load conditions are explicitly signaled ("always read before `cre workflow simulate`", "read before writing `deployment-registry`"), and the bulk detail (CLI flags, SDK signatures, patterns) is appropriately split out of the overview.

5 / 5

Total

18

/

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, information-dense description: it states concrete capabilities on both the what and when sides, uses domain-natural trigger terms, and explicitly fences off adjacent skills to avoid mis-triggering. The only weaknesses are the generic leading verb "Handles" and one internal-routing sentence that reads as instructions to the agent rather than a capability statement.

Suggestions

Replace the generic verb "Handles" with the specific actions taken (e.g. "Builds, simulates, and deploys CRE Go/TypeScript workflows...").

Reword "Keeps enclave workflow logic with no document on this skill" as a user-facing capability statement, since it currently reads as internal routing guidance.

Add the common user entry phrases the body already routes ("Chainlink Functions", "Chainlink Automation") to the trigger clause so the description captures those requests too.

DimensionReasoningScore

Specificity

Lists several concrete capability areas — "Go and TypeScript workflows, the CRE CLI, simulate, and deploy", "CRON, HTTP, and EVM-log triggers, HTTP and EVM read/write, secrets, and monitoring" — with explicit delegation of adjacent scopes. Falls short of 5 because the leading verb "Handles" is generic and the sentence "Keeps enclave workflow logic with no document on this skill" is internal routing language, not a stated capability; not 3 because far more than 1-2 concrete actions are named.

4 / 5

Completeness

Explicitly answers both: what — "Handles CRE ... Go and TypeScript workflows, the CRE CLI, simulate, and deploy" plus delegation targets; when — "It applies to CRON, HTTP, and EVM-log triggers, HTTP and EVM read/write, secrets, and monitoring, even when the user never says CRE", a concrete explicit trigger clause equivalent to "Use when...". Not 4 because the when-clause is explicit and enumerates concrete trigger terms rather than merely implying scope.

5 / 5

Trigger Term Quality

Good natural-term coverage for the domain: "CRE", "Chainlink Runtime Environment", "simulate", "deploy", "CRON", "EVM-log", "secrets", "monitoring", "Smart Accounts" — terms a CRE developer would actually say, reinforced by "even when the user never says CRE". Not 5 because common entry-point variations users say (e.g. "Chainlink Functions", "Chainlink Automation", "Chainlink workflows") are routed in the body but absent from the description; not 3 because coverage clearly goes beyond a couple of generic keywords.

4 / 5

Distinctiveness Conflict Risk

Clear niche (Chainlink CRE orchestration) with minimal conflict risk: it names and delegates the nearest overlapping capabilities to sibling skills ("Sends CRE Connect watchers, gas-less Smart Accounts, and dta.v2 to chainlink-cre-connect-skill", "Sends private-document LLM inference to chainlink-confidential-ai-attester-skill"), actively disambiguating itself. Clearly matches the distinct-triggers anchor.

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

smartcontractkit/chainlink-agent-skills

Path

chainlink-cre-skill/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.