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-casesubmit-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.md1. 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 repositorys 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提交整个 upstackdownstack、--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 stateexamples.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_typesubagent - 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 applicableexamples.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_typeExplore定位相关文件、识别关键组件再以subagent_typesubagent生成实现计划并交用户评审最后在主会话中加载.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 提供了一张直接可用的选择表如果命令需要……使用该模式基于分析创建提交/PR工作流自动化Workflow Automation迭代修复问题直到通过迭代修复Iterative Fixing制定计划或委派给专家Agent 委派Agent Delegation运行工具并展示结果简单执行Simple Execution协调多个 Agent多 Agent 编排Multi-Agent Orchestration检查多个上下文文件上下文文件优先级Context File Priority按复杂度选择方案条件性工具选择Conditional Tool Selection运行 make 目标Makefile 集成Makefile Integration由简入繁按需扩展渐进式披露Progressive Disclosure模式组合现实命令往往是复合体命令经常同时组合多种模式。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 都要求指令包含四类通用元素编号的清晰步骤序列、每步的预期结果、错误处理方法、成功判据。在此基础上每种模式还有专属要素模式专属要素工作流自动化分析前的文件检查、条件分支、输出格式规范迭代修复最大迭代次数、卡死检测逻辑、进度跟踪要求、按类别修复指令Agent 委派精确的 Task 工具调用语法、传给 Agent 的上下文、用户评审检查点、保存到磁盘指令简单执行参数解析逻辑、命令调用语法、输出格式化要求结合 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.symlinksfalse开发者模式外的默认值会把.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考