360 Secure SkillHub
360 安全技能中心

Doro Command Creator

核心功能:引导用户创建符合规范的Claude斜杠命令,支持项目/全局位置选择,提供工作流自动化、迭代修复等4种模板模式,严格遵循命令结构与质量规范。典型场景:需自动化重复工作流、固化一致流程时使用。输入为用户需求、位置偏好等,输出为规范的Markdown命令文件,保存至指定目录并告知使用方式。

a2mus
a2mus
热度 71.65
最近更新 2026-05-11 17:27:16
分类:效率依赖:读写文件 / 代码执行 / 内部调用大模型应用场景:自动化脚本 / 工作流 / 模板

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add doro-command-creator
Metadata
name
doro-command-creator
model
fast
version
1.0.0
description
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"

Command Creator

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