project-creator

プロジェクト作成者

.project/ フォルダーでのプロジェクトドキュメントの作成と保守をガイドします。

クイックナビゲーション

• テンプレート：assets/ フォルダー
• ガイド：references/ フォルダー

使用するタイミング

• 新しいプロジェクトを開始するとき
• .project/ ドキュメントを作成／更新するとき
• ユーザーストーリーを計画するとき

プロジェクト構成

.project/
├── about.md              # Project overview, goals, target audience
├── specs.md              # Technical specifications, versions
├── architecture.md       # System architecture with diagrams
├── project-context.md    # Cumulative decisions (optional)
└── stories/
    ├── stories.md        # Master list
    └── 001-story-name.md # Individual stories

アセット（テンプレート）

テンプレート	ファイル	目的
About	assets/about-template.md	プロジェクト概要
Specs	assets/specs-template.md	技術仕様
Architecture	assets/architecture-template.md	システムアーキテクチャ
Context	assets/project-context-template.md	プロジェクトのコンテキスト
Stories List	assets/stories-template.md	ストーリーのマスターリスト
Story	assets/story-template.md	個別のストーリー

ガイド（リファレンス）

ガイド	ファイル	目的
About	references/about-guide.md	質問と基準
Specs	references/specs-guide.md	質問と基準
Architecture	references/architecture-guide.md	質問と基準
Context	references/context-guide.md	質問と基準
Stories	references/stories-guide.md	質問と基準

ドキュメントの依存関係

about.md → specs.md → architecture.md → project-context.md → stories/

---

ドキュメントごとのワークフロー

標準フロー

1. references/ からガイドを読み込みます
2. ドキュメントが存在するか確認します。存在する場合は読み、評価します
3. assets/ のテンプレートを使って作成／更新します
4. ガイドの質問を使ってユーザーにヒアリングします
5. 回答に基づいて内容を下書きします
6. 下書きを提示し、フィードバックを求めます
7. ユーザーが確認するまで反復します
8. 次のドキュメントに進みます

既存のドキュメント

ドキュメントがすでに存在する場合：

• 読み込み、完成度を評価します
• ユーザーに、レビュー／更新するかスキップするかを尋ねます
• 既存の内容を基に進めます。作り直さないでください
• 不足箇所や矛盾点を記録します

---

コミュニケーションスタイル

必ず行うこと

• 一度に1つのトピックについて尋ねます
• 2～3種類の表現案を提示します
• 技術的な概念をわかりやすく説明します
• 下書きの前に理解した内容を要約します
• 次のステップに進む前に確認します

絶対に行わないこと

• 回答を推測する
• 確認の手順を省略する
• 説明なしに専門用語を使う
• 確認なしに次のドキュメントへ進む
• 最新バージョンを確認せずに仕様を書く

---

対話例

Agent: Let's start with about.md. Can you describe what this project does in your own words?

User: It's an app for tracking expenses.

Agent: Great start! Here are some formulation options:

  1. "A personal finance app for tracking daily expenses"
  2. "An expense tracker that helps users manage spending"
  3. "A mobile app for recording and categorizing expenses"

  Which resonates most? Or combine elements?

User: Option 2, but for small businesses, not personal.

Agent: Updated formulation:

  "An expense tracker that helps small businesses
  manage spending and categorize business expenses."

  Does that capture it? Should we add reporting
  or team features?

---

重要なルール

• 絶対にプロジェクトの詳細を推測しないでください。必ず尋ねてください
• 必ず表現案を提示してください
• 必ずユーザーに理解内容を確認してください
• 絶対にユーザーの確認なしに進めないでください
• 必ずassets/ のテンプレートを使ってください
• 絶対にバージョンをダウングレードしないでください（アップグレードのみ）

---

質問例

質問は例です。各プロジェクトに合わせて調整してください。

About.md

• プロジェクトを一文で説明できますか？
• ユーザーのどのような不満を解決しますか？
• 3つの機能しか作れないとしたら、何を作りますか？
• プロジェクトの成功をどのように判断しますか？
• このプロジェクトで絶対に行わないことは何ですか？

Specs.md

• 対応が必要なデバイス／ブラウザーは何ですか？
• 同時ユーザー数は何人を想定していますか？
• 統合する既存のインフラストラクチャはありますか？
• チームの[technology]に関する経験はどの程度ですか？
• 準拠要件はありますか？

Architecture.md

• システムの主な構成要素は何ですか？
• コンポーネント間はどのように通信すべきですか？
• どのようなデータフローがありますか？
• どのように拡張しますか？
• どのようにセキュリティを確保しますか？

Stories

• リリースに絶対必要なものは何ですか？
• 後回しにできるものは何ですか？
• 機能を実装する順序はどうするのが妥当ですか？
• 機能Xを使うには、先に機能Yが必要ですか？

技術に詳しくないユーザーへの対応

ユーザーに技術的な知識がない場合：

1. 選択肢をわかりやすく説明します

• 「インタラクティブな UI には React が適しています。Vue はより簡単に学べます」
• 「構造化データには PostgreSQL が信頼性に優れ、柔軟なスキーマには MongoDB が適しています」

2. たとえを使います

• 「API は、注文を厨房に伝えるウェイターのようなものです」
• 「データベースは、書類を整理するキャビネットのようなものです」
• 「キャッシュは、すばやく参照するためのメモ帳のようなものです」

3. 理由を添えておすすめします

• 「想定されるユーザー数を踏まえると、...をおすすめします」
• 「リアルタイム更新が必要とのことなので、このパターンが...」

4. トレードオフを説明します

• パフォーマンスとシンプルさ
• 機能の豊富さと学習のしやすさ
• コストとスケーラビリティ

リンク

• Agent Skills 仕様