CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

issue-harvester

Maintain exhaustive Slate/Plate issue-closure ledgers from current issue, PR, test and local proof evidence.

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/issue-harvester/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

81%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.

This is a strong operational skill: clearly ordered loops with real validation gates and fallback behavior, concrete commands throughout, and provider detail correctly pushed into a single one-level-deep reference. The main costs are a body long enough that some command catalogs read as inlined reference material, and a handful of steps that defer to external playbooks or a generator script the bundle does not actually provide.

Suggestions

Move the gh provenance-probe and coverage-search command catalogs into a references/ file (like gitcrawl.md) and keep only the decision rules inline, shortening the SKILL.md body.

Provide or at least sketch the ledger generator (or its TSV/Markdown emission format) in a scripts/ or references/ file, so 'regenerate the ledger' is executable rather than delegated to an unspecified local method.

DimensionReasoningScore

Conciseness

The body is dense, imperative, and assumes competence — it teaches a novel ledger workflow rather than concepts Claude already knows, and it delegates provider detail to the gitcrawl reference. It sits at anchor 4 rather than 5 because of minor trimmable padding: the canonical docs path is repeated nearly verbatim in four sections, and cryptic asides like "A ledger family that mixes generated input, manual classification and a summary gets a local check that fails when they drift" restate rules already implied elsewhere.

4 / 5

Actionability

Most guidance is copy-paste ready: concrete gitcrawl/gh/rg commands with explicit JSON field lists, exact artifact paths, an enumerated row schema, and closed sets of owner/status values. It stops short of anchor 5 because a few steps hand-wave: the ledger generator script is never provided ("update the TSV/MD by the smallest reliable local method"), and steps defer to external documents not in the bundle ("the target repo/license gate from `research harvest`", "the Tests rule in `AGENTS.md`").

4 / 5

Workflow Clarity

The multi-step processes are explicitly sequenced (6-step resume path, 6-step bootstrap path, 8-step --refresh-only, 12-step issue loop) with explicit validation checkpoints ("run that command before marking covered", "Run focused verification", "The refresh is complete only when compact docs artifacts are current or the exact provider blocker is recorded") and genuine feedback loops for a batch operation: provider fallback chain, `needs-repro` when behavior is uncertain, metadata-change re-read without erasing decisions, and unambiguous stop rules. This matches anchor 5, including the batch-operation feedback-loop requirement.

5 / 5

Progressive Disclosure

The body references exactly one bundle file, [gitcrawl](./references/gitcrawl.md), which exists, is one level deep, and is clearly signaled at the point of use — the provider-specific install/archive detail is appropriately split out. It stays at anchor 4 rather than 5 because the SKILL.md is a ~280-line full procedure rather than an overview-plus-references: the gh provenance probes, coverage-search patterns, and the three legacy header-family descriptions are inlined reference material that could live in separate files for easier navigation.

4 / 5

Total

17

/

20

Passed

Description

53%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.

The description is concrete and unambiguous about the niche (Slate/Plate issue-closure ledger maintenance) but reads like an internal spec line rather than a trigger description: one action verb, heavy internal jargon ("closure ledgers", "local proof evidence"), and no "Use when..." clause. It would rarely fire for the wrong skill, but it would also rarely fire for the right one unless the user already speaks the ledger vocabulary.

Suggestions

Add an explicit 'Use when...' clause naming natural triggers, e.g. 'Use when the user wants exhaustive issue history coverage for Slate, Plate, Lexical, ProseMirror, or other editor repos, or wants to resume an issue-closure ledger.'

Enumerate 2-3 concrete actions instead of the single verb 'maintain', e.g. 'Refreshes issue inventory, verifies PR/test provenance for each closed issue, and writes local regression tests for uncovered defects.'

Replace internal jargon ('issue-closure ledgers', 'local proof evidence') with user-facing synonyms like 'closed-issue coverage', 'issue history', and 'regression test coverage' so natural phrasing matches.

DimensionReasoningScore

Specificity

"Maintain exhaustive Slate/Plate issue-closure ledgers from current issue, PR, test and local proof evidence" names a concrete domain (Slate/Plate issue-closure ledgers) and one concrete action (maintain ledgers built from issue/PR/test/proof evidence). It stays at anchor 3 because only the single verb "maintain" is offered — no enumeration of the underlying actions (refresh inventory, verify coverage, write regression tests, resume ledgers) that would reach anchor 4's "several specific actions".

3 / 5

Completeness

The "what" is stated concretely (maintain exhaustive issue-closure ledgers from issue, PR, test, and local proof evidence), but there is no "Use when..." clause or equivalent trigger guidance anywhere in the description, which caps completeness at 3 per the judging guidelines. It is not anchor 4 because the "when" is entirely missing rather than merely implicit; it is not anchor 2 because the "what" is clear, not vague.

3 / 5

Trigger Term Quality

Terms like "issue-closure ledgers", "local proof evidence", and "Slate/Plate" are internal jargon rather than phrases a user would naturally say; only "issue", "PR", and "test" are natural keywords. This matches anchor 3 ("some relevant keywords but missing common variations") — not anchor 2, since the keywords are domain-relevant rather than generic, but not anchor 4 because natural trigger phrases like "closed issues", "issue history", or "test coverage" are absent.

3 / 5

Distinctiveness Conflict Risk

"Slate/Plate issue-closure ledgers" carves out a clear niche that would rarely trigger a generic PDF/Excel/document skill, matching anchor 4 ("mostly distinct; minor overlap risk"). It falls short of anchor 5 because the broader words "issue, PR, test and local proof evidence" overlap with related issue-triage and test-coverage skills in the same ecosystem (the body itself references a Triage playbook and maintainer slate-issue), so it is not trigger-proof against closely related skills.

4 / 5

Total

13

/

20

Passed

Validation

81%

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

Validation — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

frontmatter_unknown_keys

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

Warning

Total

13

/

16

Passed

Repository

udecode/plate

Path

.agents/skills/issue-harvester/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.