CtrlK
BlogDocsLog inGet started
Tessl Logo

xberg

Extract text, tables, metadata, and images from 107 document formats (PDF, Office, images, HTML, email, archives, academic) using Xberg. Use when writing code that calls Xberg APIs in Python, Node.js/TypeScript, Rust, or CLI. Covers installation, extraction (sync/async), configuration (OCR, chunking, output format), batch processing, error handling, and plugins.

72

Quality

89%

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

The canonical home for this skill is xberg in xberg-io/xberg

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.

An excellent reference-style skill body: fully executable multi-language examples, precise API surface and pitfalls, and a clean one-level reference structure pointing to eight real files. Weak spots are mild redundancy (formats table and triple envelope explanation) and the absence of an explicit batch error-recovery loop.

Suggestions

Trim the Supported Formats table to category names only (or a handful of exemplar extensions) since references/supported-formats.md already holds the complete list — the current 17-line table is the body's largest duplicated content.

Consolidate the envelope explanation into the 'Result Envelope and Document Fields' section and have Quick Start and Pitfall #1 reference it in one line each, saving three near-duplicate explanations.

Add a short fix-and-retry note for batch failures (e.g., how to re-run or skip a failed input from result.errors), which would close the feedback-loop gap in the batch workflow.

DimensionReasoningScore

Conciseness

Nearly all prose is library-specific (envelope shape, async-only bindings, exact field names, error semantics) rather than concepts Claude already knows, so it is well past the verbose anchors. Minor trimmable padding keeps it at anchor 4 instead of 5: the ~17-line Supported Formats table duplicates references/supported-formats.md, and the result-envelope structure is explained three times (Quick Start, Result Envelope section, Pitfall #1).

4 / 5

Actionability

Every section is copy-paste ready: complete runnable snippets for Python, Node, Rust, and CLI (installation, quick start, configuration in four languages plus TOML), and error handling with exact exception types ('raise a plain RuntimeError... catch RuntimeError', 'throws plain Error objects'). This matches the anchor for fully executable, copy-paste-ready code covering the common cases.

5 / 5

Workflow Clarity

The path is clearly sequenced (install → extract → configure → batch → handle errors) and batch operations do include a verification checkpoint ('inspect output.errors for non-fatal per-input failures', 'per-input failures ... are reported non-fatally in result.errors'), so the batch-validation cap does not apply. It sits at anchor 4 rather than 5 because there is no explicit fix-and-retry feedback loop (e.g., what to do with a failed input in a batch) and no validation guidance for the destructive-ish reconfigure/retry path.

4 / 5

Progressive Disclosure

The body is a genuine overview with eight clearly signaled, one-level-deep references ('Python API Reference — All functions, config classes, plugin protocols, exact signatures', etc.), all of which exist in references/, with bulk API detail correctly pushed to those files. The inline formats table is a summary with an explicit pointer to the complete reference, which is exactly the appropriate split, matching the anchor for a clear overview with well-signaled one-level-deep references.

5 / 5

Total

18

/

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: concrete third-person capability statement, explicit use-when clause, comprehensive action coverage, and library-specific triggers. The only gap is keyword breadth — file extensions and everyday synonyms (e.g., .pdf/.docx, 'convert documents') that users naturally say are absent.

Suggestions

Add one or two file extensions or natural synonyms to the trigger phrasing, e.g. 'Use when extracting text or tables from PDF, DOCX, or scanned document files' — the current trigger only fires on users who already name the Xberg library.

Broaden the when-clause beyond 'writing code that calls Xberg APIs' to also cover task-shaped triggers like 'OCR a scanned PDF' or 'batch-extract document text', since users often describe the task before knowing the tool.

DimensionReasoningScore

Specificity

"Extract text, tables, metadata, and images from 107 document formats" names multiple specific concrete actions (text, tables, metadata, images) and the coverage list ("installation, extraction (sync/async), configuration (OCR, chunking, output format), batch processing, error handling, and plugins") makes capability coverage comprehensive. It matches the anchor for listing multiple specific concrete actions with comprehensive coverage, not the anchor-4 case of minor gaps.

5 / 5

Completeness

The 'what' is explicit ("Extract text, tables, metadata, and images from 107 document formats") and the 'when' is explicit and concrete ("Use when writing code that calls Xberg APIs in Python, Node.js/TypeScript, Rust, or CLI"), clearly matching the anchor for explicitly answering both what AND when with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural terms include PDF, Office, images, HTML, email, archives, OCR, batch processing, chunking, and language names (Python, Node.js/TypeScript, Rust, CLI) — good keyword coverage. It falls short of the anchor-5 example because no file extensions (.pdf, .docx) or common synonyms ("convert documents", "parse files") appear.

4 / 5

Distinctiveness Conflict Risk

Naming the specific library ("using Xberg") and tying triggers to "calls Xberg APIs" gives a clear niche with distinct triggers and minimal conflict risk versus generic document skills. The what-clause covers broad document extraction, but the explicit use-when clause keeps triggering anchored to the named library, fitting anchor 5 rather than anchor 4's 'minor overlap risk'.

5 / 5

Total

19

/

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
xberg-io/xberg
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.