# フェーズ8: プロジェクトフォルダ構造とファイル命名規約

このフェーズは案件着手時の最初に確認する。
構造を後から整理しようとすると必ず散らかる。**最初に切る**のが鉄則。

---

## 1. 推奨配置場所

プロジェクトフォルダの配置先はユーザーの環境に合わせて決定する。以下は参考例。

### 講座受講者・継続支援案件
```
{ルートフォルダ}/{受講者名}/01_NEXT_STRATEGY/{YYYYMMDD}_{slug}/
```

### 企業案件（一発もの）
```
{ルートフォルダ}/{YYYYMMDD}_{企業名}_{slug}/
```

### サンプル・営業用モック
```
{ルートフォルダ}/{YYYYMMDD}_{slug}_samples/
```

---

## 2. プロジェクトフォルダの標準構造

```
{プロジェクトルート}/
├── 00_BRIEF/
│   ├── brand_analysis.md              ← フェーズ1の成果物
│   ├── title_and_format_plan.md       ← フェーズ2の成果物
│   └── project_handoff_{YYYYMMDD}.md  ← セッション切れ対策の引継ぎ書
├── 01_SCRIPTS/
│   ├── script_draft_01_{slug}.md
│   ├── script_draft_02_{slug}.md
│   └── script_draft_03_{slug}.md
├── 02_PROMPTS/
│   ├── character_prompt_set.md
│   ├── character_prompt_variants.md   ← 派生版が必要な場合のみ
│   ├── grok_prompt_draft_01_{slug}.md
│   ├── grok_prompt_draft_02_{slug}.md
│   └── grok_prompt_draft_03_{slug}.md
├── 03_ASSETS/
│   ├── required_image_set_checklist.md
│   ├── image_prompt_set_01_{slug}.md
│   ├── image_prompt_set_02_{slug}.md
│   ├── top_banner_prompt_01_{slug}.md
│   ├── bottom_banner_prompt_01_{slug}.md
│   ├── char_face_front.png
│   ├── char_twoview.png
│   ├── symbol_face_front.png
│   ├── symbol_twoview.png
│   ├── keyvisual_pair.png
│   ├── bg_01_front.png 〜 bg_04_wide.png
│   ├── top_banner_01.png
│   └── bottom_banner_01.png
└── 04_OUTPUT/
    ├── scene_01_01.mp4 〜 scene_01_07.mp4
    ├── scene_02_01.mp4 〜 scene_02_07.mp4
    ├── scene_03_01.mp4 〜 scene_03_07.mp4
    ├── master_01.mp4
    ├── master_02.mp4
    └── master_03.mp4
```

---

## 3. ファイル命名規約

### 番号体系
- **動画番号**: `01`, `02`, `03` … 採用された3本に対応
- **シーン番号**: `01`, `02` … `07` … 台本のScene番号
- **アセット番号**: `01`, `02` … 同種類内の連番

### スラグ
- 英数字小文字 + アンダースコア
- 動画タイトルの核心を3〜5語で
- 例: `next_5_years` / `market_value` / `hero_brand_call`

### 背景ファイル名
- 形式A: `bg_01_front.png` / `bg_02_angle.png` / `bg_03_close.png` / `bg_04_wide.png`
- 形式B: `bg_01_vertical_front.png` / `bg_02_vertical_angle.png` / etc.
- 形式C: `bg_hero_abstract.png`

### 強フック派生
- 通常版とは明確に分けて命名
- 例: `char_armor_twoview.png` / `keyvisual_riding_dynamic.png`

---

## 4. 引継ぎ書（project_handoff）の役割

セッションが切れても次の作業者（Claude含む）が即座に再開できるように作る。
作成日と進捗状態を必ず明記。

### 必須項目
1. プロジェクトの目的（何を実証するための制作か）
2. 戦略的な前提（どのレイヤーで攻めているか）
3. 確定している動画N本のタイトルと形式
4. 登場キャラクター設計
5. キャラクター・記号アセット方針
6. 背景アセット方針
7. 上下バナーのルール
8. 作成済みファイル一覧
9. 直近で修正・確定したこと（タイムスタンプ付き）
10. 今後HTMLや提案資料に載せるべき戦略ポイント
11. いま次にやるべきこと（Next Action）

---

## 5. ファイル更新のルール

エージェントの基本ルールに従う:
- ファイル変更は**エディタ系ツールのみ**で行う
- ターミナルでの `echo >` `sed` `mv` 等での編集は禁止
- ファイル移動・複製・削除もエディタまたは適切なAPI経由で

エージェントの基本ルールに従う:
- 「前略」「中略」での省略禁止
- 存在しないパス・架空のAPIを書かない
- 不明な情報はユーザーに確認

---

## 6. 完了時のクリーンアップ

納品が終わったら以下を整理:

- 採用されなかった生成候補は別フォルダ `99_REJECTED/` に退避（即削除しない、再利用可能性あり）
- マスター動画は `04_OUTPUT/` 直下に置き、シーン断片は `04_OUTPUT/scenes/` に移す
- 引継ぎ書を最終版に更新し、「完了」マークを付ける
- スキル化・教材化に再利用できる学びがあれば、本スキルの該当フェーズMDに追記提案を出す

---

## 7. 講座受講者案件の場合の追加配慮

講座受講者のプロジェクト配下の案件は、サポート期間が終わっても引き継ぎ可能な状態を保つ:

- `02_HISTORY_LOG/` にレクチャー記録を残す
- `03_ASSETS/_session.md` にセッション情報を残す
- 引継ぎ書は受講者にも共有可能な日本語で書く

---

## 8. このスキル自体の改善ループ

新しい案件で発見した知見は、本スキルの該当フェーズMDに**追記**する。
案件が終わるたびに以下を確認:

- 新しい失敗パターンが見つかったか → 該当フェーズの「失敗パターン」節に追加
- 新しいプロンプトの型が確立したか → 該当フェーズの「テンプレート」節を更新
- 新しい事故防止ルールが必要になったか → SKILL.md の「絶対遵守ルール」を更新

ただし、ブランド固有の話題は本スキルに混ぜない（汎用化してから入れる）。

---

## 完了

ここまでで全フェーズ完了。
新規案件が来たら `SKILL.md` から再度フェーズ1を開いて始める。
