企业官网建设流程全解析

Meshery 仓库 Agent 斜杠命令设计模式实战：四大核心模式与组合编排指南

【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/meshery

导读

斜杠命令（Slash Command）是让 AI Agent 在对话中一键执行可复用工作流的关键机制——把"提交 PR 栈""修复 CI 失败""委托子代理制定实施计划"这类高频重复操作固化为/command-name即可调用的确定性流程。本指南以 patterns.md 为骨架，系统讲解 Meshery 仓库.agents/工具链所采用的四种核心命令模式、五种高级模式及其选择与组合方法，并结合仓库内真实的命令实现与最佳实践，让你能够设计出 Agent 可自主执行、结果可预期、失败可恢复的高质量斜杠命令。

斜杠命令是什么：存储位置与文件结构

斜杠命令本质上是一个 Markdown 文件，当用户在 Claude Code 对话中输入/command-name时，该文件内容会被展开为提示词注入会话。在 Meshery 仓库的 Agent 工具链设计中，命令存放在两个层级：

• 项目级：.claude/commands/[command-name].md，仅对当前项目生效，随仓库版本化、团队共享；
• 全局/用户级：~/.claude/commands/[command-name].md，跨项目可用，适合个人生产力工具。

每个命令文件由 frontmatter 与指令正文组成：

--- description: Brief description shown in /help (required) argument-hint: <placeholder> (optional, if command takes arguments) --- # Command Title [Detailed instructions for the agent to execute autonomously]

其中description必填，会显示在/help输出中；argument-hint可选，用尖括号<required>标注必填参数、方括号[optional]标注可选参数。命令名必须使用 kebab-case（submit-stack而非submit_stack），文件名与命令名一致。

Meshery 仓库将这类技能统一收纳在 .agents/README.md 描述的.agents/skills/目录下，.claude/skills只是指向../.agents/skills的相对符号链接，仅作为 Claude Code 的发现路径而非运行依赖——这正是 AGENTS.md 中"技能内容一律以.agents/skills/...规范路径寻址自身文件"的原因。

核心模式一：工作流自动化模式（Workflow Automation）

结构：分析（Analyze）→ 行动（Act）→ 汇报（Report）。

适用场景：具有明确先后顺序的多步工作流；需要先分析再行动的命令；产出特定结果（提交、PR、报告）的流程。

关键特征：

• 显式的文件检查顺序（如先检查.PLAN.md）；
• 基于文件存在性的条件逻辑分支；
• 清晰的最终成功输出格式；
• 上下文感知的决策。

模式骨架（来自 patterns.md）：

1. Check for .PLAN.md in repository root - If exists: use plan context for commit message - If not: analyze git changes and draft message 2. Review git status and diff - Identify staged and unstaged changes - Determine scope of changes 3. Create commit with descriptive message - Follow repository's commit message style - Include co-author attribution 4. Submit PRs with Graphite - Use gt stack submit - Report PR URLs to user

仓库内 examples.md 提供了该模式的完整实现参考/submit-stack：先检查.PLAN.md（存在则用它生成提交信息，否则回退到git status/git diff HEAD分析），再git add . && git commit -m "..."创建提交，随后执行gt restack与gt submit --stack --publish --no-edit --restack提交整个 Graphite 栈，最后向用户汇报创建的 PR 数量与 URL。其中--stack提交整个 upstack+downstack、--publish发布草稿 PR、--no-edit直接以提交信息作为 PR 标题免交互，这些标志的语义都必须写进命令指令中，确保 Agent 不需要猜测。

核心模式二：迭代修复模式（Iterative Fixing）

结构：运行（Run）→ 解析（Parse）→ 修复（Fix）→ 重复（Repeat）。

适用场景：以迭代方式修复问题的命令（lint、测试、CI）；需要多次尝试才能成功的流程；具有明确通过/失败判据的任务。

关键特征：

• 迭代控制（最大尝试次数、卡死检测）；
• 用 TodoWrite 跟踪进度；
• 明确的停止条件；
• 按类型对失败进行分类；
• 增量应用修复。

模式骨架：

1. Run make all-ci (max 10 iterations) 2. If check fails: - Parse error output by category (pyright, ruff, tests) - Create todos for each error category - Apply fixes for each category sequentially - Mark todo complete after fixing each category 3. After each fix iteration: - Run make all-ci again - Check if new errors appeared - If stuck (same errors 2+ times): stop and report 4. Stop when: - All checks pass (exit code 0) - Max iterations reached - Detected stuck state

examples.md 中的/ensure-ci是该模式的完整实现，它运行make all-ci（依次执行 lint → format → prettier-check → pyright → test），按失败类型施治：Ruff lint 失败用make fix、格式失败用make format、Prettier 失败用make prettier、类型错误用 Read/Edit 工具修复、测试失败则先读测试文件再改源码。卡死检测规则是"同一错误连续出现 3 次即停止"，最大迭代上限 10 次，并向用户输出结构化的 STUCK 或 SUCCESS 状态报告。

核心模式三：Agent 委派模式（Agent Delegation）

结构：收集上下文（Context）→ 委派（Delegate）→ 迭代（Iterate）。

适用场景：需要专门化 Agent 的复杂任务；含人工评审环节的多阶段工作流；能从 Agent 专长分工中获益的任务。

关键特征：

• 清晰的 Agent 调用指令；
• 分阶段工作流（规划 → 评审 → 执行）；
• 显式的保存到磁盘触发点；
• 用户评审检查点；
• 委派前先收集上下文。

模式骨架：

1. Present planning context - Explain what the agent will do - Set expectations for iterative process - Mention that user can refine the output 2. Invoke subagent agent - Use Task tool with subagent_type="subagent" - Pass task description and context - Do NOT attempt to write plan yourself 3. Agent works autonomously - Creates initial plan - Iterates with user feedback - Refines based on questions/concerns 4. After user approves plan - Save to .PLAN.md - Confirm location with user - Explain next steps (execution)

该模式在 examples.md 中的/create-implementation-plan命令里得到充分体现：命令强调"规划阶段禁止写任何代码、禁止使用 Edit/Write 等修改工具，仅将计划输出到终端供迭代评审，只有用户显式批准（如 "looks good"、"approved"）后才持久化到磁盘"。

核心模式四：简单执行模式（Simple Execution）

结构：解析参数（Parse Arguments）→ 执行（Execute）→ 返回输出（Return Output）。

适用场景：带参数的单步命令；已有工具的包装命令；只需运行并汇报的命令。

关键特征：

• 参数处理（必填 vs 可选）；
• 直接调用工具；
• 最少逻辑；
• 输出格式化。

模式骨架：

1. Parse [base-branch] argument - If provided: use specified branch - If not provided: use main/master 2. Run codex-review script - Pass base-branch to script - Capture output 3. Display results - Show review findings - Report issues found - Suggest fixes if applicable

examples.md 的/codex-review是该模式的最小示例：方括号[base-branch]表示可选参数，未提供时用git rev-parse --verify main探测 main 分支、不存在则回退 master，然后直接调用scripts/codex-review.py [base-branch]并把脚本输出原样透传给用户——命令本身只是便利包装，核心逻辑都在外部脚本中。

高级模式：组合与演进

当单个模式的骨架不够用时，patterns.md 还给出五种可叠加的高级模式：

• 多 Agent 编排（Multi-Agent Orchestration）：复杂工作流按顺序调用多个专门 Agent。先用Task工具以subagent_type="Explore"定位相关文件、识别关键组件，再以subagent_type="subagent"生成实现计划并交用户评审，最后在主会话中加载.PLAN.md、用 TodoWrite 跟踪阶段并逐步执行。
• 上下文文件优先级检查（Context File Priority Checks）：命令根据可用上下文以不同模式运行。检查顺序为.PLAN.md（最高优先级，实现计划）→.github/CONTRIBUTING.md（贡献指南）→AGENTS.md（编码标准）→README.md（项目概览），取第一个命中的文件驱动后续工作流。
• 条件性工具选择（Conditional Tool Selection）：按改动规模决定路径。改动跨 3+ 个文件或引入新抽象时，委派 subagent 并制定详细计划；否则直接执行、跳过规划开销。
• Makefile 集成模式（Makefile Integration）：命令需要运行 make 目标时，明确要求"pytest/pyright/ruff/prettier/make/gt 命令一律通过 Bash 工具执行"，并检查退出码、解析错误、必要时修复。
• 渐进式披露（Progressive Disclosure）：命令由浅入深。先做最小检查、判断是否需要深入，发现问题才逐级扩展范围、按类别添加 todo 并增量处理，避免前期过度分析。

模式选择指南：需求到模式的映射

patterns.md 提供了一张直接可用的选择表：

模式组合：现实命令往往是复合体

命令经常同时组合多种模式。patterns.md 给出了两个典型范例：

• /submit-stack组合了：上下文文件优先级（先检查.PLAN.md）+ 工作流自动化（分析 → 提交 → 推送）+ 条件性工具选择（有计划则用计划）；
• /ensure-ci组合了：迭代修复（运行 → 修复 → 重复）+ Makefile 集成（使用 makefile-runner）+ 渐进式披露（随问题发现逐步扩展 todo）。

examples.md 末尾的模式对比表进一步揭示设计权衡：submit-stack为单趟执行、报错即询问用户；ensure-ci最多迭代 10 次、强制 TodoWrite 跟踪；create-implementation-plan无代码修改、以用户批准为成功判据；codex-review直接透传脚本输出。选型时应依据"是否检查上下文文件、是否需要迭代、是否需要进度跟踪、成功判据是什么"四个维度综合决策。

编写模式化指令的规范要素

无论实现哪种模式，patterns.md 都要求指令包含四类通用元素：编号的清晰步骤序列、每步的预期结果、错误处理方法、成功判据。在此基础上，每种模式还有专属要素：

结合 best-practices.md 的质量清单，命令还应该：全程使用祈使/不定式动词开头（"Run git status" 而非 "You should run git status"）、明确指定工具（"Use the Bash tool to run pytest"）、写出预期输出（"This should output..."）、给出真实示例（避免 foo/bar 占位符）、用 if/else 明确条件逻辑、以 "NEVER"/"DO NOT" 标出反模式（如禁止批量标记 todo 完成、禁止在规划阶段用 Edit 工具）、定义精确的停止条件（make all-ci退出码为 0 即成功，同一错误 3 次即卡死）。

在 Meshery 仓库中落地：Agent 工具链的工程化约束

斜杠命令与技能并非孤立文件，它们被收纳在 Meshery 仓库的.agents/目录中，并受 AGENTS.md 的明确规则约束，这对任何要在本仓库内创建命令的开发者都至关重要：

• .agents/skills/是技能的单一事实来源，每个技能一个目录、含一个SKILL.md，新增技能只允许加在这里；
• .claude/skills是指向../.agents/skills的相对符号链接且只能是符号链接，绝不可替换为真实目录或副本，否则会重新引入技能漂移；
• 技能内容寻址自身文件必须使用.agents/skills/...规范路径，不能经.claude/（符号链接缺席时解析即失败）；
• Windows 上core.symlinks=false（开发者模式外的默认值）会把.claude/skills物化为一个普通文本文件，导致 Claude Code 发现不到项目技能，需启用开发者模式或设置git config core.symlinks true后重新检出。

这套约束（详见 .agents/README.md）保证了斜杠命令/技能在 Codex、OpenCode、Claude Code 等多工具间的一致发现与无漂移维护。理解这些边界后，结合本文的四大核心模式、五种高级模式与选择组合方法，你便能在 Meshery 仓库中把任何重复性工作流固化为可靠、可维护、可共享的斜杠命令。

【免费下载链接】mesheryMeshery, the cloud native manager项目地址: https://gitcode.com/GitHub_Trending/me/meshery