企业官网建设流程全解析

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：

在 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 中声明的参数契约如下：

命令解析规则：$ARGUMENTS中 flags 之前的所有文本被视为 feature description；--stack、--api-style、--complexity未显式给出时使用上述默认值。

六条不可违反的行为规则

命令开头用CRITICAL BEHAVIORAL RULES强制约束执行过程，违反任意一条即视为失败：

1. 严格按序执行：不得跳过、重排或合并步骤；
2. 每步必须落盘：每一步在执行下一步之前，必须在.full-stack-feature/目录产出对应的输出文件；后续步骤只从磁盘文件读取前序产出，禁止依赖上下文窗口记忆——这是对抗长任务上下文漂移的关键设计；
3. 检查点强制停顿：遇到PHASE CHECKPOINT必须停止，用 AskUserQuestion 工具给出明确选项等待用户批准；
4. 失败即停：任何步骤失败（Agent 错误、测试失败、依赖缺失）立即停止，展示错误并询问用户如何继续，不得静默推进；
5. 仅使用本地 Agent：所有subagent_type只能引用本插件自带的 Agent 或general-purpose，无跨插件依赖；
6. 禁止自主进入计划模式：不得调用 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 工具逐题提问（禁止一次性抛出全部问题），问题顺序固定：

1. Problem Statement：该功能解决什么问题？用户是谁、痛点是什么？
2. Acceptance Criteria：关键验收标准是什么？何时算「完成」？
3. Scope Boundaries：明确「超出范围」的部分；
4. Technical Constraints：技术约束（既有 API 约定、特定数据库、延迟要求、认证系统等）；
5. Stack Confirmation：确认技术栈——「已从项目探测到 [stack]，前端框架？后端框架？数据库？有变化吗？」；
6. Dependencies：该功能是否依赖或影响其他功能/服务。

收集完毕后写入01-requirements.md，模板包含：Problem Statement、Acceptance Criteria（以复选框形式）、In Scope / Out of Scope、Technical Constraints、Technology Stack（frontend/backend/database/infrastructure）、Dependencies，以及 Configuration 小节（Stack / API Style / Complexity 三个字段）。

随后更新state.json：current_step置 2，files_created追加"01-requirements.md"，completed_steps追加 step 1。

Step 2：数据库与数据模型设计（.full-stack-feature/02-database-design.md）

读取01-requirements.md后，用 Task 工具启动一个general-purpose子 Agent，提示词以「You are a database architect」开场，交付物明确为六项：

1. 实体关系设计：表/集合、关系、基数；
2. Schema 定义：列类型、约束、默认值、可空字段；
3. 索引策略：哪些列建索引、索引类型、复合索引；
4. 迁移策略：生产环境安全地新增/修改 schema；
5. 查询模式：预期的读写模式及 schema 如何支撑；
6. 数据访问模式：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.md，current_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–7）

Step 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）：审查 N+1 查询、缺失索引、未优化查询、内存泄漏、缺失缓存机会、大 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–9）

Step 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/目录下形成一个完整的、可审计的交付档案：

由于步骤 2 强制要求「从磁盘读取前序文件而非依赖上下文记忆」，这 10 个文件构成了整个工作流的单一事实来源，也天然成为后续代码评审、PR 描述与部署决策的依据。

底层支撑：插件自带的四个专家 Agent

命令中引用的三个full-stack-orchestration-*Agent 与general-purpose共同承担执行职责，每个 Agent 都通过 Frontmatter 声明了名称、描述与模型分层（详见 plugins/full-stack-orchestration/agents）：

• test-automator（模型 sonnet）：AI 驱动的测试自动化专家，覆盖 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 负载测试与 N+1/索引优化。命令中 7c 步骤审查清单（N+1 查询、缺失索引、内存泄漏、包体积）与该 Agent 的能力描述完全吻合；
• deployment-engineer（模型 haiku）：部署工程专家，覆盖 GitHub Actions/GitLab CI、GitOps（ArgoCD/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.md（202 个 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