mcpField
F
full-feature-flow

full-feature-flow

github.com/sztadii其他09 次安装今天更新
代码仓库

关于 full-feature-flow

full-feature-flow 是一项编排技能,负责将功能、修复或技能变更从规划推进到实现和测试。它把工作交给专门 Agent,并要求用户先批准计划再编写代码。

主要功能

  1. 01Planner、Coder 和 Tester 角色
  2. 02实现前由用户批准计划
  3. 03六个 Agent 参与审查与用户流程测试
  4. 04最多三轮测试和修复
  5. 05最终单元、端到端及构建检查

适用场景

  1. 01将功能构想推进到实现
  2. 02通过代码和关键问题审查测试修复
  3. 03用用户流程测试审查技能变更

安装

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

$npx skills add https://github.com/sztadii/agent-skills --skill full-feature-flow

安装后在 Claude Code 中输入/full-feature-flow确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

agents/
openai.yaml
references/
code-reviewer.md
coder.md
critical-reviewer.md
planner.md
tester.md
user-flow-tester.md

README 原文English

来自项目 README

README 暂无中文译文,以下为英文原文;中文介绍见上方。

Full Feature Flow

Scope

Take a feature, fix or skill change from idea to working-tree code: a Planner agrees on the plan with the user, a Coder implements it, and a Tester checks the Coder's work with six agents (code review, critical issues, user flows) in up to three rounds until it passes. The main agent (you) only orchestrates: it gathers context, relays the Planner's questions and plans, collects the user's approval and starts the Coder. It does not plan, implement or review.

Each role's model, effort, responsibilities and output live in its reference file; use them as written unless the user overrides a setting:

Invocation authorizes planning, editing the working tree and starting the agents above. It does not authorize commits, pushes, PRs or publication; honor narrower user constraints and pass them to every agent.

Dependencies

No skill dependencies

Workflow

Agents start with no parent history, so every brief must be self-contained: include the task, constraints, relevant context and the absolute path of the role's reference file, and tell the agent to read it first. The Coder also needs the paths of the Tester's and its agents' files to pass them down. In T3 Code, check orchestrator_capabilities once per thread and start agents with delegate_task using the provider, model and options from the reference file; follow each task's next without polling.

Plan

  1. Gather context: the user's request, relevant repository instructions, files and conventions, and known constraints. Resolve verifiable repository facts yourself.
  2. Start the Planner (role: "design", shared checkout) with that context. It returns exactly three questions at once.
  3. Show the user all three questions together and wait for the answers. Send the answers to the Planner's thread (t3_thread_send to its child thread) so it keeps its context; it returns a plan.
  4. Show the user the complete plan and ask whether they approve it. If not, send their feedback to the same Planner thread and show the revised complete plan. Repeat until the user explicitly approves. Never approve on the user's behalf or treat silence or unrelated replies as approval.
  5. After approval, stop the Planner (task_cancel its task) and keep the approved plan verbatim. If the user cancels, stop the Planner and end the workflow.

Build and test

  1. Start the Coder (role: "implementation", shared checkout) with the approved plan verbatim, the gathered context, user constraints and the absolute paths of every reference file except the Planner's.
  2. The Coder implements the plan and prepares access for testing: a running web app's URL, a built mobile app or an executable command or script for other changes. It then starts a Tester for each round. The Tester runs two code reviewers, two critical-issue reviewers and two user flow testers and returns validated findings. The Coder fixes them until a round passes, for at most three rounds. After a passing round or round three, even if findings remain disputed or open, it runs the whole unit suite, e2e tests and build. If checks fail, it fixes them and verifies only the failures first, then reruns the complete final set once those pass. It reports the results and unresolved disagreements. Do not start the Tester or its agents yourself.
  3. If the Coder returns a blocking question, relay it to the user and send the answer to the Coder's thread; the Coder starts over with implementation and the Tester rounds. Otherwise wait for its final report.

Result

Relay the Coder's report to the user: approved plan summary, changed paths, delivered behavior, checks and results, rounds run with each Tester's agents, user flow results and findings, findings fixed, findings declined with reasons and evidence, unresolved disagreements after the third round, open findings, full test run results and remaining risks. If any agent was unavailable or the workflow stopped, state which stage completed, what blocks the rest and the decision needed. Do not report the task as done unless the Coder reports it done.

评论

支持 Markdown