CtrlK
BlogDocsLog inGet started
Tessl Logo

improvement

Guide for making improvements to existing ClaudeBar functionality using TDD. Use this skill when: (1) Enhancing existing features (not adding new ones) (2) Improving UX, performance, or code quality (3) User asks "improve X", "make Y better", or "enhance Z" (4) Small enhancements that don't require full architecture design For NEW features, use implement-feature skill instead.

66

Quality

80%

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 ./.claude/skills/improvement/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

70%

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

A well-organized, clearly sequenced TDD-improvement guide with explicit validation checkpoints and clean navigation. It loses points on conciseness (a token-heavy ASCII diagram restating known TDD) and actionability (the canonical pattern is shown only with placeholder tokens).

Suggestions

Replace the ASCII box-drawing workflow diagram with a concise numbered list; the red/green TDD cycle is already known to Claude and the diagram is token-heavy.

Add a second fully concrete, copy-paste-ready test example beyond lowestQuota so the canonical TDD pattern is not shown only with {placeholder} tokens.

DimensionReasoningScore

Conciseness

Most sections are lean and well-structured, but the ASCII box-drawing workflow diagram restates the red/green TDD cycle Claude already knows ("Test should FAIL initially", "Keep existing tests passing"), adding token weight that could be tightened. Not 3 because the diagram re-explains a known concept; not 1 because the body is largely efficient and free of generic padding.

2 / 3

Actionability

Provides a real command ("swift test") and one concrete example test (UsageSnapshot/lowestQuota), but the canonical TDD pattern uses placeholders ("{Component}Tests", "{describes improved behavior}", "improvedMethod") rather than copy-paste-ready code. Not 3 because the main pattern is a template with placeholder tokens; not 1 because concrete guidance and a real example are present.

2 / 3

Workflow Clarity

A clear 3-step sequence (Understand → Red → Green) is reinforced by a checklist with explicit validation checkpoints ("Test FAILS before implementation", "All existing tests still pass (`swift test`)"). Not 2 because validation checkpoints are explicit, not implicit.

3 / 3

Progressive Disclosure

Well-organized sections with a single well-signaled one-level-deep external reference ("Full documentation: docs/ARCHITECTURE.md"); no nested references and no bundle files needed. Not 2 because the reference is clearly signaled and the overview is appropriately self-contained.

3 / 3

Total

10

/

12

Passed

Description

90%

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 strong description that clearly states what the skill does, when to use it with explicit natural-language triggers, and how it differs from sibling skills. Its only weakness is specificity: the actions are described as categories (improving/enhancing) rather than concrete operations.

Suggestions

Replace abstract verbs with concrete operations the skill performs, e.g. 'add computed properties, refactor status calculations, add caching, improve error messages' to lift specificity.

Name a few concrete improvement types directly in the description rather than only the UX/performance/code-quality categories.

DimensionReasoningScore

Specificity

Names the domain ("existing ClaudeBar functionality") and action categories ("Enhancing existing features", "Improving UX, performance, or code quality") but relies on abstract verbs rather than concrete operations, matching anchor 2. Not 3 because the actions are categories (improving/enhancing) rather than specific operations like 'add computed properties' or 'refactor parsing'; not 1 because a domain and multiple action categories are explicitly named.

2 / 3

Completeness

Clearly answers both what ("Guide for making improvements to existing ClaudeBar functionality using TDD") and when ("Use this skill when: (1)…(4)…") with explicit numbered triggers. Not 2 because the 'when' is explicit, not merely implied.

3 / 3

Trigger Term Quality

Includes natural phrases users would actually say — "improve X", "make Y better", "enhance Z" — giving good coverage of trigger variations. Not 2 because it lists multiple natural phrasings rather than a single generic term.

3 / 3

Distinctiveness Conflict Risk

Carves a clear niche with "existing features (not adding new ones)" and explicitly disambiguates via "For NEW features, use implement-feature skill instead", making conflict unlikely. Not 2 because the boundary against sibling skills is stated, not just implied.

3 / 3

Total

11

/

12

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 1 suspicious

Warning

Total

15

/

16

Passed

Repository
tddworks/ClaudeBar
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.