CtrlK
BlogDocsLog inGet started
Tessl Logo

changelog

Generates a personal markdown changelog of merged or closed pull requests authored by the current user and Linear tickets the user closed or worked on, over a configurable window (default 7 days), grouped by feature area (e.g. Dashboards, Agent0). Inputs sourced from `gh search prs --author=@me` and the Linear MCP. Use for weekly recaps, status updates, performance reviews, or end-of-sprint summaries. Triggers on "changelog", "what have I done", "weekly summary", "my recent work", "recap my week", "/changelog".

72

Quality

91%

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

SKILL.md
Quality
Evals
Security

Quality

Content

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

The content is highly actionable and operationally safe — executable commands, exact error strings, and validation guards for every failure mode of a batch fetch-and-render job. Its weaknesses are a dangling load-bearing reference (templates/changelog.md is absent from the bundle) and notable rule repetition across the Arguments, Examples, Anti-patterns, and Definition-of-done sections that inflates token cost without adding information.

Suggestions

Ship the referenced templates/changelog.md file (or inline the template verbatim in a Template section) — the skill instructs rendering 'verbatim' against a file that does not exist in the bundle, so the workflow dead-ends at the render step.

Deduplicate repeated rules: the scope-error message appears verbatim in three places and the Definition of done checklist restates the Arguments, Output rules, and Anti-patterns sections; consolidate to one authoritative statement per rule and reference it.

Move the ~100 lines of --audience=general and --scope=all rendering rules into a one-level-deep reference file (e.g. references/rendering-modes.md) so the core SKILL.md body stays a lean overview.

DimensionReasoningScore

Conciseness

The body is dense with genuinely non-obvious, skill-specific rules (missing `mergedAt` in `gh search prs` JSON, inclusive `--closed` ranges, brand-name Title-casing, the 4-backtick outer fence) and assumes Claude's competence throughout. However, rules are repeated across sections — the scope-error string appears verbatim three times, and 'Definition of done' restates the Arguments, Output rules, and Anti-patterns sections — which keeps it below the fully lean anchor; it is above 'mostly efficient' because the padding is repetition of real rules, not explanation of concepts Claude already knows.

4 / 5

Actionability

Guidance is copy-paste ready: a complete argument-parsing bash block with BSD/GNU date fallback, an exact `gh search prs` query with field list and repo-filter insertion, exact error-message strings, a literal truncation-warning line, and a first-match-wins bucketing lookup table. The only non-concrete area (Linear MCP tool names) is explicitly and justifiably deferred to runtime resolution ('resolve the list-issues and get-issue tools at runtime ... do not hard-code the namespace'), so no key details are missing.

5 / 5

Workflow Clarity

A numbered six-step workflow with explicit validation checkpoints throughout: agent-side merged/closed partitioning by `state`, a truncation guard when results hit `LIMIT`, defined failure paths for missing/unauthenticated `gh` and unavailable Linear MCP (degrade with a notice, don't fail), a hard error for `--scope=current` outside a GitHub repo, an explicit empty-window state, and a closing checklist. As a batch read/render operation, every batch risk (truncation, empty results, source unavailability) has a defined response, so the batch-validation cap does not apply.

5 / 5

Progressive Disclosure

In-file section structure is clean (Arguments, Workflow, Data sources, Feature grouping, Output rules, Template, Examples, Anti-patterns), but the body's single external reference — [`templates/changelog.md`](./templates/changelog.md), cited three times and required for rendering 'verbatim' — does not exist in the bundle (no templates/ directory), so the load-bearing reference is a dead path. Also, all ~365 lines of rules are inlined in one file with the ~100 lines of scope/audience rendering rules as candidates for a separate reference file.

3 / 5

Total

17

/

20

Passed

Description

100%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 exemplary: third-person, concrete about what it does and which sources it reads, and explicit about when to use it with natural trigger phrases including the slash-command form. No fluff, no over-claims, no conflict risk with other skills.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — 'Generates a personal markdown changelog of merged or closed pull requests authored by the current user and Linear tickets the user closed or worked on, over a configurable window (default 7 days), grouped by feature area' — and names the data sources ('gh search prs --author=@me' and the Linear MCP). It is third person and comprehensively concrete; re-checking the anchors below, it is not merely 'several specific actions with minor gaps' (4) but full coverage.

5 / 5

Completeness

Both questions are answered explicitly: the 'what' is the detailed first sentence plus named inputs, and the 'when' is an explicit 'Use for weekly recaps, status updates, performance reviews, or end-of-sprint summaries. Triggers on ...' clause with concrete trigger phrases — exactly the top-anchor pattern; the 4 anchor ('when could be more explicit') is clearly surpassed.

5 / 5

Trigger Term Quality

The trigger list covers the natural phrases a user would actually say — '"changelog", "what have I done", "weekly summary", "my recent work", "recap my week", "/changelog"' — reinforced by use-cases ('weekly recaps, status updates, performance reviews, or end-of-sprint summaries'). These span synonyms and the slash-command form, matching the comprehensive-coverage anchor rather than the 'a few natural terms missing' (4) anchor.

5 / 5

Distinctiveness Conflict Risk

It carves a clear niche — a personal GitHub + Linear work recap grouped by feature area — with triggers like 'what have I done' and 'recap my week' that no generic reporting or git skill would claim. Conflict risk is minimal, fitting the clear-niche anchor rather than 'minor overlap risk' (4).

5 / 5

Total

20

/

20

Passed

Validation

75%

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

Validation — 12 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

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

relative_links

Relative link issues: 4 missing, 1 suspicious

Warning

Total

12

/

16

Passed

Repository
mthines/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.