CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

plannotator-annotate

Open Plannotator's annotation UI for a file, folder, or URL, then address the returned annotations.

65

Quality

82%

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

92%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 body is an exemplary lean operational protocol: an exact runnable command, a precise argument specification, and explicit handling of both the resolution-failure and user-dismissal cases, including the critical safety note that closing the session is not approval. The only notable gap is that the success path — how to handle actual returned annotations — is left entirely to the description and inference.

Suggestions

Add one sentence for the success path, e.g. "When annotations are returned, address each one by editing the target file/URL content accordingly" so the body is self-sufficient.

Optionally state what the annotations look like (e.g. JSON structure) so handling of the non-dismissed output is as concrete as the dismissal case.

DimensionReasoningScore

Conciseness

Every line is operational — the run command, the argument specification with concrete extensions, and two outcome-handling rules — with zero padding and no explanation of concepts Claude already knows. This matches the "lean and efficient; every token earns its place" anchor exactly.

5 / 5

Actionability

The body provides a copy-paste-ready command with the exact env var, a precise argument spec (".md, .txt, .yaml, .json, .toml, .ini, .csv, .log, …"), and concrete handling of both failure modes including the literal signature `"decision": "dismissed"`. It falls short of anchor 5 only because the success path — what to actually do with returned annotations — is stated nowhere in the body, only implied via the description.

4 / 5

Workflow Clarity

This is a simple single-purpose skill under 50 lines whose single action is unambiguous, and it includes explicit validation of the outcome (empty output or dismissed JSON) plus a feedback loop (disambiguate the target and re-run). Not destructive or batch, so no cap applies; the simple-skill exception for a 5 fits.

5 / 5

Progressive Disclosure

The skill is under 50 lines, needs no external references, and references no bundle files (none exist in references/, scripts/, or assets/). Per the guideline, well-organized short-form content with no external files needed scores 5; the body's short paragraphs are cleanly separated by concern.

5 / 5

Total

19

/

20

Passed

Description

62%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 concise, concrete, and clearly distinct thanks to the named tool, but it omits any "when to use" trigger guidance, capping completeness, and lacks synonym coverage for natural trigger phrases. Since the skill is user-invoked (disable-model-invocation: true), the missing trigger clause mainly affects human discoverability rather than model-triggering risk.

Suggestions

Append a trigger clause naming the natural user phrases, e.g. "Use when the user wants to annotate, comment on, or review a config file, folder, or URL with Plannotator."

Add one or two synonyms for annotation ("comments", "review notes") so users' natural vocabulary matches the description.

Slightly sharpen the second action — e.g. "then apply the returned annotations to the target" instead of the vague "address the returned annotations".

DimensionReasoningScore

Specificity

"Open Plannotator's annotation UI for a file, folder, or URL" names a concrete tool, explicit target types, and a first action, while "then address the returned annotations" adds a second action — though "address" is underspecified. It lists several specific actions with minor gaps rather than the 1–2 of anchor 3 or the comprehensive coverage of anchor 5.

4 / 5

Completeness

The "what" is clear (open the annotation UI for a target, then address the annotations), but there is no "Use when..." clause or equivalent trigger guidance anywhere, which caps completeness at 3 per the judging guidelines. Not anchor 2 because the "what" is concrete and specific, and not anchor 4 because the "when" is entirely absent rather than merely imprecise.

3 / 5

Trigger Term Quality

Natural terms present include "Plannotator", "annotation UI", "returned annotations", and "file, folder, or URL", but common variations a user might say ("comment", "review", "feedback", "markup") are missing. Coverage is relevant but incomplete, matching anchor 3 rather than the near-complete coverage of anchor 4.

3 / 5

Distinctiveness Conflict Risk

Naming the specific tool "Plannotator" establishes a clear niche with distinct triggers; only other Plannotator skills could plausibly overlap, which is minimal conflict risk matching anchor 5. It is not anchor 4 because the tool name plus the annotate-specific action leaves essentially no generic surface area.

5 / 5

Total

15

/

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

backnotprop/plannotator

Path

apps/kiro-cli/skills/plannotator-annotate/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.