Skill.md検索

PRD（企画書）と機能設計をもとに、システムの技術構成を決定し、図面として記録できます。 採用するプログラミング言語、データベース、API通信方式などの技術選定を、一覧表・図解・テキストで明確に文書化できます。 既存の設計書がある場合は優先し、ない場合は提供テンプレートを使って新規作成できます。 後続の実装チームが「どんな技術を使うのか」「どの部品がどう連携するのか」を一目で理解できる設計書を作成できます。 作成した設計書は docs/architecture.md に自動保存され、プロジェクト全体で参照可能になります。 システム構築の前に「技術全体像」を整理したいプロジェクトマネージャー・PO 開発チーム全体の共通理解を作りたいテックリード・アーキテクト 既存プロジェクトの技術選定を見直す必要がある開発責任者 複数チームで並行開発するときに技術的な一貫性を保ちたい組織 このスキルは、PRD（docs/product-requirements.md）と機能設計書（docs/functional-design.md）の前提条件を確認した上で、アーキテクチャ設計書を作成します。既存設計書（docs/architecture.md）がある場合はそれを優先し、ない場合は提供されたテンプレート（./template.md）とガイド（./guide.md）に従い新規作成します。アーキテクチャ設計は、PRDの要件と機能設計を技術的に実現するためのシステム構造とテクノロジースタック（使用言語・フレームワーク・DB・ミドルウェアなど）を定義します。出力先は docs/architecture.md です。

プロジェクト固有の用語と技術用語を体系的に定義・管理できます。 要件定義書、設計書、アーキテクチャなど複数ドキュメントから用語を統一的に抽出できます。 既存の用語集がある場合、その構造を保ちながら追加・更新できます。 全チームで用語の意味を共通認識化し、ドキュメント作成時の表記ゆれを防げます。 プロジェクトマネージャーで、チーム内の用語定義を統一したい人 ドキュメント作成者で、用語の一貫性を保ちたい人 新しいプロジェクトを立ち上げるときに用語体系を整備したい人 用語集を作成するための詳細ガイドです。前提条件として、①docs/product-requirements.md（PRD）②docs/functional-design.md（機能設計書）③docs/architecture.md（アーキテクチャ設計書）④docs/repository-structure.md（リポジトリ構造）⑤docs/development-guidelines.md（開発ガイドライン）を確認します。既存ドキュメント優先順位は①既存docs/glossary.md（最優先、プロジェクト固有定義）→②このスキルのガイド（参考資料）です。新規作成時はテンプレート使用、更新時は既存構造・内容を維持します。出力先はdocs/glossary.md、詳細ガイドは./guide.md、テンプレートは./template.mdを参照します。

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

プロダクトアイデアから、実装に耐える詳細なPRD（プロダクト要求定義書）を対話的に作成できます。 ターゲットユーザー、課題、機能要件、非機能要件、成功指標をテンプレートに沿って体系的に整理します。 曖昧な要件を具体的・測定可能な形に落とし込み、「これは実装可能か」をAIが検証します。 機能を優先度（P0必須/P1重要/P2検討）で分類し、MVP範囲を明確にします。 既存PRDがある場合は構造を維持しながら更新、新規作成時はテンプレートガイドを参照できます。 起業家・プロダクトマネージャーで、アイデアを実装可能な形に落とし込みたい方 デザイナーや開発チームのリーダーで、要件の曖昧さを事前に潰したい方 投資家向けプレゼン資料としても使える、説得力のあるドキュメントを作成したい方 プロダクト開発の初期段階で、「作る前に仕様を決め切る」プロセスを回したい方 PRD作成の前提条件として、docs/ideas/initial-requirements.md に初期要求（アイデア、課題、ターゲット、主要機能、MVP範囲）を保存する必要があります。既存の docs/product-requirements.md がある場合は最優先し、このスキルのテンプレートは参考資料として使用します。作成プロセスは①initial-requirements.md 確認、②テンプレートに従ってドラフト生成、③5つの観点（ビジョン明確性、ユーザー具体性、成功指標測定可能性、機能詳細化レベル、非機能要件網羅性）でレビュー、④指摘を改善・再レビュー、です。重要な方針として「具体性と測定可能性」「ユーザー中心設計」「優先順位の明確化（P0/P1/P2）」を掲げ、ユーザーストーリーフォーマットと優先度分類が含まれます。

アーキテクチャ設計で決まった技術スタック（言語、フレームワーク、DBなど）を反映した、実際のディレクトリ構造を定義できます。 src/, tests/, docs/, config/ など、各フォルダの役割と配置ルールを明文化し、開発チーム全体で統一できます。 既存のディレクトリ構造定義がある場合は優先し、ない場合は提供テンプレートを使って新規作成できます。 新しいメンバーが加わったときに「このファイルはどのフォルダに置く？」という質問がなくなり、コード審査がスムーズになります。 作成した定義書は docs/repository-structure.md に自動保存され、プロジェクト全体で参照可能になります。 プロジェクトを始める前に「ファイル置き場を決めたい」プロジェクトマネージャー・PO 複数開発チームが参加するとき、ファイル配置の統一ルールを作りたいテックリード リポジトリが成長するにつれて雑然としてきたプロジェクトを整理し直したい開発責任者 オンボーディングを効率化し、新しいチームメンバーの迷いを減らしたいマネージャー このスキルは、PRD（docs/product-requirements.md）、機能設計書（docs/functional-design.md）、アーキテクチャ設計書（docs/architecture.md）の前提条件を確認した上で、リポジトリ構造定義書を作成します。既存定義書（docs/repository-structure.md）がある場合はそれを優先し、ない場合は提供されたテンプレート（./template.md）とガイド（./guide.md）に従い新規作成します。リポジトリ構造は、アーキテクチャ設計で決定された技術スタックとシステム構成を反映した具体的なディレクトリ構造およびファイル配置ルールを定義します。出力先は docs/repository-structure.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 に理由を明記し、最後に振り返りドキュメントを作成して実装完了とします。

ユーザーの指示内容から作業計画書・要件書・設計書・タスクリストを自動生成し、体系的に整理・記録できます。 タスクリストに基づいて実装を段階的に進め、各タスクの完了状況をドキュメントにリアルタイム更新します。 実装完了後に振り返り記録を作成し、プロジェクト全体の成果と学習ポイントをドキュメント化します。 大規模な機能開発や複数タスクを確実に完了させたい開発者 作業の進捗を可視化し、チームや後続の参照用に記録したい人 タスク漏れやスキップを防ぎ、実装品質を保ちたい人 プロジェクトの意思決定や設計思想を永続的に残したい人 ステアリングファイル（.steering/）に基づく実装支援スキル。モード1（ステアリングファイル作成）では日付形式でディレクトリを作成し、永続ドキュメント（product-requirements.md、functional-design.md、architecture.md、repository-structure.md、development-guidelines.md）を確認した上で、テンプレートからrequirements.md・design.md・tasklist.mdを生成。モード2（実装・最重要）では tasklist.mdを常に参照しながら実装を進め、タスク開始・完了時にEditツールで即座に更新する。全タスク完了が絶対原則で、「時間不足」「難しい」などの理由でスキップを禁止。未完了タスク残存での終了や振り返り記入を禁止。タスク分割やサブタスク追加で対応。技術的理由のみスキップ許可（実装方針変更・アーキテクチャ変更・依存関係変更・設計変更）。

コーディング規約の可視化: 言語別の命名規則、関数設計、エラーハンドリング、テストコードなど、統一されたコーディング規約をドキュメント化できます。 開発プロセスの標準化: Git運用ルール（ブランチ戦略）、コミットメッセージ、Pull Requestプロセスを統一し、チーム全体のレビュー品質を向上させられます。 テスト戦略の確立: テストピラミッド、カバレッジ目標、テストコード実装パターンを定義し、品質を保証できます。 新規メンバーのオンボーディング短縮: 開発ガイドラインがあることで、新しいチームメンバーが素早くプロジェクトの開発スタイルをキャッチアップできます。 テックリード・エンジニアリングマネージャー: チーム全体の開発品質を高めたい方 スタートアップの創業期エンジニア: チーム拡大前に開発プロセスを整備したい方 プロジェクト責任者: コードレビュー負荷を減らし、チーム全体の生産性を向上させたい方