CtrlK
BlogDocsLog inGet started
Tessl Logo

agently

Use when the user wants to build, initialize, validate, optimize, or refactor a model-powered assistant, internal tool, automation, evaluator, or workflow from a business scenario or common problem statement, including project-structure refactors or starter skeletons that may separate model setup, prompt config, and orchestration, even if the request also mentions a UI, app shell, or local model service such as Ollama, and it is still unclear whether the solution should stay a single request, add supporting capabilities, or become orchestration. The user does not need to mention Agently explicitly.

48

Quality

51%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/agently/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

35%

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

This skill attempts to be a comprehensive playbook for Agently-based development but suffers from significant verbosity and repetition, particularly around issue filing, evaluation patterns, and framework API guidance. While it demonstrates domain expertise and provides specific API surface references, the lack of any executable code examples and the monolithic inline rule set undermine both actionability and progressive disclosure. The content would benefit greatly from aggressive condensation and splitting detailed rules into referenced sub-documents.

Suggestions

Add 1-2 concrete, executable code examples showing a typical Agently agent setup and task creation to improve actionability from abstract API references to copy-paste ready patterns.

Extract the lengthy Native-First Rules into a separate referenced file (e.g., `references/native-first-rules.md`) and keep only the top 5-6 most critical rules inline to dramatically improve conciseness and progressive disclosure.

Consolidate the duplicated issue-filing guidance (Workflow steps 7-8 and the two Native-First Rules bullets about issue reports) into a single, concise section or a referenced file.

Add explicit validation checkpoints to the workflow, such as 'If step 3 yields multiple capability paths, list trade-offs and confirm with user before proceeding' to improve workflow clarity.

DimensionReasoningScore

Conciseness

The skill is extremely verbose with extensive repetition across sections. Many rules are restated in slightly different forms (e.g., issue filing appears in both Workflow steps 7-8 and Native-First Rules, with overlapping privacy/redaction guidance). The document explains framework-internal concepts at great length that could be condensed significantly, and many bullet points contain dense, multi-clause sentences that could be tightened.

1 / 3

Actionability

The skill provides specific API method names (e.g., `agent.define(...)`, `agent.effort(...)`, `agent.create_task(...)`, `execution.get_result()`) and concrete routing decisions, which is good. However, there are zero executable code examples, no copy-paste ready snippets, and much of the guidance is abstract procedural description rather than concrete demonstration of how to apply these patterns.

2 / 3

Workflow Clarity

The 8-step workflow provides a reasonable sequence for the design process, but validation checkpoints are implicit rather than explicit. Steps like 'choose the narrowest native Agently capability path' and 'name the validation rule' lack concrete criteria or feedback loops for error recovery. The workflow also doesn't clearly indicate what to do when validation fails at step 5.

2 / 3

Progressive Disclosure

The 'Read Next' section references three files and the Capability Routing section points to other skills, which is good structure. However, the referenced bundle files don't exist (no bundle provided), and the main body contains an enormous amount of inline detail (Native-First Rules alone is ~60+ bullet points) that should be split into referenced documents rather than kept in the playbook overview.

2 / 3

Total

7

/

12

Passed

Description

67%

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 thorough in covering when to trigger and attempts to be comprehensive, but it suffers from being overly long and trying to capture too many scenarios in a single run-on sentence. The breadth of scope creates conflict risk with other skills, and the dense phrasing buries natural trigger terms that users would actually say. It would benefit from being more concise with clearer, more specific capability statements.

Suggestions

Break the description into a concise 'what' statement listing 3-5 specific concrete outputs (e.g., 'Scaffolds model-powered assistants with separated prompt config, model setup, and orchestration layers') followed by a focused 'Use when...' clause.

Add natural user-facing trigger terms that people would actually say, such as 'AI agent', 'chatbot', 'LLM app', 'AI pipeline', 'build an assistant', or 'create a bot'.

Narrow the scope to reduce conflict risk—consider removing overly broad terms like 'internal tool', 'automation', and 'UI' that could overlap with general development or frontend skills.

DimensionReasoningScore

Specificity

The description names a domain (model-powered assistants, tools, workflows) and lists several actions (build, initialize, validate, optimize, refactor), but the actions are broad and not concretely tied to specific outputs or operations. It reads more like a laundry list of verbs than concrete capabilities.

2 / 3

Completeness

The description explicitly opens with 'Use when...' and provides extensive detail about both what the skill does (build/initialize/validate/optimize/refactor model-powered tools and workflows) and when to use it (business scenarios, problem statements, project-structure refactors, even when UI or Ollama is mentioned). Both dimensions are clearly addressed.

3 / 3

Trigger Term Quality

Includes some useful trigger terms like 'assistant', 'automation', 'evaluator', 'workflow', 'Ollama', 'orchestration', and 'prompt config', but many are somewhat technical or internal-facing. Common user phrases like 'AI agent', 'chatbot', 'LLM app', or 'AI pipeline' are missing, and the description is so dense that natural trigger terms get buried.

2 / 3

Distinctiveness Conflict Risk

While it tries to carve out a niche around model-powered assistant building and orchestration, the extremely broad scope (internal tools, automations, evaluators, workflows, UI, app shells, refactors) means it could easily conflict with general coding skills, project scaffolding skills, or prompt engineering skills. The mention that 'the user does not need to mention Agently' further broadens the trigger surface.

2 / 3

Total

9

/

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.

Validation11 / 11 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.