CtrlK
BlogDocsLog inGet started
Tessl Logo

iptvnator-sqlite-db-worker

Repository-specific guidance for Electron non-EPG SQLite worker boundaries, request-scoped DB progress events, and validation for slow DB operations.

57

Quality

64%

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

Fix and improve this skill with Tessl

tessl review fix ./.codex/skills/iptvnator-sqlite-db-worker/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

72%

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

The content is concise, well-structured, and points clearly to the right files and validation commands. Its main gap is the lack of an explicit sequenced validation workflow and executable operation examples.

Suggestions

Add a short numbered workflow (make change -> run pnpm nx test electron-backend -> fix and re-run -> run targeted E2E if touched) to make the validation feedback loop explicit.

Include one executable code snippet showing how to emit a request-scoped DB_OPERATION_EVENT progress event, so the core rule is copy-paste ready.

Note when the architecture doc should be consulted first (e.g. 'Read docs/architecture/sqlite-db-worker.md before restructuring worker boundaries') to strengthen navigation.

DimensionReasoningScore

Conciseness

The body is lean and well-organized with no padding or explanation of concepts Claude already knows; every line (ownership paths, rules, validation commands) earns its place and assumes competence.

3 / 3

Actionability

Concrete guidance is present (copy-paste commands like 'pnpm nx test electron-backend' and 'IPTVNATOR_TRACE_DB=1', plus exact file paths), but the Rules section is directive rather than providing executable code examples for the operations themselves, so it is not fully copy-paste ready for the core work.

2 / 3

Workflow Clarity

A dedicated Validation section provides explicit verification commands, but there is no sequenced make-change -> validate -> fix -> retry workflow with checkpoints, which the rubric expects for level 3 on database operations.

2 / 3

Progressive Disclosure

Under 50 lines with clean sections (Ownership, Rules, Validation) and a single clearly signaled one-level reference to docs/architecture/sqlite-db-worker.md; no bundle files are needed, so the structure is well organized.

3 / 3

Total

10

/

12

Passed

Description

57%

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 specific and distinctive with a clear niche, but it omits an explicit 'Use when...' trigger and leans on technical jargon over natural trigger terms. It is solid but not exemplary.

Suggestions

Add an explicit trigger clause, e.g. 'Use when modifying Electron SQLite operations, worker-backed DB flows, or Xtream/playlist persistence.'

Soften jargon with more natural user-facing terms (e.g. 'SQLite database', 'long-running database jobs') alongside the technical phrasing.

Reframe the guidance areas as concrete actions (e.g. 'Keeps heavy SQLite work off the main thread, emits progress events, validates slow DB operations') to lift specificity.

DimensionReasoningScore

Specificity

Phrases like 'Electron non-EPG SQLite worker boundaries' and 'request-scoped DB progress events' name a concrete domain and several specific topics, but the description frames them as guidance areas rather than enumerating multiple discrete concrete actions as the level-3 anchor does.

2 / 3

Completeness

It clearly states what the skill provides ('Repository-specific guidance for...') but contains no 'Use when...' clause or equivalent explicit trigger guidance, which per the rubric caps completeness at 2.

2 / 3

Trigger Term Quality

Terms such as 'SQLite', 'Electron', and 'DB' are relevant keywords a developer might say, but the description leans on technical jargon ('non-EPG', 'request-scoped DB progress events', 'worker boundaries') and lacks common natural variations, so it is not the full coverage of level 3.

2 / 3

Distinctiveness Conflict Risk

The highly specific scope ('Electron non-EPG SQLite worker boundaries', 'request-scoped DB progress events') carves out a clear narrow niche that is unlikely to trigger for unrelated skills.

3 / 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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
4gray/iptvnator
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.