agentleFS
Goodeye-LabsGoodeye-Labs/truesight-mcp-skills/skills/error-analysis/SKILL.md

error-analysis

Skill7 starsChanged 8 months agoMITView on GitHub

Systematically identify and categorize failure modes in evaluated traces using Truesight datasets and error-analysis tools. Use when quality issues are unclear, after major pipeline changes, or when incidents indicate drift.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 5 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    BEFORE the first scoping question, search for a structured question tool (e.g., AskUserQuestion or similar interactive widget) and load it.

    line 13
  2. Distinctive:

    Ask one question at a time using the structured question tool (loaded per the HARD-GATE above).

    line 16
  3. Distinctive:

    Use the structured question tool for every question.

    line 29
  4. Distinctive:

    Ask one follow-up if response is ambiguous.

    line 30
  5. Very specific:

    If dataset exists, use list_datasets.

    line 35
  6. Very specific:

    If not, use upload_dataset.

    line 36
  7. Distinctive:

    Use random plus stratified coverage when volume is high.

    line 39
  8. Very specific:

    Use get_dataset_rows with pagination.

    line 41
  9. Distinctive:

    Stop when recent traces no longer reveal new failure categories.

    line 60

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Error Analysis

Guide the user through trace-grounded failure analysis and dataset labeling.

Interactive Q&A protocol (mandatory)

<HARD-GATE> BEFORE the first scoping question, search for a structured question tool (e.g., `AskUserQuestion` or similar interactive widget) and load it. Use that tool for EVERY scoping question. Fall back to plain-text lettered options ONLY if no such tool exists in the environment. </HARD-GATE>

Ask one question at a time using the structured question tool (loaded per the HARD-GATE above).

Example question structure:

Which data source should we analyze first?
A) Existing Truesight dataset
B) New dataset to upload
C) Unsure, list datasets first

Rules:

  • One question per message during setup.
  • Use the structured question tool for every question. Structure each with a short header, 2-4 options with labels and descriptions, and place the recommended option first. Do not add "(Recommended)" or similar annotations to option labels.
  • Ask one follow-up if response is ambiguous.

Core workflow

  1. Select or create dataset:
    • If dataset exists, use list_datasets.
    • If not, use upload_dataset.
  2. Collect representative traces:
    • Target approximately 100 traces when possible.
    • Use random plus stratified coverage when volume is high.
  3. Analyze row by row:
    • Use get_dataset_rows with pagination.
    • For each row, call suggest_error_notes.
  4. Persist annotations:
    • Save _ts_error_notes and _ts_error_category with update_dataset_row.
  5. Consolidate categories:
    • Run consolidate_error_categories.
    • Review mapping proposals, then apply with apply_category_mappings.
  6. Prioritize fixes:
    • Report most frequent categories first.
    • Recommend next skill based on failure type:
      • create-evaluation for new evaluation coverage
      • review-and-promote-traces for judgment backlog
      • eval-audit for broader process gaps

Analysis heuristics

  • Focus on first root failure in each trace, not every downstream symptom.
  • Let categories emerge from observed traces, not pre-baked labels.
  • Iterate categories after 20 traces, then relabel for consistency.
  • Stop when recent traces no longer reveal new failure categories.

Anti-patterns

  • Defining categories before reading traces.
  • Treating output quality labels as generic scores without concrete failure modes.
  • Skipping relabel after category definitions change.
  • Building new evaluators before fixing obvious prompt/tooling/engineering gaps.

Scopes reference

  • list_datasets, get_dataset_rows require datasets:read
  • upload_dataset, update_dataset_row, apply_category_mappings require datasets:write
  • suggest_error_notes, consolidate_error_categories require error-analysis:execute

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.