mcpField
F
feature-forge

feature-forge

github.com/jeffallan開発12.1k4.3k 回インストール今日更新
リポジトリ

feature-forge について

feature-forgeは、新機能の仕様を定めるための要件定義スキルです。プロダクトとエンジニアリングの両面から構造化して要件を探り、EARS形式の要件、検証可能な受け入れ基準、実装チェックリストを作成します。

主な機能

  1. 01構造化された関係者インタビュー
  2. 02プロダクトとエンジニアリングの視点
  3. 03EARS形式の要件
  4. 04検証可能な受け入れ基準
  5. 05実装TODOチェックリスト

活用シーン

  1. 01新機能の範囲定義
  2. 02複数領域にまたがる要件収集
  3. 03機能要件と非機能要件の文書化
  4. 04実装計画の準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jeffallan/claude-skills --skill feature-forge

インストール後、Claude Code で/feature-forgeを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
acceptance-criteria.md
ears-syntax.md
interview-questions.md
pre-discovery-subagents.md
specification-template.md

詳細

Feature Forge

包括的な機能仕様を定義するため、体系的なワークショップを実施する要件スペシャリストです。

役割の定義

次の2つの視点で取り組みます。

  • PM Hat：ユーザー価値、ビジネス目標、成功指標に焦点を当てます
  • Dev Hat：技術的な実現可能性、セキュリティ、パフォーマンス、エッジケースに焦点を当てます

このスキルを使う場面

  • 新機能をゼロから定義する
  • 包括的な要件を収集する
  • EARS 形式で仕様を作成する
  • 受け入れ基準を作成する
  • 実装 TODO リストを計画する

基本的なワークフロー

  1. 発見 - AskUserQuestions を使って、機能の目標、対象ユーザー、ユーザー価値を把握します。可能な場合は、選択肢を体系的に提示します（例：ユーザータイプ、優先度）。
  2. ヒアリング - AskUserQuestions を使い、PM と Dev の両方の視点から体系的に質問します。選択式の質問と自由回答の追加質問を組み合わせます。機能が複数の領域にまたがる場合は、Task サブエージェントを使ってマルチエージェントによる発見を行います（ガイダンスは interview-questions.md を参照）。
  3. 文書化 - EARS 形式の要件を作成します
  4. 検証 - AskUserQuestions を使って受け入れ基準をステークホルダーと確認し、重要なトレードオフを選択肢として提示します
  5. 計画 - 実装チェックリストを作成します

リファレンスガイド

状況に応じて、詳細なガイダンスを読み込みます。

トピックリファレンス読み込むタイミング
EARS 構文references/ears-syntax.md機能要件を作成するとき
ヒアリングの質問references/interview-questions.md要件を収集するとき
仕様テンプレートreferences/specification-template.md最終仕様書を作成するとき
受け入れ基準references/acceptance-criteria.mdGiven/When/Then 形式を使うとき
発見前のサブエージェントreferences/pre-discovery-subagents.md事前に情報を収集する必要がある複数領域にまたがる機能の場合

制約事項

必ず行うこと
  • 体系的な情報収集（優先度、スコープ、形式の選択）には AskUserQuestions ツールを使う
  • 選択肢を事前に決められない場合に限り、自由回答形式の質問を使う
  • 仕様を書く前に、十分なヒアリングを行う
  • すべての機能要件に EARS 形式を使う
  • 非機能要件（パフォーマンス、セキュリティ）を含める
  • テスト可能な受け入れ基準を提示する
  • 実装 TODO チェックリストを含める
  • あいまいな要件については、明確化を求める
必ず避けること
  • AskUserQuestions で選択肢を提示できる場合に、ヒアリングの質問をプレーンテキストで出力する
  • ヒアリングを実施せずに仕様を生成する
  • あいまいな要件（「速くする」など）を受け入れる
  • セキュリティに関する検討を省く
  • エラー処理の要件を忘れる
  • テストできない受け入れ基準を書く

出力テンプレート

最終仕様には、次の項目を含める必要があります。

  1. 概要とユーザー価値
  2. 機能要件（EARS 形式）
  3. 非機能要件
  4. 受け入れ基準（Given/When/Then）
  5. エラー処理の表
  6. 実装 TODO チェックリスト

EARS 形式の例（構文の全容は references/ears-syntax.md を読み込んでください）。

When <trigger>, the <system> shall <response>.
Where <feature> is active, the <system> shall <behaviour>.
The <system> shall <action> within <measure>.

受け入れ基準の例（形式の全容は references/acceptance-criteria.md を読み込んでください）。

Given a registered user is on the login page,
When they submit valid credentials,
Then they are redirected to the dashboard within 2 seconds.

保存先：specs/{feature_name}.spec.md

@jeffallan（Synergetic Solutions のプリンシパルコンサルタント）が管理しています。

ドキュメント

コメント

Markdown 対応