CtrlK
BlogDocsLog inGet started
Tessl Logo

agently

Use when a model-powered product, assistant, automation, evaluator, or workflow request still needs the right Agently owner, execution shape, or project boundary chosen. Also use for explicit low-frequency TaskDAG or DynamicTask requests.

64

Quality

76%

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

Fix and improve this skill with Tessl

tessl review fix ./skills/agently/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

86%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 body is a well-structured, lean routing/ownership overview that assumes Claude's competence and uses textbook progressive disclosure to push detail into verified reference files, with concrete named entities making the guidance actionable despite being instruction-only.

DimensionReasoningScore

Conciseness

The body is dense and information-rich with no padding: it never explains concepts Claude already knows and every line (ownership rules, routing, anti-patterns) earns its place, matching anchor 5's 'lean and efficient; assumes Claude's competence'.

5 / 5

Actionability

It gives concrete actionable guidance via named owners, files, and APIs ('route through `agently-design`', 'read `references/task-dag.md`', '`.input(...)`', '`.info(...)`', '`.output(...)`'), fitting anchor 4; it stops short of anchor 5 only because, as an instruction-only skill, it offers no copy-paste executable code covering common cases.

4 / 5

Workflow Clarity

The numbered 'Workflow' section (steps 1-6) sequences the design process clearly and includes an escalation checkpoint ('Report a framework gap when no native owner can carry a required invariant'), matching anchor 4; the destructive/batch cap does not apply since this is design/routing work, and it lacks the explicit validate-fix-retry feedback loop that would lift it to anchor 5.

4 / 5

Progressive Disclosure

The 'Read by Need' section maps each need to a verified one-level-deep reference file (references/project-framework.md, context-and-skills.md, task-dag.md, model-quality-validation.md) and the full-stack-reference asset, with well-organized sections throughout, matching anchor 5's clear overview with well-signaled one-level references.

5 / 5

Total

18

/

20

Passed

Description

66%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 third-person, explicit about when to trigger, and highly distinct due to Agently-specific terminology, but its 'what' actions are abstract routing/choosing decisions rather than concrete operations, which limits specificity and completeness.

Suggestions

Add one or two concrete verbs that describe the skill's actual operation (e.g., 'routes', 'selects', 'maps') so the 'what' reads as a concrete action rather than an abstract 'chosen' state.

Include more common synonyms a user might naturally say (e.g., 'agent app', 'LLM workflow', 'AI assistant') alongside the current technical terms to broaden natural trigger coverage.

Tighten the opening noun list ('product, assistant, automation, evaluator, or workflow request') to the two or three most common phrasings to reduce overlap breadth without losing distinctiveness.

DimensionReasoningScore

Specificity

The description names the domain (model-powered product, assistant, automation, evaluator, workflow) and several routing actions ('the right Agently owner, execution shape, or project boundary chosen', 'TaskDAG', 'DynamicTask'), but the actions are abstract choosing/routing decisions rather than concrete operations, matching anchor 3 and not the multi-concrete-action coverage of anchor 4.

3 / 5

Completeness

Both 'what' (choose owner/execution shape/project boundary) and 'when' are present with explicit trigger clauses ('Use when...', 'Also use for explicit low-frequency TaskDAG or DynamicTask requests'), but the 'what' is abstract rather than concrete operations, so it sits at anchor 4 rather than the fully concrete anchor 5.

4 / 5

Trigger Term Quality

It includes some relevant natural terms ('model-powered product', 'assistant', 'automation', 'workflow request') plus product-specific ones ('TaskDAG', 'DynamicTask'), but misses common variations and synonyms of the broader phrases, fitting anchor 3 rather than the fuller coverage of anchor 4.

3 / 5

Distinctiveness Conflict Risk

The Agently-specific terminology ('Agently owner', 'TaskDAG', 'DynamicTask', 'execution shape', 'project boundary') carves a clear niche with distinct triggers and minimal overlap risk, matching anchor 5; the broad opening list is narrowed by the 'still needs the right Agently owner... chosen' qualifier.

5 / 5

Total

15

/

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
AgentEra/Agently-Skills
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.