Skill.md検索

ユーザーの作業指示から要件・設計・タスクの3つのドキュメントを自動生成し、.steering/ ディレクトリに整理して保存できます。 タスクリストに基づいて実装を進め、完了したタスクを逐一ドキュメント記録して進捗を可視化できます。 実装完了後に振り返りドキュメントを作成し、プロジェクトの成果・課題・学習内容を永続記録します。 複雑な機能実装を体系的に計画し、漏れなく完了させたい開発者 プロジェクトの意思決定過程や設計理由を後から参照できる形で残したい人 チーム内での作業進捗を共有可能なドキュメント形式で管理したい人 タスク完了率を追跡し、品質を保ちながら確実に納品したい人 ステアリングファイル（.steering/[YYYYMMDD]-[機能名]/）管理スキル。モード1では永続ドキュメント（product-requirements.md、functional-design.md、architecture.md、repository-structure.md、development-guidelines.md）を読んでプロジェクト方針を理解し、テンプレート（.claude/skills/steering/templates/）を参照しながらrequirements.md・design.md・tasklist.mdを生成。tasklist.mdはrequirements.mdとdesign.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の優先度設定」「ユーザー中心設計」が明記されています。

アーキテクチャ設計に基づいた、明確で保守しやすいリポジトリ構造を体系的に定義できます。 技術スタック（フロントエンド、バックエンド等）とシステム構成を反映した具体的なディレクトリ構造を設計できます。 既存のリポジトリ構造定義書がある場合は、その構造と内容を維持しながら更新・拡張できます。 テンプレートとガイドに従うことで、統一フォーマットの定義書が短時間で作成できます。 アーキテクト・技術リード：プロジェクトの技術設計をディレクトリ構造に反映させたい方 新規プロジェクトの立ち上げ担当者：スケーラブルで保守しやすい構造を最初から定義したい方 チーム全体：ファイルの位置や命名規則を統一して開発効率を上げたい方 ドキュメント管理者：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です。

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

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