full-stack-feature 命令深度解析:用 Claude Code 编排端到端全栈功能开发
full-stack-feature 命令深度解析用 Claude Code 编排端到端全栈功能开发【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本篇技术指南完整剖析full-stack-orchestration插件提供的/full-stack-orchestration:full-stack-feature命令——它把「需求澄清 → 数据库设计 → 架构设计 → 三层实现 → 测试与安全性能审查 → 部署 → 文档交接」的全过程固化为一个 9 步骤、3 阶段、双检查点的确定性多 Agent 工作流。读完本文你将掌握该命令的完整行为规则、state.json会话状态机制、每一步的输入输出契约与 Task 提示词结构并能结合插件自带的四个专家 Agent测试自动化、安全审计、性能工程、部署工程理解其底层执行逻辑从而在自己的 Claude Code 会话中可靠地驱动一次全栈功能的交付。命令定位插件生态中的一个工作流编排器在agents24/agents这个多 Harness 的 Agentic 插件市场中full-stack-orchestration属于Workflows 类目下的 16 个工作流编排器之一见 docs/architecture.md 的 Pattern 2: Workflow Orchestration 小节。与单用途插件不同编排器插件的价值在于顺序协调多个专家 Agent项目内容插件目录plugins/full-stack-orchestration命令full-stack-feature.md配套 Agentstest-automator、security-auditor、performance-engineer、deployment-engineer安装方式/plugin install full-stack-orchestration编排链路来自 docs/usage.mdbackend-architect → database-architect → frontend-developer → test-automator → security-auditor → deployment-engineer → observability-engineer在 docs/usage.md 的命令参考表中该命令被归类在「Development Features」分类描述为 Complete full-stack feature implementation与/backend-development:feature-development纯后端和/multi-platform-apps:multi-platform跨平台应用协调形成互补它是三者中覆盖面最完整的一条链路。调用方式与命令行参数该命令支持两种触发方式# 1. 结构化命令推荐参数明确 /full-stack-orchestration:full-stack-feature user dashboard with real-time analytics \ --stack react/fastapi/postgres --api-style graphql --complexity complex # 2. 自然语言Claude 自行推理并协调 Implement user dashboard with real-time analytics命令 Frontmatter 中声明的参数契约如下参数默认值可选值作用feature description必填任意文本功能描述即下文提示词中的$FEATURE占位符--stackauto-detect由项目自动探测或显式指定如react/fastapi/postgres锁定前后端与数据库技术栈--api-stylerestrest|graphql决定 API 设计输出形态--complexitymediumsimple|medium|complex控制各阶段的产出深度与检查严格度命令解析规则$ARGUMENTS中 flags 之前的所有文本被视为 feature description--stack、--api-style、--complexity未显式给出时使用上述默认值。六条不可违反的行为规则命令开头用CRITICAL BEHAVIORAL RULES强制约束执行过程违反任意一条即视为失败严格按序执行不得跳过、重排或合并步骤每步必须落盘每一步在执行下一步之前必须在.full-stack-feature/目录产出对应的输出文件后续步骤只从磁盘文件读取前序产出禁止依赖上下文窗口记忆——这是对抗长任务上下文漂移的关键设计检查点强制停顿遇到PHASE CHECKPOINT必须停止用 AskUserQuestion 工具给出明确选项等待用户批准失败即停任何步骤失败Agent 错误、测试失败、依赖缺失立即停止展示错误并询问用户如何继续不得静默推进仅使用本地 Agent所有subagent_type只能引用本插件自带的 Agent 或general-purpose无跨插件依赖禁止自主进入计划模式不得调用 EnterPlanMode因为「本命令就是计划本身」直接执行。其中第 2 条值得特别说明它把「文件即事实」的工程原则引入了 Agent 编排。每个步骤的输入全部来自.full-stack-feature/下已落盘的 Markdown意味着整个流程可以被中断、恢复、审计也使得前序 Agent 的产出天然成为后续 Agent 的上下文避免长会话中上下文窗口被稀释。预检与状态管理state.json 会话机制命令在启动时执行两类预检1. 检查既有会话检查.full-stack-feature/state.json是否存在若存在且status为in_progress读取它向用户展示当前步骤并提供两个选项——1. Resume from where we left off从断点恢复/2. Start fresh (archives existing session)归档旧会话后重新开始若存在且status为complete询问是否归档并重新开始。这套机制让一个可能跨越数小时、多轮对话的全栈功能开发具备了可恢复性——即使在 Phase 中途用户离开或会话被打断也能无损续跑。2. 初始化状态文件创建.full-stack-feature/目录与state.json初始内容模板如下{ feature: $ARGUMENTS, status: in_progress, stack: auto-detect, api_style: rest, complexity: medium, current_step: 1, current_phase: 1, completed_steps: [], files_created: [], started_at: ISO_TIMESTAMP, last_updated: ISO_TIMESTAMP }关键字段语义current_step与current_phase标记执行位置completed_steps记录已完成的步骤编号files_created累积记录产出的全部文件注意模板里直接写的是字符串01-requirements.md实际执行时会追加state.json自身与其余 8 个输出文件stack/api_style/complexity由$ARGUMENTS解析结果填充。每一步结束时都必须同步更新state.json这是整个工作流可靠性的基石。Phase 1架构与设计基础步骤 1–3交互式Step 1需求收集.full-stack-feature/01-requirements.md采用一次一问的交互式澄清用 AskUserQuestion 工具逐题提问禁止一次性抛出全部问题问题顺序固定Problem Statement该功能解决什么问题用户是谁、痛点是什么Acceptance Criteria关键验收标准是什么何时算「完成」Scope Boundaries明确「超出范围」的部分Technical Constraints技术约束既有 API 约定、特定数据库、延迟要求、认证系统等Stack Confirmation确认技术栈——「已从项目探测到 [stack]前端框架后端框架数据库有变化吗」Dependencies该功能是否依赖或影响其他功能/服务。收集完毕后写入01-requirements.md模板包含Problem Statement、Acceptance Criteria以复选框形式、In Scope / Out of Scope、Technical Constraints、Technology Stackfrontend/backend/database/infrastructure、Dependencies以及 Configuration 小节Stack / API Style / Complexity 三个字段。随后更新state.jsoncurrent_step置 2files_created追加01-requirements.mdcompleted_steps追加 step 1。Step 2数据库与数据模型设计.full-stack-feature/02-database-design.md读取01-requirements.md后用 Task 工具启动一个general-purpose子 Agent提示词以「You are a database architect」开场交付物明确为六项实体关系设计表/集合、关系、基数Schema 定义列类型、约束、默认值、可空字段索引策略哪些列建索引、索引类型、复合索引迁移策略生产环境安全地新增/修改 schema查询模式预期的读写模式及 schema 如何支撑数据访问模式Repository/DAO 接口设计。产出保存为02-database-design.md更新状态至 step 3。Step 3后端与前端架构.full-stack-feature/03-architecture.md读取01-requirements.md与02-database-design.md启动general-purpose架构 Agent提示词以「You are a full-stack architect」开场交付物分三层后端架构API 设计端点/resolver、请求响应 schema、错误处理、版本化服务层业务逻辑组件、职责边界认证/授权如何应用于新端点与既有服务/系统的集成点前端架构组件层级页面组件、容器、展示组件状态管理需要什么状态、存放在哪、数据流路由新路由、导航结构、路由守卫API 集成数据获取策略、缓存、乐观更新横切关注点错误处理链路后端错误 → API 响应 → 前端错误态安全考量输入校验、XSS 防护、CSRF、数据保护风险评估与技术风险缓解策略。产出保存为03-architecture.mdcurrent_step置为checkpoint-1。PHASE CHECKPOINT 1强制人工审批此处必须停顿向用户展示数据库设计与架构的摘要关键组件、API 端点、数据模型概览、组件结构并提供三个选项Architecture and database design are complete. Please review: - .full-stack-feature/02-database-design.md - .full-stack-feature/03-architecture.md 1. Approve -- proceed to implementation 2. Request changes -- tell me what to adjust 3. Pause -- save progress and stop here用户未选 1 之前禁止进入 Phase 2选 2 则修订后重新检查点选 3 则更新state.json并停止。这一设计把「设计评审」作为实现前的强制质量门禁确保实现阶段建立在用户认可的设计之上。Phase 2实现步骤 4–7Step 4数据库实现.full-stack-feature/04-database-impl.md读取需求与数据库设计文档启动数据库工程 Agent指令清单为创建 schema 变更的迁移脚本实现与设计一致的模型/实体按设计的查询模式实现 Repository/数据访问层添加数据库级校验约束按设计用正确索引优化查询遵循项目既有 ORM 与迁移模式。产出摘要保存为04-database-impl.md。Step 5后端实现.full-stack-feature/05-backend-impl.md读取需求、架构、数据库实现三份文档启动后端开发 Agent指令包括按架构实现 API 端点/resolver在服务层实现业务逻辑接通数据库实现的数据访问层添加输入校验、错误处理与正确的 HTTP 状态码按设计实现认证/授权中间件添加结构化日志与可观测性钩子遵循项目既有代码模式与约定。Step 6前端实现.full-stack-feature/06-frontend-impl.md读取需求、架构、后端实现文档启动前端开发 Agent指令覆盖按架构的组件层级构建 UI 组件实现设计中的状态管理与数据流用设计的数据获取策略对接后端 API实现表单处理、校验与错误态在适当位置添加加载态与乐观更新保证响应式设计与可访问性基础语义化 HTML、ARIA 标签、键盘导航遵循项目既有前端模式。该步骤带有一个显式例外若功能无前端组件纯后端/API跳过本步——在06-frontend-impl.md中写一段简短说明解释跳过原因然后继续。这避免了编排器对无 UI 需求的功能机械套用前端步骤。Step 7测试与验证.full-stack-feature/07-testing.md此步在单次响应中并行发起三个 Task是命令中并行度最高的环节7a 测试套件创建full-stack-orchestration-test-automator为全部新后端函数写单元测试为 API 端点写集成测试为迁移与查询模式写数据库测试如适用写前端组件测试覆盖快乐路径、边界情况、错误处理、边界条件遵循项目既有测试模式与框架新代码目标 80% 覆盖率7b 安全审查full-stack-orchestration-security-auditor按 OWASP Top 10、认证/授权缺陷、输入校验缺口、SQL 注入风险、XSS/CSRF 漏洞、数据保护问题、依赖漏洞与安全反模式进行审查输出带严重级别、位置与修复建议的发现清单7c 性能审查full-stack-orchestration-performance-engineer审查 N1 查询、缺失索引、未优化查询、内存泄漏、缺失缓存机会、大 payload、慢渲染路径、包体积问题、多余重渲染输出带影响评估与优化建议的发现清单。三者完成后汇总到07-testing.md结构为Test Suite / Security Findings按严重级别/ Performance Findings按影响/ Action Items交付前必须处理的 Critical/High 项。若存在 Critical 或 High 级别发现须立即修复并重新验证之后才进入 checkpoint-2。PHASE CHECKPOINT 2强制人工审批再次停顿展示测试与验证摘要Testing and validation complete. Please review .full-stack-feature/07-testing.md Test coverage: [summary] Security findings: [X critical, Y high, Z medium] Performance findings: [X critical, Y high, Z medium] 1. Approve -- proceed to deployment documentation 2. Request changes -- tell me what to fix 3. Pause -- save progress and stop here未获批准不得进入 Phase 3。这一检查点将「质量验证结果」作为交付前的第二道门禁。Phase 3交付步骤 8–9Step 8部署与基础设施.full-stack-feature/08-deployment.md读取架构与测试文档启动full-stack-orchestration-deployment-engineer指令包括为新增代码创建或更新 CI/CD 流水线配置在部署流水线中加入数据库迁移步骤如需渐进式发布则添加功能开关feature flag配置为新服务/端点定义健康检查与就绪探针为关键指标错误率、延迟、吞吐量创建监控告警编写包含回滚步骤含数据库回滚的部署 Runbook遵循项目既有部署模式。Step 9文档与交接.full-stack-feature/09-documentation.md读取全部前序.full-stack-feature/*.md文件启动general-purpose技术写作 Agent交付物为新端点的 API 文档含请求/响应示例数据库 schema 变更与迁移说明如适用更新面向用户的文档编写简短的架构决策记录ADR说明关键设计选择创建交接摘要构建了什么、如何测试、已知限制。完成将state.json的status置为complete并更新last_updated然后输出最终摘要包含 9 个输出文件清单01-requirements 至 09-documentation与四步后续建议审查所有生成的代码与文档运行完整测试套件验证全部通过基于实现创建 Pull Request按08-deployment.md中的 Runbook 部署。产物契约.full-stack-feature/目录的 10 个文件整个流程在.full-stack-feature/目录下形成一个完整的、可审计的交付档案步骤文件内容预检state.json会话状态当前步骤/阶段、已完成步骤、产出文件清单101-requirements.md需求文档问题陈述、验收标准、范围、约束202-database-design.md数据库设计与数据模型303-architecture.md前后端架构与横切关注点404-database-impl.md数据库实现摘要505-backend-impl.md后端实现摘要606-frontend-impl.md前端实现摘要纯后端功能则记录跳过原因707-testing.md测试、安全、性能审查汇总与行动项808-deployment.md部署配置与 Runbook909-documentation.mdAPI 文档、ADR 与交接摘要由于步骤 2 强制要求「从磁盘读取前序文件而非依赖上下文记忆」这 10 个文件构成了整个工作流的单一事实来源也天然成为后续代码评审、PR 描述与部署决策的依据。底层支撑插件自带的四个专家 Agent命令中引用的三个full-stack-orchestration-*Agent 与general-purpose共同承担执行职责每个 Agent 都通过 Frontmatter 声明了名称、描述与模型分层详见 plugins/full-stack-orchestration/agentstest-automator模型 sonnetAI 驱动的测试自动化专家覆盖 TDD 红绿重构循环、Playwright/Selenium 跨浏览器、Postman/Karate API 测试、k6/JMeter 性能测试、契约测试与可访问性测试。命令中 7a 步骤的「80% 覆盖率」「单元/集成/数据库/组件测试分层」均与该 Agent 的能力集一一对应security-auditor模型 opus安全审计专家覆盖 OWASP Top 10/ASVS、OAuth 2.0/OIDC、SAST/DAST、零信任架构与 GDPR/HIPAA/SOC2 合规。命令中 7b 步骤要求按严重级别输出「发现-位置-修复建议」正是该 Agent 的 Response Approach 第 3 步「Conduct comprehensive security testing」的落地performance-engineer模型 inherit性能工程专家覆盖 OpenTelemetry 分布式追踪、Core Web Vitals、多级缓存、k6 负载测试与 N1/索引优化。命令中 7c 步骤审查清单N1 查询、缺失索引、内存泄漏、包体积与该 Agent 的能力描述完全吻合deployment-engineer模型 haiku部署工程专家覆盖 GitHub Actions/GitLab CI、GitOpsArgoCD/Flux、零停机部署、数据库自动迁移与功能开关。命令中 Step 8 的七条指令CI/CD、迁移步骤、feature flag、健康检查、监控告警、回滚 Runbook即为该 Agent 的核心专长。从模型分层看命令对三个专用 Agent 的指派sonnet 测试、opus 安全、haiku 部署与 docs/architecture.md 中「Haiku 适合确定性执行、Sonnet 适合复杂推理、Opus 适合安全审计」的五层模型策略保持一致体现了「重脑力任务配强模型、确定性任务配快模型」的成本/质量平衡。在仓库中的使用上下文从仓库文档可以进一步确认该命令的定位与组合方式与其它命令的编排链路docs/usage.md 的 Multi-Agent Workflow Examples/full-stack-orchestration:full-stack-feature描述的工作流为 backend-architect → database-architect → frontend-developer → test-automator → security-auditor → deployment-engineer → observability-engineer多插件组合docs/architecture.md 的 Pattern 4可以先用本命令完成功能实现再叠加/security-scanning:security-hardening、/unit-testing:test-generate、/comprehensive-review:full-review、/cicd-automation:workflow-automate进行加固与发布安装方式作为full-stack-orchestration插件整体安装/plugin install full-stack-orchestration其 4 个 Agent、1 个命令与若有Skills 一起进入上下文仓库 README 强调「安装插件只加载其自身组件而非整个市场」这与本命令「仅使用本地 Agent、无跨插件依赖」的规则互相印证。总结full-stack-feature命令的工程价值在于三个设计选择文件化状态state.json 每步落盘保障了长任务的可靠性与可恢复性双检查点 一次一问的需求澄清把不可逆的 AI 自主推进拆解为可人工干预的分段决策并行三路验证测试/安全/性能将质量门禁内置到流程而非事后补测。对于需要在 Claude Code 中稳定交付端到端功能的团队这套「规划 → 实现 → 验证 → 交付」的编排模式本身即是一个可复用的参考范式。进一步阅读docs/usage.md命令总览与组合示例· docs/plugins.md插件目录与安装· docs/architecture.md编排器设计模式· docs/agents.md202 个 Agent 目录· plugins/full-stack-orchestration/agents命令底层依赖的四个专家 Agent。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考