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.
78
73%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/dwmkerr/skills/project-setup/SKILL.mdQuality
Discovery
82%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 has strong trigger terms and good completeness with an explicit 'Use when' clause covering multiple natural phrasings. Its main weakness is the vagueness of 'standard configuration' — it doesn't specify what concrete actions are performed (e.g., creating README, LICENSE, .gitignore, setting visibility). Distinctiveness could also be improved by clarifying this is specifically about GitHub remote repository creation.
Suggestions
Replace 'standard configuration' with specific actions like 'Creates a GitHub repository with README, LICENSE, .gitignore, and initial commit'
Add clarifying language to distinguish from local-only git init, e.g., 'Creates a new remote GitHub repository' to reduce conflict with local project scaffolding skills
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (GitHub project) and one action (create with standard configuration), but doesn't list specific concrete actions like initializing git, creating README, setting up .gitignore, configuring CI, etc. 'Standard configuration' is vague. | 2 / 3 |
Completeness | Clearly answers both 'what' (create a new GitHub project with standard configuration) and 'when' (explicit 'Use when' clause with multiple trigger phrases). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would actually say: 'create a project', 'set up a new repo', 'initialize a repository', 'start a new GitHub project'. Good coverage of common phrasings. | 3 / 3 |
Distinctiveness Conflict Risk | While GitHub-specific, 'create a project' and 'initialize a repository' could overlap with generic project scaffolding skills or local git initialization skills. The scope is somewhat ambiguous between GitHub-specific operations and general repo setup. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, actionable skill with fully executable commands and clear sequencing for setting up a GitHub project. Its main weaknesses are the lack of validation checkpoints after API calls (e.g., verifying settings were applied), some verbosity in explanatory sections (version strategy, inline license text), and all content being in a single file when some could be referenced externally.
Suggestions
Add validation steps after API calls, e.g., `gh api repos/dwmkerr/<repo-name> --jq '.allow_squash_merge, .allow_merge_commit'` to verify settings were applied correctly.
Move the full MIT License text and Release Please configuration details into separate referenced files to keep the main skill leaner.
Trim the version strategy explanation in step 6 — the config values with brief inline comments would suffice for Claude.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary verbosity. The full MIT License text is boilerplate Claude knows, the version strategy explanation in step 6 is somewhat lengthy, and the 'What Gets Created' summary partially duplicates the setup steps. However, most content earns its place. | 2 / 3 |
Actionability | Every step provides fully executable, copy-paste ready bash commands and file contents. The gh CLI commands are specific with exact flags and API endpoints. The README template includes a concrete example. This is highly actionable. | 3 / 3 |
Workflow Clarity | Steps are clearly numbered and sequenced, but there are no validation checkpoints. After configuring repo settings via API calls, there's no verification that the settings were applied correctly. For operations that modify GitHub repository configuration, a validation step (e.g., checking the repo settings after applying them) would be appropriate. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and numbered steps, but it's somewhat long (~120 lines of substantive content) and could benefit from splitting the Release Please setup and license text into separate referenced files. Everything is inline in a single document. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- dwmkerr/claude-toolkit
- Commit
ccd0360
- 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.