analyze-if-func-spec-too-complex

機能仕様が複雑すぎるか分析する

まずルールを読み込んでください。 .plain ファイルを読んだり、編集したり、書き込んだりする前に、load-plain-reference スキルを実行し、案内されたルールファイルを読んでください。この会話ですでに load-plain-reference が実行されている場合に限り、これを省略できます。

重要な理由

レンダラーには厳格な複雑さの上限があり、各機能仕様が想定するコード変更は 最大200行 でなければなりません。この上限を超えると、レンダラーは「Functional spec too complex!」として拒否するため、仕様を分割する必要があります。挿入前にこれを把握すれば、レンダリングの失敗を防げます。

入力

草案の機能仕様（まだファイルに挿入されていないもの）と、追加先となる .plain ファイルの全コンテキスト（定義、実装要件、既存の機能仕様）。

ワークフロー

1. .plain ファイル全体（および requires／import モジュール）を読み、現在のコードベースの状況を把握します。すでにあるものと、新しい仕様が何を基盤としているかを確認してください。
2. 草案の機能仕様を注意深く読みます。
3. 以下のチェックリストを使って、複雑さを分析します。
4. 判定だけを出力します。 ACCEPTABLE または TOO COMPLEX のいずれかです。理由、LOC の見積もり、内訳は出力しないでください。

複雑さ分析のチェックリスト

各指標を確認してください。1つの項目に「はい」と答えただけで、必ずしも仕様が複雑すぎるとは限りませんが、「はい」が複数ある場合は強い警告サインです。

0. 最初の仕様のブートストラップコスト

これは、requires による実装の基盤がない新しいルートモジュールで、最初の機能仕様ですか？ その場合、プロジェクト構造、パッケージメタデータ、フレームワーク設定、エントリーポイント、初期ソースファイル、ユニットテスト基盤の作成に伴う暗黙のコストを含めてください。

最初の仕様は、後続の仕様よりも大幅にシンプルでなければなりません。呼び出しとテストが可能な、最小限の決定論的な機能を1つ提供してください。観測可能な結果を伴わないセットアップは許容されませんが、ブートストラップ作業に永続化、連携、複数のインターフェース、分岐するワークフロー、または横断的な動作を組み合わせる場合は、「TOO COMPLEX」となる強い兆候です。

1. 異なる動作の数

仕様には、個別にテストできる動作が複数記述されていますか？

複雑すぎる：

***functional specs***

# manage-tasks
A :User: can create, edit, delete, and archive :Task: items, with validation on all fields and confirmation dialogs for destructive actions.

許容範囲内（動作ごとに1つ）：

***functional specs***

# create-task
A :User: can create :Task:. Only valid :Task: items can be added.

# edit-task
A :User: can edit :Task:.

# delete-task
A :User: can delete :Task:.

# archive-task
A :User: can archive :Task:.

2. 新たに導入または変更する概念の数

仕様を実現するために、まだ存在しないデータ構造、UI コンポーネント、API エンドポイント、その他の構成要素を導入する必要がありますか？ それぞれ数えてください。

• 新しい構成要素が0～1個 → おそらく問題ありません
• 新しい構成要素が2～3個 → 境界線上です。慎重に検討してください
• 新しい構成要素が4個以上 → ほぼ確実に複雑すぎます

3. 分岐ロジックと条件

複数の条件分岐、モード、または特殊なケースが記述されていますか？

複雑すぎる：

***functional specs***

# process-order
:Order: processing depends on :OrderType:. Standard orders are validated and stored. Express orders skip validation and are queued for immediate dispatch. Bulk orders are split into sub-orders of 100 items each, validated individually, and processed in parallel with progress tracking.

許容範囲内（モードを分ける）：

***functional specs***

# process-standard-order
A standard :Order: is validated and stored.

# process-express-order
An express :Order: is queued for immediate dispatch without validation.

# split-bulk-order
A bulk :Order: is split into sub-orders of 100 items each.
- Each sub-order is processed individually.

4. 横断的な懸念事項

エラー処理、ログ記録、再試行ロジック、ページネーション、キャッシュなどの横断的な懸念事項と、コア機能がひとまとめになっていますか？

複雑すぎる：

***functional specs***

# fetch-resources
:Resource: items are fetched from the external API with pagination support, retry on transient errors with exponential backoff, caching for 5 minutes, and logging of all API calls.

許容範囲内（懸念事項を分ける）：

***functional specs***
# fetch-resources
:Resource: items are fetched from the external API.

# fetch-resources-paged
:Resource: items are fetched from the external API in pages.

# retry-resource-fetch
Fetching :Resource: items is retried on transient errors using exponential backoff.

5. UI の複雑さ

複数のインタラクティブ要素、レイアウト、状態遷移を含む、完成された画面やページが記述されていますか？

複雑すぎる：

***functional specs***

# dashboard
The dashboard shows :User: profile, recent :Task: items in a sortable table, a notification bell with unread count, and a sidebar with navigation links that highlights the active page.

許容範囲内（段階的に構築する）：

***functional specs***

# dashboard-page
A dashboard page is shown for :User:.

# dashboard-recent-tasks
Recent :Task: items are shown in a sortable table on the dashboard.

# dashboard-notifications
A notification indicator with the unread count is shown on the dashboard.

6. データ変換の複雑さ

複数のエンティティにわたる複雑なデータのマッピング、集計、または変換が必要ですか？

• シンプルなフィールドのマッピングやフィルタリング → おそらく問題ありません
• 複数段階の変換、エンティティ間の結合、または集計 → 複雑すぎる可能性があります

7. 暗黙の技術コンポーネント

仕様では、記述されている動作に加えて、相応の技術コンポーネント（エンジン、パーサー、スケジューラー、レイアウトアルゴリズム、状態マシン、同期機構など）の構築が暗に求められていますか？ コンポーネントは無料で使えるプリミティブではありません。コンポーネントのコードも生成する必要があるため、200 LOC の予算に含め、見積もりの一部として評価する必要があります。コンポーネントの構築と、その上に動作を組み立てることの両方が必要な仕様は、実質的に 1 つの仕様に 2 つのコード群が含まれていることになり、「複雑すぎる」ことを強く示しています。コンポーネントを呼び出すための接着コードだけでなく、コンポーネント自体の実装も数えてください。

複雑すぎる（コンポーネントを構築し、1 つの仕様内で使用する）：

***functional specs***

# export-report-pdf
A :Report: is exported to PDF, laying out multi-page tables with repeating headers and page numbers, and charts rendered from :Report: data.

許容範囲（コンポーネントを独立した仕様で定義し、その後に参照する）：

***functional specs***

# pdf-renderer-tables
:PdfRenderer: lays out multi-page tables from structured content.
- Table headers repeat at the top of each page.
- Each page shows its page number.

# export-report-pdf
A :Report: is exported to PDF using :PdfRenderer:, embedding charts rendered from :Report: data.

この指標に該当する場合は、break-down-func-spec の Strategy 6 を適用して修正します。コンポーネントを先行する独立した仕様として切り出し、参照してください。

8. おおよその LOC の見積もり

実装規模を頭の中で見積もってください。次の点を考慮します。

• 新たに作成する必要があるファイル
• 新しい関数／メソッド
• 暗黙に必要となる技術コンポーネント（エンジン、パーサー、アルゴリズムなど）のコード。使用するための接着コードだけではありません
• データモデルの変更（スキーマ、マイグレーション、型）
• UI コンポーネント（該当する場合）
• テストのセットアップとアサーション（ユニットテストは並行して自動生成されます）
• 新しいルートモジュールの最初の仕様では、実装要件から暗に必要となるプロジェクトおよびテストの足場一式
• エラー処理の経路
• インポート文と定型コード

見積もりが約 150 LOC を超える場合、仕様が複雑すぎるリスクが高くなります（レンダラーが必要な定型コードを追加する余地を残してください）。

出力形式

このスキルは、前後にテキスト、説明、見積もり、内訳を付けず、次の文字列のいずれか 1 つだけを出力します。

ACCEPTABLE

または

TOO COMPLEX

内部分析（チェックリスト、LOC の見積もり、推論）は判定の参考にしますが、出力には含めてはいけません。結果に基づく次の対応は呼び出し元が決定します。

add-functional-spec / add-functional-specs との連携

このスキルは、仕様のドラフト作成後、ファイルへの挿入前に、add-functional-spec ワークフローのステップ 3 で（または add-functional-specs の各仕様について）呼び出されます。呼び出し元は、次の 1 語の判定に基づいて処理します。

• ACCEPTABLE — 仕様の挿入に進みます。
• TOO COMPLEX — break-down-func-spec を呼び出して小さな仕様を作成し、その後、仕様ごとに個別に挿入します（各仕様で競合チェックを実行します）。