Command Creator

WHAT: Create Claude Code slash commands - reusable markdown workflows invoked with /command-name. WHEN: User wants to create, make, or add a slash command. User wants to automate a repetitive workflow or document a consistent process for reuse. KEYWORDS: "create a command", "make a slash command", "add a command", "new command", "/command", "automate this workflow", "make this repeatable"

Security Scan

The skill's purpose (authoring slash-command markdown files) largely matches its content, but there are internal contradictions and unannounced side-effecting operations (git commits, make/CI runs, PR submission) that users should review before installing or allowing autonomous execution.

Purpose & Capability

The declared purpose is to create Claude Code slash commands and the SKILL.md, README, and reference docs are all focused on that. However, the instructions reference running tools like git, make, gt, TodoWrite/Task tools and performing repo-level operations (git add/git commit/gt submit) even though the skill's manifest declares no required binaries or environment variables. Not listing expected tool dependencies (git, make, gt, etc.) is an incoherence worth noting, though not necessarily malicious.

Instruction Scope

The instructions explicitly tell the agent to read project files, create directories, and write files under .claude/commands or ~/.claude/commands (which is consistent with creating commands), but they also include patterns and examples that run potentially destructive or high-impact commands: `git add .`, `git commit -m ...`, `gt restack`/`gt submit --stack --publish --no-edit`, and `make all-ci` with automated iterative fixes. The docs also contain contradictory guidance about using the Bash tool for make commands (both 'ALWAYS use Bash tool' and 'DO NOT use Bash tool for make commands' appear), which is a logical inconsistency. Because the skill encourages running repo-modifying commands and automated CI-fix cycles, users should be cautious about allowing autonomous execution or giving the agent repository write privileges.

Install Mechanism

This is an instruction-only skill with no install spec and no code files, so nothing is downloaded or written by an installer. That lowers the risk from supply-chain/install-time behavior.

Credentials

The skill declares no required environment variables or credentials. That is appropriate for its stated purpose. Note: many instructions assume availability of external tools (git, make, gt, TodoWrite/Task tools) and access to the user's filesystem, which is consistent with creating command files but should be explicitly documented in requires.* if the skill were to run in environments that enforce declared dependencies.

Persistence & Privilege

The skill does not request 'always: true' or any elevated persistent privileges. It's user-invocable and allows model invocation by default, which is normal. The skill writes files to .claude/commands or ~/.claude/commands as part of its function; that file-writing behavior is expected for this purpose but is a material side effect users should understand before enabling autonomous runs.

What to consider before installing

This skill is mostly coherent with its goal of authoring slash-command markdown files, but it contains a few red flags you should consider before installing or allowing it to run autonomously: - It references running system tools (git, make, gt) and performing repo-modifying actions (git add, git commit, submitting PRs). Those are legitimate for some command examples, but they have real side effects — only allow the skill in repos where unintended commits/PRs are acceptable. - The manifest claims no required binaries, yet the instructions assume git, make, gt, and platform-specific tools (TodoWrite/Task). Expect to provide or verify those tools are available, or the skill may fail in surprising ways. - There are internal contradictions in the instructions (conflicting guidance about using the Bash tool for make commands). That suggests the content wasn't fully reviewed and could lead the agent to take inconsistent actions. - Because the skill can write files to your home directory or project dirs, review generated command files before using them. If you plan to allow autonomous invocation, restrict it (do not enable wide autonomy) until you confirm the generated commands are safe and the agent's execution scope is limited. Recommendations: - Test the skill in a disposable or non-critical repository first. - Disable autonomous invocation or require user confirmation for any recipe that runs git/add/commit or submits PRs. - If you need stricter controls, ask the skill author to declare required binaries (git, make, gt) and to remove contradictory instructions. - Review and audit any generated command files and any commits/PRs the agent proposes before merging or publishing.

Slash commands are markdown files in .claude/commands/ (project) or ~/.claude/commands/ (global) that expand into prompts when invoked.

Command Structure

---
description: Brief description for /help (required)
argument-hint: <required> or [optional] (if takes arguments)
---

# Command Title

[Instructions for agent to execute autonomously]

---

Creation Workflow

Step 1: Determine Location

1. Check if in git repo: git rev-parse --is-inside-work-tree
2. Default: Git repo → .claude/commands/, No git → ~/.claude/commands/
3. Override if user explicitly says "global" or "project"

Report chosen location before proceeding.

Step 2: Identify Pattern

Load references/patterns.md and present options:

Pattern	Structure	Use When
Workflow Automation	Analyze → Act → Report	Multi-step with clear sequence
Iterative Fixing	Run → Parse → Fix → Repeat	Fix issues until passing
Agent Delegation	Context → Delegate → Iterate	Complex tasks, user review
Simple Execution	Parse → Execute → Return	Wrapper for existing tools

Ask: "Which pattern is closest to what you want?"

Step 3: Gather Information

A. Name and Purpose

• "What should the command be called?" (kebab-case: my-command)
• "What does it do?" (for description field)

B. Arguments

• "Does it take arguments? Required or optional?"
• Required: <placeholder>, Optional: [placeholder]

C. Workflow Steps

• "What specific steps should it follow?"
• "What tools or commands should it use?"

D. Constraints

• "Any specific tools to use or avoid?"
• "Any files to read for context?"

Step 4: Generate Command

Load references/best-practices.md for:

• Template structure
• Writing style (imperative form)
• Quality checklist

Key principles:

• Use imperative form: "Run X", not "You should run X"
• Be explicit: "Run make lint", not "Check for errors"
• Include expected outcomes
• Define error handling
• State success criteria

Step 5: Create File

mkdir -p [directory-path]

Write the command file. Report:

• File location
• What the command does
• How to use: /command-name [args]

Step 6: Test (Optional)

Suggest: "Test with /command-name [args]"

Iterate based on feedback.

---

Writing Guidelines

Imperative form (verb-first):

• ✅ "Run git status"
• ❌ "You should run git status"

Specific, not vague:

• ✅ "Run make lint to check for errors"
• ❌ "Check for errors"

Include outcomes:

• ✅ "Run git status - should show modified files"
• ❌ "Run git status"

Realistic examples:

• ✅ git commit -m "Add OAuth2 authentication"
• ❌ git commit -m "foo bar"

---

Command Patterns Quick Reference

Workflow Automation

1. Check for .PLAN.md
2. Analyze git status/diff
3. Perform actions
4. Report results

Iterative Fixing

1. Run make all-ci (max 10 iterations)
2. Parse errors by category
3. Apply targeted fixes
4. Repeat until success or stuck

Agent Delegation

1. Present context
2. Invoke subagent with Task tool
3. Iterate with user feedback
4. Save output after approval

See references/examples.md for full command examples.

---

Quality Checklist

Before finalizing:

• Name is kebab-case (my-command, not my_command)
• Description is action-oriented
• Steps are numbered and specific
• Tool usage explicitly specified
• Error handling defined
• Success criteria stated
• Uses imperative form

---

NEVER

• Use underscores in command names (use hyphens)
• Write vague instructions ("fix errors")
• Skip error handling
• Use second person ("You should...")
• Create commands without testing
• Leave success criteria undefined