mcpField
F
full-feature-flow

full-feature-flow

github.com/sztadiiその他09 回インストール今日更新
リポジトリ

full-feature-flow について

full-feature-flowは、機能・修正・スキル変更を計画から実装、テストまで進めるためのオーケストレーションスキルです。専用エージェントに作業を割り当て、コーディング前にユーザーの計画承認を求めます。

主な機能

  1. 01Planner、Coder、Testerの役割分担
  2. 02実装前のユーザーによる計画承認
  3. 036つのエージェントによるレビューとユーザーフローテスト
  4. 04最大3回のテスト・修正ラウンド
  5. 05最終的な単体・E2E・ビルド確認

活用シーン

  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.

コメント