mcpField
A
avoid-feature-creep

avoid-feature-creep

github.com/waynesuttonエージェントワークフロー4051.3k 回インストール4 週間前に更新
リポジトリ

avoid-feature-creep について

avoid-feature-creep は、コーディングエージェントや開発者向けに、実装範囲を依頼内容に沿わせるスキルです。範囲拡大の兆候や確認用の問い、追加案を提案として保留する手順を示します。

主な機能

  1. 01変更を依頼内容に結び付ける
  2. 02範囲拡大の兆候を見つける
  3. 03追加事項を提案として保留
  4. 04問いを使った範囲確認
  5. 05PRDへの範囲管理の適用

活用シーン

  1. 01バグ修正を依頼された変更に限定
  2. 02エージェントの実装案をレビュー
  3. 03製品要件と将来案を切り分ける

インストール

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

$npx skills add https://github.com/waynesutton/builder-skills --skill avoid-feature-creep

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

同梱ファイルagents/openai.yamlassets/small-logo.svg

詳細

機能のスコープを広げない

依頼によって作業範囲が決まります。差分に含まれるすべての変更は、依頼文のどれかの一文に根拠がなければなりません。それ以外は変更ではなく、提案です。

基本ルール

依頼されたものを作ります。あると便利そうなものでも、シニアエンジニアなら追加するものでも、コードベースが「こうあるべき」というものでもありません。差分の各行について、依頼を根拠に説明できないなら、その行は差分に含めるべきではありません。

これは、プロダクトのスコープにもコードのスコープにも当てはまります。問題の記述を超えて大きくなった PRD は、リファクタリングも一緒に出荷するバグ修正と同じ問題を抱えています。

スコープが広がり始めた兆候

次のいずれかに気づいたら、立ち止まってください。

  • 考えているときに「ついでに」や「せっかくだから」が出てくる
  • 誰も依頼していないケース向けに、設定オプション、フラグ、パラメーターを追加する
  • 変更箇所の近くにあるコードが整理されていないように見えたため、リファクタリングする
  • 最初の機能を完成させるために、別の機能を追加する
  • ユーザーが遭遇したことのないエッジケース向けにエラーハンドリングを追加する
  • 変更範囲外のコードにテスト、型、ドキュメントを追加する
  • 単発の処理を再利用可能な抽象化に一般化する
  • 明確なユーザーニーズが示されていないのに、競合の機能を模倣する
  • PRD の「将来」や「あるとよい」セクションが、どんどん長くなる
  • 依頼から必要性が読み取れないファイルに変更が及ぶ

どれもよいアイデアかもしれません。しかし、ユーザーから依頼されない限り、どれも作業範囲には含まれません。

代わりにすること

  1. 依頼を完了します。依頼に十分に応える、最小限の変更を出荷します。
  2. 追加のアイデアは、その都度記録します。実行には移しません。
  3. 最後に、追加のアイデアを一か所にまとめます。
    • チャットや PR の概要では、Suggestions という見出しの下に一行ずつ記載します
    • PRD では、理由を一行添えて Out of scope に記載します
    • prds/ フォルダーがあるリポジトリでは、該当する PRD の Out of scope セクションに追記します
  4. 判断はユーザーに委ねます。「エージェントがそう考えた」は承認ではありません。

提案を書くのは簡単で、無視しても何も失いません。依頼されていないコードはレビュー時間を増やし、バグを招き、変更の目的を曖昧にします。

ステークホルダーとエージェント

すべての機能リクエストには、PM、経営幹部、ユーザー、個人的な課題を解決したい開発者、AI コーディングエージェントなど、発案者がいます。全員に同じように対応してください。依頼を記録し、現在のスコープに照らして検討し、今回の作業を始めた問題を解決するものでない限り、後回しにします。

AI エージェントも、今やステークホルダーです。意見を持ち、追加を提案してきます。エージェントがスコープを広げるときによく使う言い回しは次のとおりです。

  • 「まだ遭遇していないエッジケース向けに、エラーハンドリングも追加しましょう」
  • 「リファクタリングすれば、もっとすっきりします」
  • 「これにはテストも追加したほうがよいでしょう」
  • 「これらの追加シナリオに型を追加しました」

あなたがエージェントなら、自分がこうしたことをしていないかに気づき、提案リストに移してください。エージェントと作業しているなら、セッションの開始時にスコープを伝え、追加の提案は他のステークホルダーからの依頼と同じように扱ってください。

何かを追加する前に、次の点を確認してください。

  • これは、依頼で示された問題を解決しますか？
  • 機能する最小の形は何ですか？
  • これを作らなかった場合、どうなりますか？

最初の答えが「いいえ」なら、提案に回します。

変更前と変更後

依頼：「タスクに deletedAt フィールドを追加し、一覧クエリで削除済みタスクを非表示にする。」

変更前、スコープが広がった例：

  • スキーマに deletedAt を追加
  • by_user_and_deleted インデックスを追加
  • インデックスを使うよう list を書き換え
  • softDelete、restore、purgeDeleted ミューテーションを追加
  • 30 日後に削除する cron を追加
  • list を listActive に改名し、3 か所の呼び出し元を更新
  • 「後で管理者ビューに使うため」showDeleted 引数を追加

変更後、スコープを守った例：

  • スキーマに deletedAt: v.optional(v.number()) を追加
  • インデックスを追加して list から使うようにし、削除済みの行が読み込まれないようにする

変更と一緒に送る概要：

Done: deletedAt field and list query now skips deleted tasks.

Suggestions
- A softDelete mutation to set deletedAt (nothing sets it yet)
- A restore mutation
- A cron to purge rows older than 30 days
- An admin flag on list to include deleted rows

差分の 2 行で依頼に応えました。提案の 4 行で、すべてのアイデアを残しました。次に何をするかはユーザーが決めます。

PRD

PRDの各セクションは、問題の説明に立ち返ることで、その価値が示されます。PRDが大きくなってきたら、次のようにします。

  • 問題の説明を読み直します。問題の解決に役立たない項目は削除します。
  • 削除した項目は、それぞれ理由を1つ添えて Out of scope に移します。
  • 削除した項目がまとまりのある機能を形成するなら、それは最初のPRDを大きくするのではなく、2つ目のPRDにします。

チェックリスト

  • 変更したすべてのファイルが、依頼内容から必要だと判断できます
  • 依頼されていない新しい設定オプション、フラグ、パラメーターを追加していません
  • 周辺コードをリファクタリングしていません
  • 最初の機能を完成させるために、別の機能を追加していません
  • 変更範囲外のコードについて、テスト、型、ドキュメントを追加していません
  • 追加項目は、要約の Suggestions またはPRDの Out of scope に記載されています
  • 要約では、提案の前に、実施した内容を1行で説明しています
  • ユーザーが「頼んだことだけを実行して」と言った場合、差分にはそれだけが含まれています

コメント

Markdown 対応