Skill.md検索

新機能開発の際に、要件・設計・タスクをセットで作成し、計画的に実装を進められます。ステアリングファイル（.steering/）に requirements.md、design.md、tasklist.md を自動生成し、プロジェクトの方針に沿った構成をサポートします。 タスク実行中は tasklist.md を常に参照しながら、リアルタイムで進捗を記録・更新できます。チェックボックス形式で各タスクの完了状況を可視化し、実装漏れを防ぎます。 全タスクが完了するまでの進捗追跡を強制化し、「時間の都合で後回し」などの理由でタスクをスキップさせません。大きなタスクは自動的にサブタスクに分割し、完了可能な粒度に調整します。 実装完了後、振り返り内容をドキュメントに記録し、次のプロジェクトへの知見として蓄積できます。 プロジェクトマネージャーやリーダー：複数のタスク進捗を一元管理し、チーム全体の完了状況を把握したい方 開発エンジニア：要件から実装まで迷わずに進めたい、やるべきことを明確にしたい方 品質管理担当者：すべてのタスクが確実に完了したことを確認し、実装漏れを防ぎたい方 スタートアップやアジャイルチーム：短い周期で機能開発を進める際に、計画と進捗の両方を効率的に管理したい方 このスキルは3つの主要な使用タイミングを定義しています。作業計画時は、docs/ フォルダ内の永続ドキュメント（product-requirements.md、functional-design.md、architecture.md、repository-structure.md、development-guidelines.md）を読み込み、プロジェクト方針を理解した上で、.steering/[YYYYMMDD]-[機能名]/ 形式のディレクトリを作成し、テンプレートから requirements.md、design.md、tasklist.md を生成します。実装時が最重要モードで、tasklist.md を常に開いた状態を維持し、タスク開始時に [ ] を [x] に、完了時にもEditツールで記録することを必須とします。複数タスクをまとめて更新することや、tasklist.md を見ずに実装することは禁止です。タスク完全完了の原則として、全タスクが完了するまで作業を継続することを絶対とし、「時間の都合により」「別タスクとして実施予定」などの理由でのスキップを禁止しています。ただし技術的理由（実装方針変更、アーキテクチャ変更など）に該当する場合のみ、理由を明記してスキップが許可されます。大きすぎるタスクは自動的にサブタスクに分割し、tasklist.md に追加して対応します。

アイデアの壁打ちから始まり、初期要求仕様(docs/ideas/initial-requirements.md)をもとに高品質なPRDを段階的に生成できます。 Mermaid図解による視覚的な説明、ユーザーストーリー、優先度分類（P0/P1/P2）など、実装チームが実際に動くために必要な詳細情報をすべて記載した要件定義書を自動生成します。 AIレビュー（プロダクトビジョンの明確性、ターゲットユーザーの具体性、成功指標の測定可能性など5つの観点）を組み込み、品質の低い要件を検出・改善できます。 既存PRDがある場合は、それを優先して参考にしながら更新・拡張できます。 具体性と測定可能性の基準に基づいてレビュー→改善→再レビューのサイクルを自動化します。 プロダクトマネージャーや企画担当者で、漠然としたアイデアを実装可能な要件定義書に変える必要がある方 スタートアップや新規プロジェクトの立ち上げで、短期間に質の高い要件定義を作る必要がある方 エンジニアチームへの要件説明書を体系的に作りたい方 「プロダクトビジョン」「ユーザー中心設計」「測定可能な成功指標」を意識した要件定義を学びたい方 このスキルは、高品質なプロダクト要求定義書(PRD)作成のための詳細ガイドとテンプレートを提供します。前提条件として、ユーザーがClaude Codeとの対話を通じてアイデアのブラッシュアップを完了し、その内容をdocs/ideas/initial-requirements.mdに保存していることが必要です。PRD作成プロセスは以下で構成されます：(1)initial-requirements.mdの確認、(2)テンプレートに従ったPRDドラフト生成、(3)5つの観点（ビジョンの明確性、ユーザーの具体性、成功指標の測定可能性、機能要件の詳細度、非機能要件の網羅性）でのレビュー、(4)改善→再レビューサイクル。作成したPRDはdocs/product-requirements.mdに保存します。重要なポイントとして、すべての要件は具体的で測定可能であり、ユーザーストーリー形式「[ユーザー]として、[目的]のために、[機能]が欲しい」に従い、P0(MVP必須)・P1(初期リリース後)・P2(将来検討)の優先度を設定します。既存PRDがある場合はそれを最優先し、このガイドは補足資料として参考にしてください。

PRD（製品要件書）と機能設計書の要件を技術的に実現するシステム構造を自動生成できます。 テクノロジースタック（使用する技術・ツール・言語）の選定と理由付けができます。 既存のアーキテクチャ設計書がある場合、その構造を維持しながら更新・改善できます。 アーキテクチャ設計書のテンプレートとガイドに従い、品質の高い設計ドキュメントを作成できます。 システムの技術構成を決める必要があるプロジェクトマネージャーやリーダー 新しいプロジェクトで最初のアーキテクチャ設計書を作成する必要がある技術責任者 既存プロジェクトのアーキテクチャを整理し直す必要がある開発チーム 複雑なシステムを設計するときに、標準的な手順やベストプラクティスを参考にしたい人 このスキルは以下の流れでアーキテクチャ設計書を作成します。前提条件として、docs/product-requirements.md（PRD）とdocs/functional-design.md（機能設計書）を確認してから開始します。アーキテクチャ設計は、PRDの要件と機能設計を技術的に実現するためのシステム構造とテクノロジースタックを定義します。優先順位として、既存のdocs/architecture.mdがある場合はそれを最優先し、このスキルのガイドはあくまで補足資料として使用します。新規作成時はテンプレートとガイド（./guide.md、./template.md）を参照してください。出力先はdocs/architecture.mdに統一します。

プロジェクト固有の用語と技術用語を体系的に定義し、チーム全体で共通理解を作れます。 製品要件書、機能設計書、アーキテクチャ設計書など複数のドキュメントから用語を自動抽出して整理できます。 既存の用語集がある場合は優先順位（既存 > ガイド）に従い、一貫性を保ちながら更新・拡張できます。 テンプレートと詳細ガイドに従うだけで、統一フォーマットの用語集が作成できます。 プロジェクトマネージャーやPO：チーム内の用語の統一により、認識ズレを防ぎたい方 新しいチームメンバー：プロジェクト固有の用語を素早く学びたい方 ドキュメント管理者：複数ドキュメント間の用語の一貫性を保ちたい方 エンジニア・デザイナー：技術用語とビジネス用語を整理して開発効率を上げたい方 前提条件として、docs/product-requirements.md（PRD）、docs/functional-design.md（機能設計書）、docs/architecture.md（アーキテクチャ設計書）、docs/repository-structure.md（リポジトリ構造）、docs/development-guidelines.md（開発ガイドライン）を確認します。用語集は全てのドキュメントで使用される用語を統一的に定義し、各ドキュメントから用語を抽出して体系的に整理します。既存の用語集（docs/glossary.md）がある場合は最優先とし、このスキルのガイドは参考資料として使用します。新規作成時はテンプレート（./template.md）とガイド（./guide.md）を参照し、出力先はdocs/glossary.mdです。

PRD（製品要件書）の技術的な実装方法を詳細な設計書として作成できます。 プロジェクト固有の既存設計書がある場合、それを優先して参考にしながら新規作成・更新ができます。 汎用的なテンプレートと詳細ガイドに従い、一貫性のある機能設計書を生成できます。 作成した設計書を docs/functional-design.md に自動保存できます。 設計書のテンプレートと作成ガイドを参照しながら、品質の高い設計ドキュメントを効率的に作成できます。 プロダクト企画から開発への手引きを明確にしたい企画・PM 要件を技術仕様として落とし込む必要がある開発リーダー チーム全体で設計の一貫性を保ちたいプロジェクト管理者 既存の設計ルールを後発メンバーに引き継ぎたい技術責任者 このスキルは、機能設計書作成時に使用する詳細ガイドです。前提として docs/product-requirements.md の存在が必須です。既存の機能設計書 docs/functional-design.md がある場合はそれを最優先で参照し、次にこのスキルのガイドを補助資料として使用します。新規作成時はスキル内のテンプレート（./template.md）と詳細ガイド（./guide.md）を参照して作成してください。作成した機能設計書は必ず docs/functional-design.md に保存し、既存の設計書を更新する際も既存の構造と内容を維持しながら追記するようにします。

アーキテクチャ設計書をもとに、プロジェクトの最適なディレクトリ構造を自動生成できます。 技術スタックに応じた標準的なフォルダ配置やファイル構成を定義でき、チーム全体で統一された構造を維持できます。 既存のリポジトリ構造定義書がある場合は優先順位に従って適切に更新・保守できます。 リポジトリ構造定義書（docs/repository-structure.md）をテンプレートとガイドに従って作成・管理できます。 プロジェクト立ち上げ時にディレクトリ構造を整理したい企画・マネージャー 技術スタックが決まったので、それに合わせたリポジトリ構造を定義したい開発リーダー チーム内でコードの場所がばらばらで、構造を統一したい開発チーム 既存プロジェクトの構造が設計書と乖離している場合に正しい構造へ戻したい方 このスキルは、リポジトリ構造定義に必要な前提条件として、PRD（docs/product-requirements.md）、機能設計書（docs/functional-design.md）、アーキテクチャ設計書（docs/architecture.md）の確認を必須としています。リポジトリ構造は、アーキテクチャ設計で決定された技術スタックとシステム構成を反映した具体的なディレクトリ構造を定義します。既存のdocs/repository-structure.mdがある場合は最優先として、スキルのガイドより優先されます。新規作成時はテンプレート（./template.md）とガイド（./guide.md）を参照し、出力先はdocs/repository-structure.mdに統一しています。

コーディング規約の整備：型定義、命名規則、関数設計など、コード実装時に必要な統一ルールを具体例付きで定義できます。 開発プロセスの標準化：Git運用、ブランチ戦略（Git Flow）、コミットメッセージ、PRプロセスなどをチーム全体で統一できます。 品質基準の明確化：テスト方針（テストピラミッド）、カバレッジ目標、コードレビュープロセスを定義し、品質を可視化できます。 新規開発時の指針：命名規則やテスト戦略、セキュリティ対策など、新規開発の際に必要な実装パターンをすぐに参照できます。 CI/CD基盤の構築支援：品質自動化やパイプライン構築の方針を定義し、継続的インテグレーション（継続的に品質をチェックする仕組み）の実装をサポートできます。 チームの開発生産性を上げたいプロジェクトマネージャーやリーダー 属人的なコード品質のばらつきを統一したいチーム全体の開発メンバー 新メンバーがすぐに開発に参加できる環境を整えたい開発チームの管理者 複数プロジェクトのコーディング規約を統一的に管理したい企業の技術統括者