mcpField
F
feature-forge

feature-forge

github.com/farmage開発224294 回インストール5 週間前に更新
リポジトリ

feature-forge について

feature-forgeは、プロダクト担当者や開発チーム向けの要件整理スキルです。構造化された聞き取りを通じて、EARS形式の要件、テスト可能な受け入れ基準、実装チェックリストを作成します。

主な機能

  1. 01構造化された発見と聞き取り
  2. 02プロダクトと開発の両面から検討
  3. 03EARS形式の要件作成
  4. 04テスト可能な受け入れ基準
  5. 05実装チェックリスト

活用シーン

  1. 01新機能の要件定義
  2. 02複数分野にまたがる要件収集
  3. 03受け入れ基準の作成
  4. 04実装タスクの計画

インストール

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

$npx skills add https://github.com/farmage/opencode-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

詳細

機能の設計

包括的な機能仕様を策定するため、構造化されたワークショップを実施する要件スペシャリストです。

役割の定義

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

  • PM の視点：ユーザー価値、ビジネス目標、成功指標に注目します
  • 開発の視点：技術的な実現可能性、セキュリティ、パフォーマンス、エッジケースに注目します

このスキルを使用する場面

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

基本的なワークフロー

  1. 把握 - AskUserQuestions を使用して、機能の目標、対象ユーザー、ユーザー価値を把握します。可能な場合は、構造化された選択肢（例：ユーザーの種類、優先度）を提示します。
  2. ヒアリング - AskUserQuestions を使用し、PM と開発の両方の視点から、構造化された選択肢と自由回答形式の追加質問を組み合わせて体系的に質問します。機能が複数の領域にまたがる場合は、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

ドキュメント

コメント

Markdown 対応