project-setup

Create a new GitHub project with standard configuration. Use when user asks to "create a project", "set up a new repo", "initialize a repository", or wants to start a new GitHub project.

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Failed to scan

The risk profile of this skill

Quality

Content

76%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 highly actionable and lean, giving copy-paste commands and complete config for every step. Its main gap is workflow safety: the provisioning sequence has no verification checkpoints between steps, so failures mid-flow would not be caught.

Suggestions

Add verification checkpoints after key steps — e.g., 'gh repo view <repo-name>' to confirm creation and a 'gh api …/rulesets' check after branch protection — to lift workflow clarity above 3.

Move the full MIT license text into a references/LICENSE template file and link to it, keeping the SKILL.md body as a concise overview.

Note the fork/subagent context assumption somewhere the body can see (the frontmatter comment is non-standard YAML) so the execution model is unambiguous.

Dimension	Reasoning	Score
Conciseness	The body is dominated by executable gh commands, JSON config, and the license text with little padding; only minor over-explanation such as 'Release Please automates version bumps and changelogs from conventional commits' could be trimmed, matching the efficient-with-minor-trim anchor.	4 / 5
Actionability	Provides copy-paste-ready gh commands with exact flags, complete release-please JSON configs, the full MIT license text, a README template plus a concrete worked example — covering the common cases fully.	5 / 5
Workflow Clarity	The seven steps are clearly numbered and sequenced with a 'What Gets Created' overview, but there are no validation or verification checkpoints between provisioning steps (e.g., confirm repo created, confirm settings applied, confirm push succeeded), matching the 'sequence present but checkpoints missing' anchor.	3 / 5
Progressive Disclosure	Sections are well-organized (overview, 7 numbered subsections, example usage) with no bundle files to navigate; the inlined full MIT license and README example are minor organization gaps that keep it just below the ideal split/overview anchor, and the under-50-line exception does not apply.	4 / 5
	Total	16 / 20 Passed

Description

86%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 strong: it pairs a clear purpose statement with an explicit, well-phrased 'Use when…' trigger list rich in natural synonyms. Its only weakness is that 'what' is summarized as 'standard configuration' without naming the concrete capabilities the body delivers.

Suggestions

Replace 'with standard configuration' with 2-3 concrete deliverables (e.g., 'with branch protection, squash-merge settings, MIT license, and a starter README') to lift specificity.

Consider adding 'new repository' or 'repo' as an explicit noun in the 'what' clause to reinforce distinctiveness against generic git skills.

Dimension	Reasoning	Score
Specificity	Names the domain and one concrete action ("Create a new GitHub project") but "with standard configuration" is generic and no further concrete actions are enumerated, matching the anchor for 1-2 concrete actions without comprehensive coverage.	3 / 5
Completeness	Explicitly answers both what ("Create a new GitHub project with standard configuration") and when ("Use when user asks to…") with concrete trigger phrases, matching the top anchor.	5 / 5
Trigger Term Quality	Supplies comprehensive natural trigger phrases users would actually say — "create a project", "set up a new repo", "initialize a repository", "start a new GitHub project" — covering multiple synonyms for the same intent.	5 / 5
Distinctiveness Conflict Risk	The project/repo-creation niche is mostly distinct with specific triggers, but there is minor overlap risk with closely related git or repository-management skills, so it sits just below the clear-niche anchor.	4 / 5
	Total	17 / 20 Passed

Validation

93%

Warnings & errors only

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

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: dwmkerr/claude-toolkit
Path: plugins/dwmkerr/skills/project-setup/SKILL.md
Commit: 4316684

Reviewed: 8 days ago

Table of Contents

Discovery Implementation Validation

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.