Guide for implementing oRPC contract-first API patterns in Dify frontend. Triggers when creating new API contracts, adding service endpoints, integrating TanStack Query with typed contracts, or migrating legacy service calls to oRPC. Use for all API layer work in web/contract and web/service directories.
Install with Tessl CLI
npx tessl i github:langgenius/dify --skill orpc-contract-firstOverall
score
81%
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillEvaluation — 100%
↑ 2.00xAgent success when using this skill
Validation for skill structure
Discovery
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.
This is a well-crafted skill description that excels across all dimensions. It provides specific concrete actions, includes natural trigger terms developers would use, explicitly states both what the skill does and when to use it, and carves out a distinct niche with oRPC/Dify-specific terminology and directory paths.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'implementing oRPC contract-first API patterns', 'creating new API contracts', 'adding service endpoints', 'integrating TanStack Query with typed contracts', 'migrating legacy service calls to oRPC'. | 3 / 3 |
Completeness | Clearly answers both what ('implementing oRPC contract-first API patterns', 'creating API contracts', etc.) and when ('Triggers when creating new API contracts...', 'Use for all API layer work in web/contract and web/service directories'). | 3 / 3 |
Trigger Term Quality | Includes natural keywords users would say: 'API contracts', 'service endpoints', 'TanStack Query', 'oRPC', 'API layer', plus specific directory paths 'web/contract' and 'web/service' that developers would reference. | 3 / 3 |
Distinctiveness Conflict Risk | Highly specific niche with distinct triggers: oRPC-specific patterns, Dify frontend context, specific directories (web/contract, web/service), and TanStack Query integration make it unlikely to conflict with generic API or frontend skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
65%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is well-organized and token-efficient, correctly assuming Claude's competence with TypeScript and API patterns. However, it lacks concrete executable examples for the core tasks (creating contracts, defining routes, creating hooks) and misses validation steps that would help catch integration errors. The workflow is clear but would benefit from copy-paste ready code snippets.
Suggestions
Add a complete executable example showing a contract definition with path, method, input (using params/query/body structure), and output
Include a concrete hook example showing consoleQuery and consoleClient usage with actual TanStack Query patterns
Add validation checkpoint after step 2 (e.g., 'Verify TypeScript compiles without errors' or 'Check router types are correctly inferred')
Consider linking to example files in the codebase for more complex patterns (form handling, error states, optimistic updates)
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely lean and efficient. No unnecessary explanations of what oRPC is or how contracts work. Every section delivers actionable information without padding. | 3 / 3 |
Actionability | Provides clear workflow steps and rules, but lacks executable code examples. The type export snippet is useful but the workflow steps describe what to do without showing concrete code for creating contracts, defining routes, or creating hooks. | 2 / 3 |
Workflow Clarity | Three-step workflow is clearly sequenced, but lacks validation checkpoints. No guidance on how to verify contracts are correctly registered, hooks work properly, or how to handle errors during migration. | 2 / 3 |
Progressive Disclosure | Good structure with clear sections, but all content is inline. For a skill covering contracts, router composition, and hooks, references to example files or more detailed guides for each area would improve navigation. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 13 / 16 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
description_trigger_hint | Description may be missing an explicit 'when to use' trigger hint (e.g., 'Use when...') | Warning |
metadata_version | 'metadata' field is not a dictionary | Warning |
license_field | 'license' field is missing | Warning |
Total | 13 / 16 Passed | |
Table of Contents
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.