Token导航 LogoToken导航TokenDH.com
研究检索执行命令github未标认证来源可访问许可证需确认审计未展示

customaize-agent:create-command自定义 Agent 创建命令

Agent Skill

customaize-agent:create-command 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

10,771

周安装

440

GitHub Stars

891

下载量

3,485
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:customaize-agent:create-command(自定义 Agent 创建命令)
来源仓库:https://github.com/neolabhq/context-engineering-kit
仓库路径:skills/customaize-agent:create-command
安装命令:
npx skills add https://github.com/neolabhq/context-engineering-kit --skill customaize-agent:create-command
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/neolabhq/context-engineering-kit --skill customaize-agent:create-command

简介

customaize-agent:create-command 辅助创建 shell 命令,支持项目级与用户级部署。

  • 适用于构建交互式工作流、文档生成或复杂任务分阶段处理场景。
  • 自动识别项目工具链并建议合理命令结构与存放位置。
  • 安装前请确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写操作。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

Command Creator Assistant

This meta-command helps create other commands by:

  1. Understanding the command's purpose
  2. Determining its category and pattern
  3. Choosing command location (project vs user)
  4. Generating the command file
  5. Creating supporting resources
  6. Updating documentation

<command_categories>

  1. Planning Commands (Specialized)

- Feature ideation, proposals, PRDs - Complex workflows with distinct stages - Interactive, conversational style - Create documentation artifacts - Examples: @/.claude/commands/01_brainstorm-feature.md @/.claude/commands/02_feature-proposal.md

  1. Implementation Commands (Generic with Modes)

- Technical execution tasks - Mode-based variations (ui, core, mcp, etc.) - Follow established patterns - Update task states - Example: @/.claude/commands/implement.md

  1. Analysis Commands (Specialized)

- Review, audit, analyze - Generate reports or insights - Read-heavy operations - Provide recommendations - Example: @/.claude/commands/review.md

  1. Workflow Commands (Specialized)

- Orchestrate multiple steps - Coordinate between areas - Manage dependencies - Track progress - Example: @/.claude/commands/04_feature-planning.md

  1. Utility Commands (Generic or Specialized)

- Tools, helpers, maintenance - Simple operations - May or may not need modes </command_categories>

<command_frontmatter>

CRITICAL: Every Command Must Start with Frontmatter

All command files MUST begin with YAML frontmatter enclosed in --- delimiters:

---
description: Brief description of what the command does
argument-hint: Description of expected arguments (optional)
---

Frontmatter Fields

  1. description (REQUIRED):

- One-line summary of the command's purpose - Clear, concise, action-oriented - Example: "Guided feature development with codebase understanding and architecture focus"

  1. argument-hint (OPTIONAL):

- Describes what arguments the command accepts - Examples: - "Optional feature description" - "File path to analyze" - "Component name and location" - "None required - interactive mode"

Example Frontmatter by Command Type

# Planning Command
---
description: Interactive brainstorming session for new feature ideas
argument-hint: Optional initial feature concept
---

# Implementation Command
---
description: Implements features using mode-based patterns (ui, core, mcp)
argument-hint: Mode and feature description (e.g., 'ui: add dark mode toggle')
---

# Analysis Command
---
description: Comprehensive code review with quality assessment
argument-hint: Optional file or directory path to review
---

# Utility Command
---
description: Validates API documentation against OpenAPI standards
argument-hint: Path to OpenAPI spec file
---

Placement

  • Frontmatter MUST be the very first content in the file
  • No blank lines before the opening ---
  • One blank line after the closing --- before content begins </command_frontmatter>

<command_features>

Slash Command Features

Namespacing

Use subdirectories to group related commands. Subdirectories appear in the command description but don't affect the command name.

Example:

  • .claude/commands/frontend/component.md creates /component with description "(project:frontend)"
  • ~/.claude/commands/component.md creates /component with description "(user)"

Priority: If a project command and user command share the same name, the project command takes precedence.

Arguments

All Arguments with $ARGUMENTS

Captures all arguments passed to the command:

# Command definition
echo 'Fix issue #$ARGUMENTS following our coding standards' > .claude/commands/fix-issue.md

# Usage
> /fix-issue 123 high-priority
# $ARGUMENTS becomes: "123 high-priority"

Individual Arguments with $1, $2, etc.

Access specific arguments individually using positional parameters:

# Command definition
echo 'Review PR #$1 with priority $2 and assign to $3' > .claude/commands/review-pr.md

# Usage
> /review-pr 456 high alice
# $1 becomes "456", $2 becomes "high", $3 becomes "alice"

Bash Command Execution

Execute bash commands before the slash command runs using the ! prefix. The output is included in the command context.

Note: You must include allowed-tools with the Bash tool.

---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
description: Create a git commit
---

## Context

- Current git status: !`git status`
- Current git diff: !`git diff HEAD`
- Current branch: !`git branch --show-current`
- Recent commits: !`git log --oneline -10`

File References

Include file contents using the @ prefix to reference files:

Review the implementation in @src/utils/helpers.js
Compare @src/old-version.js with @src/new-version.js

Thinking Mode

Slash commands can trigger extended thinking by including extended thinking keywords.

Frontmatter Options

FrontmatterPurposeDefault
allowed-toolsList of tools the command can useInherits from conversation
argument-hintExpected arguments for auto-completionNone
descriptionBrief description of the commandFirst line from prompt
modelSpecific model stringInherits from conversation
disable-model-invocationPrevent Skill tool from calling this commandfalse

Example with all frontmatter options:

---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
argument-hint: [message]
description: Create a git commit
model: claude-3-5-haiku-20241022
---

Create a git commit with message: $ARGUMENTS

</command_features>

<pattern_research>

Before Creating: Study Similar Commands

  1. List existing commands in target directory: # For project commands ls -la /.claude/commands/ # For user commands ls -la ~/.claude/commands/
  2. Read similar commands for patterns:

- Check the frontmatter (description and argument-hint) - How do they structure sections? - What MCP tools do they use? - How do they handle arguments? - What documentation do they reference?

  1. Common patterns to look for: # MCP tool usage for tasks Use tool: mcp__scopecraft-cmd__task_create Use tool: mcp__scopecraft-cmd__task_update Use tool: mcp__scopecraft-cmd__task_list # NOT CLI commands ❌ Run: scopecraft task list ✅ Use tool: mcp__scopecraft-cmd__task_list
  2. Standard references to include:

- @/docs/organizational-structure-guide.md - @/docs/command-resources/{relevant-templates} - @/docs/claude-commands-guide.md </pattern_research>

<interview_process>

Phase 1: Understanding Purpose

"Let's create a new command. First, let me check what similar commands exist..."

*Use Glob to find existing commands in the target category*

"Based on existing patterns, please describe:"

  1. What problem does this command solve?
  2. Who will use it and when?
  3. What's the expected output?
  4. Is it interactive or batch?

Phase 2: Category Classification

Based on responses and existing examples:

  • Is this like existing planning commands? (Check: brainstorm-feature, feature-proposal)
  • Is this like implementation commands? (Check: implement.md)
  • Does it need mode variations?
  • Should it follow analysis patterns? (Check: review.md)

Phase 3: Pattern Selection

Study similar commands first:

# Read a similar command
@{similar-command-path}

# Note patterns:
- Task description style
- Argument handling
- MCP tool usage
- Documentation references
- Human review sections

Phase 4: Command Location

🎯 Critical Decision: Where should this command live?

Project Command (/.claude/commands/)

  • Specific to this project's workflow
  • Uses project conventions
  • References project documentation
  • Integrates with project MCP tools

User Command (~/.claude/commands/)

  • General-purpose utility
  • Reusable across projects
  • Personal productivity tool
  • Not project-specific

Ask: "Should this be:

  1. A project command (specific to this codebase)
  2. A user command (available in all projects)?"

Phase 5: Resource Planning

Check existing resources:

# Check templates
ls -la /docs/command-resources/planning-templates/
ls -la /docs/command-resources/implement-modes/

# Check which guides exist
ls -la /docs/

</interview_process>

<generation_patterns>

Critical: Copy Patterns from Similar Commands

Before generating, read similar commands and note:

  1. Frontmatter (MUST BE FIRST): --- description: Clear one-line description of command purpose argument-hint: What arguments does it accept ---

- No blank lines before opening --- - One blank line after closing --- - description is REQUIRED - argument-hint is OPTIONAL

  1. MCP Tool Usage: # From existing commands Use mcp__scopecraft-cmd__task_create Use mcp__scopecraft-cmd__feature_get Use mcp__scopecraft-cmd__phase_list
  2. Standard References: <context> Key Reference: @/docs/organizational-structure-guide.md Template: @/docs/command-resources/planning-templates/{template}.md Guide: @/docs/claude-commands-guide.md </context>
  3. Task Update Patterns: <task_updates> After implementation: 1. Update task status to appropriate state 2. Add implementation log entries 3. Mark checklist items as complete 4. Document any decisions made </task_updates>
  4. Human Review Sections: <human_review_needed> Flag decisions needing verification: - [] Assumptions about workflows - [] Technical approach choices - [] Pattern-based suggestions </human_review_needed>

</generation_patterns>

<implementation_steps>

  1. Create Command File

- Determine location based on project/user choice - Generate content following established patterns - Include all required sections

  1. Create Supporting Files (if project command)

- Templates in /docs/command-resources/ - Mode guides if generic command - Example documentation

  1. Update Documentation (if project command)

- Add to claude-commands-guide.md - Update feature-development-workflow.md if workflow command - Add to README if user-facing

  1. Test the Command

- Create example usage scenarios - Verify argument handling - Check MCP tool integration </implementation_steps>

<creation_checklist> Before finalizing:

  • Includes YAML frontmatter with description (required) and argument-hint (optional)
  • Frontmatter is the very first content (no blank lines before opening ---)
  • Studied similar commands in the category
  • Command follows naming conventions (use numeric prefix for ordered workflows)
  • Includes proper task/context structure
  • References @organizational-structure-guide.md
  • Uses MCP tools (not CLI) - check existing patterns
  • Includes human review sections
  • Has clear examples like other commands
  • Updates task states appropriately
  • Creates proper documentation
  • Follows established patterns from similar commands
  • Correct command prefix (project: or user:) </creation_checklist>

<example_session> User: "I need a command to help validate our API documentation"

🔍 Research: Let me check existing analysis commands...

*Use Read tool to examine: /.claude/commands/review.md*

I notice the review command:

  • Uses MCP tools for task operations
  • Includes human review sections
  • References organizational structure
  • Has clear output formatting

🤔 Question: Can you tell me more about this API documentation validation?

  • What format is the documentation in?
  • What aspects need validation?
  • Should it create tasks for issues found?

User: "It's OpenAPI specs, need to check for completeness and consistency"

💡 Category: This is an Analysis command similar to 'review'.

🔍 Pattern Check: Looking at review.md, I see it:

<task>
You are a code reviewer conducting a comprehensive review...
</task>

<mcp_usage>
Always use MCP tools:
- mcp__scopecraft-cmd__task_list
- mcp__scopecraft-cmd__task_update
</mcp_usage>

🎯 Location Question: Should this be:

  1. A project command (specific to this API project)
  2. A user command (useful for all your API projects)

User: "Project command - it needs to reference our specific API standards"

✅ Creating project command: /.claude/commands/validate-api.md

Generated command (following review.md patterns):

---
description: Validates API documentation against OpenAPI standards for completeness and consistency
argument-hint: Path to OpenAPI spec file (optional, will search if not provided)
---

<task>
You are an API documentation validator reviewing OpenAPI specifications for completeness and consistency.
</task>

<context>
References:
- API Standards: @/docs/api-standards.md
- Organizational Structure: @/docs/organizational-structure-guide.md
Similar to: @/.claude/commands/review.md
</context>

<validation_process>
1. Load OpenAPI spec files
2. Check required endpoints documented
3. Validate response schemas
4. Verify authentication documented
5. Check for missing examples
</validation_process>

<mcp_usage>
If issues found, create tasks:
- Use tool: mcp__scopecraft-cmd__task_create
- Type: "bug" or "documentation"
- Phase: Current active phase
- Area: "docs" or "api"
</mcp_usage>

<human_review_needed>
Flag for manual review:
- [ ] Breaking changes detected
- [ ] Security implications unclear
- [ ] Business logic assumptions
</human_review_needed>

</example_session>

<final_output> After gathering all information:

  1. Command Created:

- Location: {chosen location} - Name: {command-name} - Category: {category} - Pattern: {specialized/generic}

  1. Resources Created:

- Supporting templates: {list} - Documentation updates: {list}

  1. Usage Instructions:

- Command: /{prefix}:{name} - Example: {example usage}

  1. Next Steps:

- Test the command - Refine based on usage - Add to command documentation </final_output>

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

36.48%
按下载量换算1,271

Claude

31.99%
按下载量换算1,115

Cursor

18.86%
按下载量换算657

Gemini CLI

9.6%
按下载量换算335

安全审计

暂无安全审计结果可展示。

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/neolabhq/context-engineering-kit --skill customaize-agent:create-command 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills