CtrlK
BlogDocsLog inGet started
Tessl Logo

harvest

Collecting GitHub PR data and generating work reports. Retrieves PR info via gh commands to auto-generate weekly/monthly reports and release notes. Use when work reporting or PR analysis is needed.

60

Quality

71%

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 ./.archive/harvest/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

A richly structured, highly actionable read-only PR-reporting skill with a clear workflow, concrete thresholds, and strong guardrails. Its two weaknesses are repetition that inflates token cost, and a progressive-disclosure design whose referenced detail files are missing from the bundle, breaking navigation.

Suggestions

Deduplicate PR-size benchmarks and the AI-inflated-metrics caveat so each rule lives in one canonical place (Critical Decision Rules), with other sections cross-referencing rather than restating.

Ship the referenced reference/*.md and _common/*.md files in the bundle (or inline the most critical ones, e.g. gh-commands and report-templates) so the Reference Map's links resolve.

Add a couple of literal, copy-pasteable gh command examples inline in Core Contract for the most common fetch patterns, rather than deferring all syntax to the (currently absent) gh-commands reference.

DimensionReasoningScore

Conciseness

Dense and mostly actionable, but redundancy and some over-explanation remain: PR-size benchmarks (200/400/1000 LOC) recur in Core Contract, Trigger Guidance, and Critical Decision Rules, and the AI-inflated-metrics caveat is restated in both Core Contract and Boundaries→Never; Goodhart's Law and the McKinsey controversy are explained at length. Not a 2 because content is substantive rather than padded, not a 4 because the repetition is more than minor.

3 / 5

Actionability

Highly concrete guidance throughout — "per_page=100" with "gh api --paginate", LOC thresholds (200/400/1000), time benchmarks (<6h/<13h/<26h/<48h), exact output filenames (pr-summary-YYYY-MM-DD.md), and subcommand dispatch. Not a 5 because literal executable gh command examples are deferred to reference/gh-commands.md rather than shown inline, leaving a minor gap for the common cases.

4 / 5

Workflow Clarity

Clear SURVEY→COLLECT→ANALYZE→REPORT→VERIFY sequence in a phase table, with a VERIFY validation step, Ask-First gating for >100-PR batches, and a graceful-degradation feedback rule ("never fabricate; label degraded sections"). Not a 5 because validation checkpoints are stated abstractly rather than as explicit pass/fail checks with retry loops.

4 / 5

Progressive Disclosure

Structure and signaling are excellent — a Reference Map, one-level-deep references, well-organized sections — but the referenced reference/*.md and _common/*.md files are absent from the bundle (only scripts/ exists), so navigation leads to non-existent files and the disclosure is not actually realized. Not a 4 because the missing-file gap is more than a minor organization issue.

3 / 5

Total

14

/

20

Passed

Description

78%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 solid third-person description that states both capability and use-when, with concrete verbs and a clear GitHub-PR niche. The main weakness is a relatively thin trigger clause that could surface more of the natural phrases users say (changelog, PR summary, retro).

Suggestions

Broaden the "Use when" clause with concrete trigger phrases a user would naturally say, e.g. "Use when generating weekly/monthly work reports, release notes or changelogs, sprint retrospectives, or analyzing PR activity".

Mention key report variants (release notes, DORA, retrospective) in the description so the trigger surface matches the skill's actual scope.

DimensionReasoningScore

Specificity

Quotes concrete actions — "Collecting GitHub PR data", "Retrieves PR info via gh commands", "auto-generate weekly/monthly reports and release notes" — listing several specific capabilities; not a 5 because it summarizes rather than enumerating the full breadth of report types (retros, DORA, OKR, client reports).

4 / 5

Completeness

Both what (collect PR data via gh, generate reports/release notes) and when ("Use when work reporting or PR analysis is needed") are present; not a 5 because the when-clause lacks the concrete multi-trigger phrasing of the anchor example (no "or when the user mentions release notes / changelogs" expansion).

4 / 5

Trigger Term Quality

Natural terms appear — "weekly/monthly reports", "release notes", "work reporting", "PR analysis" — but the explicit "Use when work reporting or PR analysis is needed" clause is narrow and omits synonyms a user would say (changelog, PR summary, sprint retro); not a 5 due to missing common variations.

4 / 5

Distinctiveness Conflict Risk

"GitHub PR data" + "gh commands" pins a clear niche with distinct triggers and minimal overlap risk; re-reading anchor 4 ("minor overlap risk with closely related skills") confirms this is more distinct, fitting the 5 anchor's clear-niche criterion.

5 / 5

Total

17

/

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
simota/agent-skills
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.