CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

agent-tool-call-latency

Measures every agent tool call on this machine from local session history (the user's chat logs), in any harness, finds where the time goes, and ranks fixes for slow commands, harness overhead and wasted waiting. Use when the user asks why their agents are slow, where agent run time goes, or how to cut the time agents spend waiting on tools.

Quality

94%

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

96%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 an exceptionally tight operational spec: six phases with per-phase completion criteria, executable commands with exact flags and thresholds, validation feedback loops, and careful safeguards for destructive changes, with detail correctly pushed to real one-level-deep reference files. The single notable defect is a dead link to the published example report, which is the only thing keeping progressive disclosure from a top score.

Suggestions

Ship the published example report at examples/agent-tool-call-latency/report.md (the link target of ../../examples/agent-tool-call-latency/report.md) or remove/inline the reference, so phase 6's 'published example' pointer is not a dead link.

If the example report cannot be bundled, replace the link with a one-line description of what the example demonstrates so readers are not sent to a missing path.

DimensionReasoningScore

Conciseness

The body is dense, directive prose with no explanation of concepts Claude already knows: phases give exact commands, thresholds ('every cheap-operation gap of 200 ms or more at p50', 'above 2% of tool time') and exit-code semantics ('Exit status 2 means an adapter failed') without padding. Every line instructs rather than describes, matching the 'every token earns its place' anchor; the 4 anchor's 'minor instances of over-explanation' would require trimmable justification, and the brief rationales here (e.g. 'a timestamp, so a later audit never overwrites the original') carry operational weight.

5 / 5

Actionability

Guidance is fully executable: copy-paste commands with flags and placeholders ('python3 <skill>/scripts/extract.py --since <first day> --out <work directory>/calls.jsonl --exclude-cwd /agent-latency-bench/'), a concrete data-row format ('add a [category, label, regex] row to <work directory>/patterns.json'), exact work-directory and backup naming ('<file>.pre-latency-audit-<YYYYMMDD-HHMMSS>'), and a fully specified report structure. All referenced scripts and adapters exist in the bundle, so the commands run as written.

5 / 5

Workflow Clarity

Six phases are clearly sequenced, each ending in an explicit 'Done when' checklist, with validation and feedback loops throughout: 'A schema error or an unexplained WARN sends you back to the adapter', adapter failure handling with retry before proceeding, and phase-5 safety for destructive changes (timestamped backups, 'run git status first', worktree rule, 'changes.md' with undo instructions, and re-asking the user when a fix turns out unsafe). This exceeds the anchor-4 'most checkpoints' level and matches explicit validation with error-recovery loops; the destructive-operation cap at 3 does not apply because validation is abundant.

5 / 5

Progressive Disclosure

Structure is strong: a ~100-line overview keeps detail in four one-level-deep, well-signalled reference files ([SCHEMA.md](references/SCHEMA.md), [CAUSES.md](references/CAUSES.md), [ADAPTERS.md](references/ADAPTERS.md), [BENCHMARK.md](references/BENCHMARK.md)) that all exist, with a valid anchor link to ADAPTERS.md § Done when, and scripts in scripts/. It falls short of anchor 5 because the body points to a published example report at 'examples/agent-tool-call-latency/report.md' (../../examples/...) that is not present in the bundle — a navigation dead end — which is exactly the 'minor organization gaps' of anchor 4 rather than the 'easy navigation' of 5.

4 / 5

Total

19

/

20

Passed

Description

92%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 description: it states a comprehensive set of concrete capabilities (measure, locate, rank) with the data source and scope, and carries an explicit 'Use when ...' clause with natural trigger phrases. The only weakness is trigger coverage that misses a few common synonyms a user might naturally say.

Suggestions

Add one or two natural trigger variations such as 'speed up agents', 'slow tool calls', or 'agent performance' to the 'Use when' clause so users phrasing the request as a performance complaint also match.

Consider naming the measurable artifact early (e.g. 'tool-call latency') so the skill matches users who use the technical term rather than only colloquial phrasings.

DimensionReasoningScore

Specificity

The description lists multiple concrete, comprehensive actions with their data source and scope: 'Measures every agent tool call on this machine from local session history', 'in any harness', 'finds where the time goes, and ranks fixes for slow commands, harness overhead and wasted waiting'. It covers input (session history), analysis (find where time goes) and output (ranked fixes), matching the comprehensive-coverage anchor rather than the 'minor gaps' anchor at 4.

5 / 5

Completeness

It explicitly answers both questions: what ('Measures every agent tool call ... finds where the time goes, and ranks fixes ...') and when ('Use when the user asks why their agents are slow, where agent run time goes, or how to cut the time agents spend waiting on tools'), with concrete trigger phrases. This matches the anchor requiring both what and when with explicit triggers; the 4 anchor's 'when could be more explicit' does not apply here.

5 / 5

Trigger Term Quality

Natural phrases users would say are present: 'why their agents are slow', 'where agent run time goes', 'how to cut the time agents spend waiting on tools'. However, common variations such as 'speed up agents', 'slow tool calls', or 'agent performance' are absent, so keyword coverage is good but not comprehensive — anchor 4, not the synonym-complete anchor 5, and clearly above the 3 anchor whose keywords miss natural phrasing.

4 / 5

Distinctiveness Conflict Risk

It occupies a clear niche — auditing agent tool-call latency from local session history across harnesses — with distinct triggers ('why their agents are slow', 'waiting on tools') that few other skills would claim. The combination of measurement source, scope and output makes conflict risk minimal, matching anchor 5 rather than the minor-overlap anchor 4.

5 / 5

Total

19

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

relative_links

Relative link issues: 1 suspicious

Warning

Total

14

/

16

Passed

Repository

exadel-inc/agentic-readiness-assessment

Path

skills/agent-tool-call-latency/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.