mcpField
A
aep-design

aep-design

github.com/memorysaver开发1858 次安装6 周前更新
代码仓库

关于 aep-design

aep-design 是一项交互式技能，用于将功能想法整理为经过审查的 OpenSpec 变更，并提交到集成分支。它涵盖需求探索、方案编写和设计审查，为后续实现准备文档。

主要功能

  1. 01探索需求与代码库模式
  2. 02创建 OpenSpec 提案和规格
  3. 03审查安全、性能与边界情况
  4. 04将设计文档提交到集成分支

适用场景

  1. 01明确新功能的范围
  2. 02记录架构与实现任务
  3. 03在编码前审查功能设计

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/memorysaver/agentic-engineering-patterns --skill aep-design

安装后在 Claude Code 中输入/aep-design确认已加载。

附带文件references/modes.mdreferences/workflow-modes.md

详细介绍

设计

在集成分支（$BASE — 按 /aep-git-ref「解析 $BASE」中的说明解析）上进行交互式功能设计。与用户对话，探索问题、提出解决方案、评审设计并提交产物。

适用场景：

/aep-onboard → /aep-scaffold → [ /aep-design → /aep-launch → /aep-build → /aep-wrap ]
                          ▲ you are here

会话： 主会话，与用户交互 输入： 功能构想或用户请求（可参考产品上下文） 输出： 已提交到集成分支的 OpenSpec 变更（提案、设计、规范、任务）

操作模式

启动时自动检测：

ls product-context.yaml 2>/dev/null
  • 独立模式（没有 product-context.yaml）——功能生命周期独立运行；继续执行前置条件。
  • 产品周期模式（存在 product-context.yaml）——该功能是 /aep-envision → /aep-map → /aep-dispatch → /aep-design 中的一个故事。阅读 references/modes.md，了解已分派故事的上下文（验收标准、接口义务、现有变更）如何在各阶段开始前加载。

前置条件

执行两项单行检查——/aep-onboard 安装缺失的工具，/aep-scaffold 安装缺失的 OpenSpec 技能：

which git openspec >/dev/null 2>&1 && { which gh >/dev/null 2>&1 || which glab >/dev/null 2>&1; } || echo "MISSING cli tool → run /aep-onboard"
ls .claude/skills/openspec-{explore,propose,apply-change,archive-change}/SKILL.md >/dev/null 2>&1 || echo "MISSING openspec skill → run /aep-scaffold"

工作流模式选择

设计前选择一种工作流模式——完整或精简。该模式决定下方的阶段 3，并会延续到 /aep-launch 和 /aep-build。阅读 references/workflow-modes.md，了解两种模式、选择标准，以及如何记录选择以确保 launch 和 build 遵循该模式。

阶段 1：OpenSpec 探索

/opsx:explore

与用户明确需求和范围，调查代码库中的相关模式，识别风险和未知事项；如功能有此需要，则创建 docs/ 架构说明。

后置条件： 需求、范围和风险均已记录在变更目录（openspec/changes/<change-name>/）中。

阶段 2：OpenSpec 提案

/opsx:propose

生成完整的 OpenSpec 变更：proposal.md（内容/原因）、design.md（实现方式、关键决策、风险）、specs/**/*.md（需求和场景）、tasks.md（实现检查清单）。如果故事已分派，变更已存在——/opsx:propose 会对其进行细化。

后置条件： openspec/changes/<change-name>/proposal.md 已存在（并附有 design.md、specs/、tasks.md）。

阶段 3：设计评审

从非功能性角度评审范围——架构、接口、任务分解：

  1. 安全性——身份验证缺口、注入面、数据泄露？
  2. 性能——N+1 查询、大型负载、阻塞操作？
  3. 现有模式——是否遵循代码库惯例？
  4. 边缘情况——并发、竞态条件、故障模式？

如需调整，直接更新 OpenSpec 变更文件。

精简模式： 完全跳过阶段 3。

后置条件： 用户已批准设计，并将批准记录在 proposal.md 中（批准说明或已勾选的复选框）。

提交到集成分支

根据 /aep-git-ref「控制面提交」中的说明，将变更目录和所有架构文档作为控制面提交提交到 $BASE（按 /aep-git-ref「解析 $BASE」中的说明解析 $BASE）。使用 git add openspec/changes/<change-name>/ docs/ 显式暂存，并使用提交消息 feat: add <change-name> architecture doc and OpenSpec change。这样可确保从 $BASE 创建工作区时，其中包含所有产物。

后置条件： 变更目录已提交并推送到 $BASE。

下一步

设计已完成。继续执行 /aep-launch，启动自主工作区会话以实现该功能。

评论

支持 Markdown