Command Skill Creator

v0.1.0

Create automation command skills (slash commands) for Claude Code projects. Use when building `/slash-commands` that automate multi-step workflows - deploys,...

0· 0·0 current·0 all-time
byMisha Kolesnik@tenequm
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
The name/description (create command/slash-command skills) match the instructions and examples. All suggested operations — reading project files, discovering code paths, writing SKILL.md into .claude/skills/, and designing approval gates — are exactly what a command-skill creator should need. No unrelated credentials, binaries, or installs are requested.
Instruction Scope
SKILL.md explicitly instructs agents to read project files (including cross-repo paths like ~/pj/...), discover files via grep/glob, and save SKILL.md into target project directories. That is coherent for this purpose but grants broad discretion to read and modify repository files and to spawn shell-based steps (git, docker, kubectl, etc.) in generated commands. The guidance to 'trust Claude to understand natural language' is deliberately permissive and may produce commands that are over-broad unless the user requires explicit restrictions.
Install Mechanism
This is an instruction-only skill with no install spec and no code files to write or execute at install time, which is the lowest-risk model for a meta-skill of this type.
Credentials
The skill does not request environment variables, credentials, or config paths. Examples mention interacting with local repo state and common developer tools (git, docker, kubectl) — appropriate for creating command skills. There are no disproportionate secret requests.
Persistence & Privilege
The skill is not always-enabled and does not claim elevated platform privileges. It explicitly instructs authors to write SKILL.md files into project directories, which is expected behavior but means generated skills could later be run with side effects. The SKILL.md recommends setting disable-model-invocation: true for produced command skills, which is a safer default.
Assessment
This is a coherent authoring helper for building side-effecting command SKILL.md files. Before installing or using it: (1) Understand it encourages generation of commands that read and modify repositories and can include shell actions like git, docker, and kubectl — review every generated SKILL.md before saving or running. (2) Prefer the recommended disable-model-invocation: true in produced frontmatter so commands only run when explicitly invoked. (3) Restrict allowed-tools and limit any generated commands that reference home directories or cross-repo paths; require explicit approval gates for irreversible actions. (4) Never provide secrets or global credentials to the skill; vet any generated scripts for hardcoded paths or risky operations. If you want stronger guarantees, ask the skill to produce the SKILL.md only (do not auto-save), and perform a manual audit and test in a safe environment before committing.

Like a lobster shell, security has layers — review code before you run it.

latestvk976wnkdevvtqnwp99knm5bdqh844yf9

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

SKILL.md

Command Skill Creator

Create command-type skills - imperative prompts that guide Claude through phased execution of multi-step workflows. These are /slash-commands users invoke explicitly, not passive reference material.

Command skills live in project-level .claude/skills/<name>/SKILL.md and are invoked as /name [arguments].

When to use this vs skill-creator

  • This skill: Commands that DO things - deploy, commit, migrate, sync, release, scaffold. Side effects, approval gates, phased execution.
  • skill-creator: Knowledge that INFORMS Claude - coding standards, API references, framework guides. No side effects, auto-triggered by context.

Creation Workflow

Step 1: Understand Intent

Establish what the command automates. Ask (or extract from conversation context):

  • What does this command do? What are the major phases?
  • Which actions have side effects? (commits, deploys, file mutations, external APIs)
  • Does it take arguments? What kind?
  • Does it operate across multiple repos/projects?
  • Are there approval gates needed before irreversible actions?
  • What model complexity is needed? (most commands work with default; complex multi-phase reasoning may need opus)

If the user says "turn this into a command," extract the workflow from conversation history - tools used, sequence, corrections made.

Step 2: Design Frontmatter

Choose fields based on the command's nature. See the frontmatter reference table below.

Minimum viable frontmatter:

---
name: my-command
description: What it does and when to use it
disable-model-invocation: true
---

The reason disable-model-invocation: true is the default for command skills: commands have side effects by definition. If it had no side effects, it would be a knowledge skill instead. Setting this to true ensures the command only runs when the user explicitly invokes it, preventing Claude from autonomously deploying, committing, or mutating state.

Add more fields based on characteristics:

  • Takes arguments → argument-hint: "[arg-name]"
  • Needs strong reasoning → model: opus
  • Should restrict tools → allowed-tools: Read, Bash(specific-cmd *)
  • Self-contained exploration → context: fork + agent: Explore

Step 3: Structure Phases

Break the command into numbered phases with markdown headers (##). Claude follows numbered sequences with headers reliably - dense paragraphs get lost.

Common phase progression:

  1. Pre-flight - validate preconditions, read config, check state
  2. Research/Discovery - gather info for decisions (parallelize with subagents when possible)
  3. Present/Approve - show recommendations, wait for explicit user approval
  4. Execute - make the changes
  5. Verify - smoke tests, health checks
  6. Summary - report outcomes

Not every command needs all phases. A simple formatter might just be execute + verify.

Step 4: Add Safety

For each phase with side effects:

  • Approval gate: "STOP and wait for user approval before proceeding."
  • Error handling: "If X fails, stop and show the error. Do NOT proceed to Phase N."
  • Rollback path: How to undo if something goes wrong
  • Verification: Check that each action succeeded before moving on

These aren't bureaucracy - they prevent the command from autonomously deploying broken code or committing garbage. A 2-second approval pause costs nothing compared to rolling back a bad deploy.

Step 5: Write the SKILL.md

Generate the complete skill file. Keep it under 200 lines - command skills are prompts, not documentation. If the command needs extensive reference material, use supporting files.

Always start with the argument guard:

The target is: $ARGUMENTS

If no argument was provided, ask the user for one and stop.

Then: rules section, phases, summary template.

Step 6: Audit

Run through every item on the audit checklist below. Fix failures before finalizing. Present the audit results to the user.

Step 7: Place

Save the skill to the target project:

<project>/.claude/skills/<command-name>/SKILL.md

If supporting files are needed, they go alongside SKILL.md.


Frontmatter Reference

FieldTypeDefaultWhen to Use
namestringdir nameAlways. Lowercase, hyphens, max 64 chars
descriptionstringrequiredAction-oriented: what it does + when to trigger
modelstringinheritComplex reasoning: opus. Cost savings: haiku
disable-model-invocationboolfalseAlways true for command skills (they have side effects)
argument-hintstringnoneIf command takes args: [service-name], [model-id]
allowed-toolsstringallRestrict: Read, Bash(npm *), mcp__github__*
contextstringinlinefork for isolated subagent (read-only exploration)
agentstringgeneralWith context: fork: Explore, Plan
user-invocablebooltruefalse hides from menu (background knowledge only)

$ARGUMENTS

$ARGUMENTS is replaced with the user's full argument string. Positional access via $0, $1, or $ARGUMENTS[N] (0-based).

/deploy twitter staging
# $ARGUMENTS = "twitter staging", $0 = "twitter", $1 = "staging"

Don't over-specify argument parsing. Trust Claude to understand natural language - describe what you expect and let Claude validate, rather than writing brittle format parsers.

Path Variables

Never hardcode absolute paths. Use:

  • ${CLAUDE_PROJECT_DIR} - project root
  • ${CLAUDE_SKILL_DIR} - skill's own directory (for bundled scripts)
  • Relative paths from repo root

Design Patterns

See references/design-patterns.md for detailed patterns with full examples. Quick reference:

ScenarioPattern
One action, no approval neededSimple Task
Multiple steps, some irreversiblePhased Workflow with Approval Gate
Need info from multiple sourcesParallel Research + Sequential Implementation
Modifying another projectCross-Repo with Adaptive Discovery
Command exceeds 200 linesProgressive Disclosure with supporting files

Anti-Patterns

Watch for these when reviewing command skills:

  • Hardcoded paths: /Users/someone/... → use ${CLAUDE_PROJECT_DIR} or relative
  • Missing safety: no disable-model-invocation on commands with side effects
  • Over-specification: complex argument parsers instead of natural language
  • No checkpoints: making changes without showing what will happen first
  • Blind edits: modifying files without reading them
  • Silent failures: no error handling or status reporting
  • Context ignorance: not reading CLAUDE.md, existing conventions, or config files
  • Monolithic prompt: 500+ line SKILL.md instead of using supporting files

Audit Checklist

Every command skill must pass before finalizing:

  1. disable-model-invocation: true if any side effects exist
  2. argument-hint present if command takes arguments
  3. No hardcoded absolute paths
  4. Adaptive discovery (grep/glob) for cross-repo file references
  5. Guard clause for missing $ARGUMENTS
  6. Approval gate before destructive/irreversible operations
  7. Clear outcome reporting (succeeded, failed, next steps)
  8. SKILL.md under 200 lines (supporting files for overflow)
  9. Explicit error handling ("if X fails, stop and show error")
  10. ${CLAUDE_PROJECT_DIR} or relative paths, never absolute
  11. Reads files before editing (no blind modifications)
  12. Reads target project's CLAUDE.md for cross-repo operations

Files

3 total
Select a file
Select a file to preview.

Comments

Loading comments…