プロダクト要求定義書(PRD)を構造的に作成

非機能要件ヒアリングシート（8ファイル）に記載されたAWSサービスの仕様が最新版と一致しているか自動チェックできます。 SLA・クォータなどの数値、サービス機能、ベストプラクティスが現在の公式情報と乖離していないかを検証できます。 旧サービス名のままで記載されている、サービス提供が終了している、新機能が言及されていないなどの課題を特定できます。 チェック範囲を全体・特定ファイル・カテゴリごとに指定でき、効率的に更新対象を絞り込めます。 AWS最新情報との照合結果をレポートにまとめ、ドキュメント更新の優先度判断ができます。 AWSソリューションアーキテクトやクラウド設計者 定期的にAWSドキュメント・ベストプラクティスを最新に保ちたい企業 長期運用しているAWSプロジェクトの非機能要件定義を刷新したい PM・要件定義者 信頼性・セキュリティ・コスト最適化など特定カテゴリの陳腐化を重点的にチェックしたいアーキテクト 非機能要件ヒアリングシート（reliability・security・cost-optimization等8ファイル）に記載されたAWSサービス情報を最新の公式仕様と照合します。検索範囲は $ARGUMENTS で指定可能（引数なし=全体、ファイル名指定、カテゴリ指定）。 ワークフローは4段階です。Step 1: nfr-taxonomy.mdとチェック対象ファイルを読み込み、Step 2: 各ファイルからAWSサービス名・SLA数値・機能記述・ベストプラクティスを抽出、Step 3: aws-knowledge MCPサーバーで照合（SLA正確性、サービス機能最新性、リブランド有無、新サービス欠落、非推奨サービス記載の5観点）、Step 4: 照合結果を日本語レポートで出力。AWS最新情報との不一致が確認できた場合のみ指摘し、確認できない情報は記載しません。

PRDの要件を技術実装の詳細設計に落とし込み、機能設計書を素早く作成できます。 既存の設計書がある場合は自動的にそれを参考にし、構造を保ちながら更新・補足できます。 テンプレートとガイドが用意されているため、何から書き始めるか迷わずに執筆を開始できます。 設計書を docs/functional-design.md に一元管理し、チーム全体で設計内容を共有できます。 プロダクト企画者が決めた要件を、開発者向けに技術的な実装方法として落とし込みたい人 チームメンバーに「この機能はどう実装する予定？」を分かりやすく説明したい人 新しいプロジェクトやフェーズの開始時に、設計ドキュメントの骨組みをすぐに整えたい人 既存の設計書を保ちつつ、内容を段階的に充実させたい人 機能設計書作成の前提として、docs/product-requirements.md のPRDが存在する必要があります。設計書の優先順位として、既存の docs/functional-design.md がある場合はそれを最優先とし、このスキルのガイドは参考資料として使用します。新規作成時はテンプレート（./template.md）と詳細ガイド（./guide.md）を参照してください。作成した機能設計書は docs/functional-design.md に保存され、既存設計書がある場合は構造と内容を維持しながら更新します。

ユーザーからの新機能や変更指示を受け取ると、それに基づいた作業計画書（requirements.md、design.md、tasklist.md）を自動生成できます。 tasklist.md に記載されたタスクを 1 つずつ進捗管理し、完了時にリアルタイムで checklist を更新できます。 プロジェクトの永続ドキュメント（product-requirements.md、functional-design.md、architecture.md など）と整合させながら、一貫性のある設計・実装を進められます。 実装完了後に振り返りドキュメントを自動生成し、次のタスクへの知見を記録できます。 作業指示を受けるたびに「何をやるのか」「どの順序でやるのか」を明確に整理したい PM・チームリード 複数の並行タスクがあり、進捗を可視化・一元管理したい開発チーム 実装完了時に「何をやったか」「なぜそう決めたか」を記録し、チームの知識を蓄積したい人 プロジェクトの永続的な設計方針と日々のタスク実行を同じドキュメント体系で管理したい人 Steering スキルは、.steering/[YYYYMMDD]-[機能名]/ の形式でディレクトリを作成し、requirements.md、design.md、tasklist.md の 3 つのテンプレートに基づいたファイルを生成します。実装時には tasklist.md を常に開いた状態で進め、タスク開始時に [ ] → [x] に更新し、完了時に EditToolで記録することが必須です。重要な原則として、tasklist.md の全タスクが完了するまで作業を継続し、「時間の都合」「別タスク予定」などの理由によるスキップは禁止です。タスクが大きすぎる場合はサブタスクに分割し、スキップが許可されるのは実装方針変更・アーキテクチャ変更・依存関係変更・設計変更など技術的理由に限定されます。スキップ時には tasklist.md に理由を明記し、最後に振り返りドキュメントを作成して実装完了とします。