開発を進めるうえで遵守すべき標準ルールを定義します。
本リポジトリは、タスク管理アプリケーション専用のリポジトリです。
アプリケーション全体の「何を作るか」「どう作るか」を定義する恒久的なドキュメント。 アプリケーションの基本設計や方針が変わらない限り更新されません。
-
product-requirements.md - プロダクト要求定義書
- プロダクトビジョンと目的
- ターゲットユーザーと課題・ニーズ
- 主要な機能一覧
- 成功の定義
- ビジネス要件
- ユーザーストーリー
- 受け入れ条件
- 機能要件
- 非機能要件
-
functional-design.md - 機能設計書
- 機能ごとのアーキテクチャ
- システム構成図
- データモデル定義(ER図含む)
- コンポーネント設計
- ユースケース図、画面遷移図、ワイヤフレーム
- API設計(将来的にバックエンドと連携する場合)
-
architecture.md - 技術仕様書
- テクノロジースタック
- 開発ツールと手法
- 技術的制約と要件
- パフォーマンス要件
-
repository-structure.md - リポジトリ構造定義書
- フォルダ・ファイル構成
- ディレクトリの役割
- ファイル配置ルール
-
development-guidelines.md - 開発ガイドライン
- コーディング規約
- 命名規則
- スタイリング規約
- テスト規約
- Git規約
-
glossary.md - ユビキタス言語定義
- ドメイン用語の定義
- ビジネス用語の定義
- UI/UX用語の定義
- 英語・日本語対応表
- コード上の命名規則
特定の開発作業における「今回何をするか」を定義する一時的なステアリングファイル。 作業完了後は参照用として保持されますが、新しい作業では新しいディレクトリを作成します。
-
requirements.md - 今回の作業の要求内容
- 変更・追加する機能の説明
- ユーザーストーリー
- 受け入れ条件
- 制約事項
-
design.md - 変更内容の設計
- 実装アプローチ
- 変更するコンポーネント
- データ構造の変更
- 影響範囲の分析
-
tasklist.md - タスクリスト
- 具体的な実装タスク
- タスクの進捗状況
- 完了条件
.steering/[YYYYMMDD]-[開発タイトル]/
例:
.steering/20250103-initial-implementation/.steering/20250115-add-tag-feature/.steering/20250120-fix-filter-bug/.steering/20250201-improve-performance/
mkdir -p docs
mkdir -p .steeringアプリケーション全体の設計を定義します。 各ドキュメントを作成後、必ず確認・承認を得てから次に進みます。
docs/product-requirements.md- プロダクト要求定義書docs/functional-design.md- 機能設計書docs/architecture.md- 技術仕様書docs/repository-structure.md- リポジトリ構造定義書docs/development-guidelines.md- 開発ガイドラインdocs/glossary.md- ユビキタス言語定義
重要: 1ファイルごとに作成後、必ず確認・承認を得てから次のファイル作成を行う
初回実装用のディレクトリを作成し、実装に必要なドキュメントを配置します。
mkdir -p .steering/[YYYYMMDD]-initial-implementation作成するドキュメント:
.steering/[YYYYMMDD]-initial-implementation/requirements.md- 初回実装の要求.steering/[YYYYMMDD]-initial-implementation/design.md- 実装設計.steering/[YYYYMMDD]-initial-implementation/tasklist.md- 実装タスク
.steering/[YYYYMMDD]-initial-implementation/tasklist.md に基づいて実装を進めます。
- 永続的ドキュメント(
docs/)への影響を確認 - 変更が基本設計に影響する場合は
docs/を更新
新しい作業用のディレクトリを作成します。
mkdir -p .steering/[YYYYMMDD]-[開発タイトル]例:
mkdir -p .steering/20250115-add-tag-feature作業単位のドキュメントを作成します。 各ドキュメント作成後、必ず確認・承認を得てから次に進みます。
.steering/[YYYYMMDD]-[開発タイトル]/requirements.md- 要求内容.steering/[YYYYMMDD]-[開発タイトル]/design.md- 設計.steering/[YYYYMMDD]-[開発タイトル]/tasklist.md- タスクリスト
重要: 1ファイルごとに作成後、必ず確認・承認を得てから次のファイル作成を行う
変更が基本設計に影響する場合、該当する docs/ 内のドキュメントを更新します。
.steering/[YYYYMMDD]-[開発タイトル]/tasklist.md に基づいて実装を進めます。
- アプリケーションの基本設計を記述
- 頻繁に更新されない
- 大きな設計変更時のみ更新
- プロジェクト全体の「北極星」として機能
- 特定の作業・変更に特化
- 作業ごとに新しいディレクトリを作成
- 作業完了後は履歴として保持
- 変更の意図と経緯を記録
設計図やダイアグラムは、関連する永続的ドキュメント内に直接記載します。 独立したdiagramsフォルダは作成せず、手間を最小限に抑えます。
配置例:
- ER図、データモデル図 →
functional-design.md内に記載 - ユースケース図 →
functional-design.mdまたはproduct-requirements.md内に記載 - 画面遷移図、ワイヤフレーム →
functional-design.md内に記載 - システム構成図 →
functional-design.mdまたはarchitecture.md内に記載
- Mermaid記法(推奨)
- Markdownに直接埋め込める
- バージョン管理が容易
- ツール不要で編集可能
graph TD
A[ユーザー] --> B[タスク作成]
B --> C[タスク一覧]
C --> D[タスク編集]
C --> E[タスク削除]
- ASCII アート
- シンプルな図表に使用
- テキストエディタで編集可能
┌─────────────┐
│ Header │
└─────────────┘
│
↓
┌─────────────┐
│ Task List │
└─────────────┘
- 画像ファイル(必要な場合のみ)
- 複雑なワイヤフレームやモックアップ
docs/images/フォルダに配置- PNG または SVG 形式を推奨
- 設計変更時は対応する図表も同時に更新
- 図表とコードの乖離を防ぐ
- ドキュメントの作成・更新は段階的に行い、各段階で承認を得る
.steering/のディレクトリ名は日付と開発タイトルで明確に識別できるようにする- 永続的ドキュメントと作業単位のドキュメントを混同しない
- コード変更後は必ずリント・型チェックを実施する
- 共通のデザインシステム(Tailwind CSS)を使用して統一感を保つ
- セキュリティを考慮したコーディング(XSS対策、入力バリデーションなど)
- 図表は必要最小限に留め、メンテナンスコストを抑える