tool-description-error-tracking

Guide for understanding the tool's functionality and usage in error tracking

Quality

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./.agents/skills/tool-description-error-tracking/SKILL.md

Quality

Discovery

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 description is extremely vague and fails on all dimensions. It doesn't name the specific tool, doesn't list concrete actions, lacks trigger terms users would naturally use, and provides no guidance on when Claude should select this skill. It reads more like a meta-description of a guide than an actionable skill description.

Suggestions

Name the specific error tracking tool (e.g., Sentry, Bugsnag, Datadog) and list concrete actions like 'configure alerts, triage exceptions, analyze stack traces, set up integrations'.

Add an explicit 'Use when...' clause with natural trigger terms such as 'error tracking', 'exceptions', 'crash reports', 'bug monitoring', or the specific tool name.

Replace the vague 'understanding the tool's functionality and usage' framing with direct capability statements in third person (e.g., 'Configures and manages [Tool] for error tracking and exception monitoring').

Dimension	Reasoning	Score
Specificity	The description uses vague language like 'understanding the tool's functionality and usage' without naming any concrete actions. It does not specify what the tool does, what actions it performs, or what outputs it produces.	1 / 3
Completeness	The 'what' is extremely vague ('understanding the tool's functionality') and there is no 'when' clause or explicit trigger guidance at all. Both dimensions are weak or missing.	1 / 3
Trigger Term Quality	The only potentially useful trigger term is 'error tracking', but it's buried in vague phrasing. There are no natural keywords a user would say like 'bug', 'exception', 'Sentry', 'stack trace', 'crash report', or specific tool names.	1 / 3
Distinctiveness Conflict Risk	The description is so generic that it could apply to virtually any error tracking tool or even any tool documentation. 'Guide for understanding the tool's functionality' could conflict with any skill that involves tool usage or documentation.	1 / 3
	Total	4 / 12 Passed

Implementation

14%

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

This skill reads more like informal developer documentation than an actionable skill for Claude. It spends significant tokens explaining how the tool works internally (LLVM instrumentation, error computation logic) rather than providing clear, executable guidance on how to use it. The content lacks a coherent workflow, has multiple typos, and doesn't include examples of interpreting output or acting on error reports.

Suggestions

Replace the conceptual 'How the tool works' section with a concise 1-2 sentence summary and add a clear end-to-end workflow: compile with flags → run program → find reports in .fpc_logs/ → interpret JSON output → fix errors

Add a concrete example of a JSON error report with annotation showing how to interpret each field and what action to take

Remove internal implementation details (function signatures, operand explanations, ODR linkage notes) that don't help Claude use the tool, or move them to a separate INTERNALS.md reference file

Fix typos ('firdt' → 'first', 'variablea' → 'variables', 'oprand' → 'operand') and tighten the compilation section to just the essential commands with a brief example

Dimension	Reasoning	Score
Conciseness	The content is verbose and explains concepts Claude already understands (what LLVM instrumentation is, how FP32 vs FP64 comparison works, what arithmetic operations are). There are typos ('firdt', 'variablea', 'oprand') and unnecessary elaboration throughout. The explanation of how error is computed could be drastically shortened.	1 / 3
Actionability	The compilation section provides concrete commands (fpchecker-show, PATH export, compiler flags), but the error computation section is purely descriptive rather than instructive. There are no examples of actual usage workflows—compiling a sample program, interpreting a JSON error report, or acting on findings.	2 / 3
Workflow Clarity	There is no clear sequenced workflow for using the tool end-to-end. The sections describe what the tool does conceptually but never provide a step-by-step process (compile → run → read reports → fix). No validation checkpoints or error recovery guidance is provided.	1 / 3
Progressive Disclosure	The content is a monolithic wall of text with no clear hierarchy or navigation structure. Source files are mentioned but not linked or organized for discovery. There are no references to separate documents for advanced topics, and the content mixes conceptual explanation with usage instructions without clear separation.	1 / 3
	Total	5 / 12 Passed

Validation

100%

Warnings & errors only

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

Validation — 11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository: llnl/FPChecker
Commit: 875a03e

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

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.