CtrlK
BlogDocsLog inGet started
Tessl Logo

vp-gitignore-builder

Build and merge repository .gitignore files or global gitignore files using github/gitignore templates with smart target separation. Use when the user asks to "create gitignore", "build .gitignore", "add gitignore templates", "set up gitignore", "update gitignore", "create global gitignore", or requests "/gitignore". Also trigger when observing projects without .gitignore, seeing untracked files like node_modules/, .env, __pycache__/, or *.log in git status, or after git init in a new repo. Boundary: not for .dockerignore or other non-git ignore files.

75

Quality

92%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Advisory

Suggest reviewing before use

SKILL.md
Quality
Evals
Security

Quality

Content

85%

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 well-sequenced with strong validation checkpoints and clean progressive disclosure to a real reference file and bundled script. Its only real weakness is conciseness: the gitignore syntax primer and decorative box-drawing output template restate knowledge Claude already has.

Suggestions

Remove or condense the "Gitignore Syntax Reminders" section — Claude already knows gitignore negation, comments, trailing-slash, and wildcard semantics; keep only any project-specific nuance.

Replace the decorative box-drawing START/END markers in the output example with a minimal comment header (e.g. `# START - github/gitignore templates`) to cut tokens without losing the replace-on-update intent.

Consider moving the full three-section output-structure example into references/examples.md and keeping only the section-order summary inline.

DimensionReasoningScore

Conciseness

The body is mostly efficient tables and executable commands, but it pads with a "Gitignore Syntax Reminders" section explaining negation, comments, trailing slashes, and wildcards — gitignore basics Claude already knows — and an elaborate box-drawing output template; it is not a 1 because the bulk is actionable rather than a concept explainer, and not a 3 because of those redundant explanations and decorative markers.

2 / 3

Actionability

Provides fully executable, copy-paste-ready commands — `scripts/merge-gitignore.sh --target repo Node Python` plus escape-hatch flags and a complete exit-code table — alongside concrete indicator-file detection tables; it is not a 2 because the guidance is complete and executable rather than pseudocode or vague.

3 / 3

Workflow Clarity

Seven steps are clearly sequenced with explicit validation checkpoints: a confirmation prompt in Step 3, EOL-conflict handling via exit code 2 in Step 5, and a diff-preview confirmation before writing in Steps 6–7, forming a validate/confirm feedback loop; it is not a 2 because checkpoints are explicit rather than merely implied.

3 / 3

Progressive Disclosure

The body is an organized overview that signals one well-defined, one-level-deep reference — [examples.md](references/examples.md), verified to exist — and delegates the executable logic to the bundled scripts/merge-gitignore.sh (also verified real), keeping navigation clear; it is not a 2 because references are clearly signaled and content is appropriately split rather than inlined or nested.

3 / 3

Total

11

/

12

Passed

Description

100%

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 excellent: it states concrete capabilities, provides abundant natural trigger phrases covering both explicit requests and behavioral signals, and even includes a boundary clause to prevent misfires. It uses third-person/imperative voice with no first- or second-person penalty triggers.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — "Build and merge repository .gitignore files or global gitignore files using github/gitignore templates" — naming both repo and global targets and the merge operation, matching the anchor for several specific actions; it is not a 2 because it goes beyond naming a single domain/action.

3 / 3

Completeness

Explicitly answers both what ("Build and merge repository .gitignore files or global gitignore files...") and when ("Use when the user asks...", "Also trigger when observing projects without .gitignore...") with explicit triggers; the judging guideline caps completeness at 2 only when an explicit 'Use when...' is missing, and one is present, so it is not capped at 2.

3 / 3

Trigger Term Quality

Covers natural phrasings a user would actually say — "create gitignore", "build .gitignore", "add gitignore templates", "set up gitignore", "update gitignore", "create global gitignore", and "/gitignore" — giving good coverage of common variations; it is not a 2 because the keyword set is broad and natural rather than partial.

3 / 3

Distinctiveness Conflict Risk

Occupies a clear niche (gitignore builder) with distinct triggers and an explicit boundary ("not for .dockerignore or other non-git ignore files"), making conflict with other skills unlikely; it is not a 2 because the scope and boundary are too sharp to overlap meaningfully with similar skills.

3 / 3

Total

12

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

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