Skill.md検索

PRD（docs/product-requirements.md）で定義された要件を、開発チームが実装できるレベルまで技術的に詳細化した機能設計書を作成できます。 ユーザーニーズから実装仕様への橋渡しを体系的に行い、曖昧な要件を具体的なシステム設計に変換します。 既存の機能設計書がある場合はそれを最優先で参照しながら更新・拡張でき、プロジェクト固有の設計方針を一貫して保ちます。 テンプレートと詳細ガイドに従うことで、初めての設計書作成でも品質を保証した設計書を生成できます。 作成した機能設計書をdocs/functional-design.mdに一元管理し、要件定義から実装までの透明性を確保します。 プロダクトマネージャーやシステムアーキテクト等、PRDをエンジニアが実装可能な形に翻訳する立場の方 新規プロジェクトで、要件定義から実装設計への移行をスムーズに進めたい方 複数チーム間で一貫した設計思想を保ったまま、機能設計書を段階的に詳細化したい方 プロダクト開発における「要件定義」と「実装」のギャップを埋めるドキュメントが必要な組織 高品質な機能設計書を作成するための詳細ガイドとテンプレートを提供します。前提条件として、docs/product-requirements.mdにPRDが作成されていることが必須です。機能設計書は、PRDで定義された要件を技術的に実現する方法を詳細化するドキュメントです。既存の機能設計書（docs/functional-design.md）がある場合は最優先で参照し、プロジェクト固有の設計が記載されているためこのスキルのガイドより優先します。新規作成時はテンプレートとガイドを参照し、更新時は既存設計書の構造と内容を維持しながら更新してください。作成した機能設計書はdocs/functional-design.mdに保存し、さらに詳しい作成ガイドは別ファイル（guide.md）で参照可能です。

プロジェクト固有の用語と技術用語を一元管理し、全ドキュメント間で用語の定義を統一できます。 PRD、機能設計書、アーキテクチャ設計書などから用語を自動抽出し、体系的に整理できます。 新しい用語が追加される際に、既存の用語集の構造を維持しながら更新できます。 用語集のテンプレートとガイドに従い、分かりやすく検索しやすい用語集を作成できます。 プロジェクト全体で用語の表記揺れをなくしたい技術リーダーやドキュメント管理者 複数のドキュメントが存在し、用語の定義を統一する必要がある開発チーム 新入メンバーがプロジェクト固有の用語を素早く理解できる環境を整備したい人 既存の用語集をメンテナンス・更新する必要があるプロジェクト管理者 このスキルは用語集を体系的に作成するためのガイドです。前提条件として、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/product-requirements.md（PRD）、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）を自動生成し、.steering/ ディレクトリに整理して保存できます。 作業中はタスクリストに基づいて段階的に実装を進め、完了状況をリアルタイムに記録・更新します。 実装完了後に振り返りドキュメントを作成し、プロジェクトの経過と結果を永続的に記録します。 複数の作業を同時進行管理し、進捗をドキュメントに残したい開発者 作業計画を立てた後、計画通りに確実に完了させたい人 プロジェクトの要件や設計思想を後で参照できる形で記録したい人 タスク漏れなく確実に実装を完了させ、作業の品質を保ちたい人 ステアリングファイル（.steering/[YYYYMMDD]-[機能名]/）に基づいた実装支援スキル。モード1では永続ドキュメント（product-requirements.md、functional-design.md、architecture.md等）を読んでからテンプレート（requirements.md、design.md、tasklist.md）をカスタマイズしてファイル作成。モード2の実装では tasklist.mdを常に開いた状態で進捗を管理し、タスク開始時・完了時に必ずEditツールで更新することが必須。全タスク完了が絶対原則で、未完了タスクを残したまま作業終了することを禁止。タスクスキップは技術的理由（実装方針変更・アーキテクチャ変更・依存関係変更など）のみ許可。大きすぎるタスクはサブタスクに分割して対応。

アイデア段階からPRD（プロダクト要求定義書）への段階的な移行をサポートし、初期要求ファイル（docs/ideas/initial-requirements.md）から詳細なPRDを自動生成できます。 プロダクトビジョン、ターゲットユーザー、成功指標（KPI）、機能要件、非機能要件を体系的に整理し、実装チームが即座に動き始められるレベルまで詳細化します。 レビュー機能により、曖昧な要件や測定不可能な指標を検出し、改善提案を自動提示します。複数回のレビューサイクルで品質を段階的に向上させることができます。 既存PRDと新規作成を区別した優先順位ルールに従い、プロジェクト固有の要件を保持しながら効率的に更新・拡張できます。 プロダクト企画やPM が、アイデア段階から実装可能な要件定義書まで体系的に作成したい人 チーム全体で要件の曖昧さを減らし、認識のズレを防ぎたい組織 スタートアップやチーム内で、プロダクト開発プロセスを標準化・効率化したい場合 具体性と測定可能性を備えた高品質なPRDが必要な大規模プロジェクト このスキルはPRD作成の前提条件として、①アイデアのブラッシュアップ完了、②初期要求仕様ファイル（docs/ideas/initial-requirements.md）の作成を要求します。PRD作成プロセスは、①初期要求仕様ファイルの確認、②テンプレートに従ったPRDドラフト生成、③プロダクトビジョン・ターゲットユーザー・成功指標・機能要件・非機能要件の5観点でレビュー、④指摘事項の段階的改善で構成されています。既存PRC（docs/product-requirements.md）がある場合は最優先、ない場合はテンプレート参照で新規作成します。重要なポイントとして「具体性と測定可能性」「ユーザーストーリーフォーマット」「P0/P1/P2の優先度設定」「ユーザー中心設計」が明記されています。

新機能開発の際に、要件・設計・タスクをセットで作成し、計画的に実装を進められます。ステアリングファイル（.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 に追加して対応します。

PRD（製品要件書）と機能設計書の内容をもとに、システムのアーキテクチャを技術的に実現するための設計書を作成できます。システム構造、テクノロジースタック、コンポーネント間の関係性などを整理し、エンジニア全体の共通認識を形成します。 プロジェクト固有のアーキテクチャ設計書（docs/architecture.md）が既に存在する場合、そのドキュメントを最優先として参照・更新できます。既存設計書の構造と内容を維持しながら、新しい情報を反映させることで、プロジェクト全体の一貫性を保ちます。 スキル付属のテンプレート・ガイドを参考にしながら、汎用的なベストプラクティスをプロジェクトに適用できます。新規プロジェクトの場合はテンプレートから開始し、既存プロジェクトの場合は補足資料として活用できます。 アーキテクト・テックリード：システム全体の構造設計を担当し、技術選定の根拠をドキュメント化したい方 開発チーム：プロジェクトのアーキテクチャ方針を明確に理解し、統一された実装を進めたい方 新規プロジェクト立ち上げメンバー：ゼロからアーキテクチャを設計し、設計書を作成・共有したい方 このスキルは、アーキテクチャ設計を開始する前に必須ドキュメント（docs/product-requirements.md と docs/functional-design.md）の確認を要求しています。既存のアーキテクチャ設計書がある場合、docs/architecture.md を最優先として扱い、このスキルのガイドより優先することを明記しており、プロジェクト固有の技術選定と設計の一貫性を維持します。新規作成時はスキルのテンプレートとガイド（./guide.md と ./template.md）を参照し、出力先は docs/architecture.md に統一されています。既存設計書を更新する場合でも、その構造と内容を維持しながら補足・修正を加える方式を推奨しています。

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