---
name: set-md
description: "Use when: /set-md を実行してサイトのドキュメント（AGENTS.md / agent_docs/*.md / README.md）をゼロから生成・更新したいとき。サイト構造を自動解析し、AIエージェントが効率よく作業するためのコンテキスト情報をMDにまとめる。WP / フォーム / 静的HTMLサイト（LP集合体）の3パターンに対応。GTMクリック計測（data-gtm-click）の命名規則も自動抽出してMDに保存する。"
version: "1.6.0"
---

# set-md

`/set-md` で実行するドキュメント生成スキル。

## 役割

サイト（リポジトリ）の構造を解析し、以下のドキュメントを生成・更新する。

| 生成ファイル                      | 用途                                                                                           |
| --------------------------------- | ---------------------------------------------------------------------------------------------- |
| `AGENTS.md`                       | AIエージェント共通のコンテキスト情報（必ず生成）                                               |
| `.claude/agent_docs/wordpress.md` | WordPress作業ガイド（WP検出時）                                                                |
| `.claude/agent_docs/forms.md`     | フォームフレームワーク作業ガイド（フォーム検出時）                                             |
| `.claude/agent_docs/[section].md` | 独立した仕様を持つセクション（必要数だけ）                                                     |
| `README.md`                       | GitHub向けプロジェクト概要（既存がなければ生成、あれば更新提案。実用的に整備済みなら触らない） |

**前提となる設計思想：**

- `AGENTS.md` は「どのAIツールでも読める」共通仕様書。最小限のコンテキストに絞り、詳細は supplementary docs へ委譲する
- `agent_docs/*.md` は「当該領域に触る直前にだけ読む」専門文書。過剰な総論は書かない
- `README.md` は「人間がGitHubのリポジトリページで最初に読む」文書。AIコンテキストとは目的が異なる
- **各 MD は AI が「いつ読むべきか」を一発判定できるように、YAML frontmatter で `name` / `description` / `when_to_use` を明示する**（v1.3.0〜）

---

## AI 向け MD のベストプラクティス（v1.3.0 で追加）

生成する各 MD は以下のベストプラクティスに沿って書く。AI がバイブコーディングで流用しやすい形にすることが目的。

| ベスプラ                                                                   | 効果                                            |
| -------------------------------------------------------------------------- | ----------------------------------------------- |
| **YAML frontmatter（`name` / `description` / `when_to_use`）を先頭に置く** | AI が「いつこの MD を読むべきか」を判定しやすい |
| **TL;DR を冒頭に 3〜5 行**                                                 | 全体把握が瞬時にできる                          |
| **スニペット集を含める**                                                   | コピペ可能なコード断片で実装が安定する          |
| **「やる ✅ / やらない ❌」対比表**                                        | グレーゾーンが減る                              |
| **具体的なファイルパスと変数名を使う**                                     | 抽象的な表現は AI が誤解する                    |
| **セクション順序を統一**                                                   | 複数 agent_doc を渡り歩く AI の認知負荷を減らす |

統一セクション順序（agent_doc）：

```
1. YAML frontmatter
2. TL;DR
3. 対象範囲
4. ファイル構成
5. コーディング規約（ブレイクポイント / カラー / 命名 / JS方針 / やる×やらない）
6. スニペット集
7. 触る前に確認すること
8. よくある作業の入口
9. 既知の落とし穴（空でも置く。後から埋める前提）
```

---

## 実行フロー概要

```
Step 1: 自動解析（並列）
  └─ 1-a〜1-h の全項目を並列で調査
  └─ AGENTS.md / agent_docs/*.md が存在すれば Read して内容を把握

Step 2: ヒアリング（AskUserQuestion）
  └─ 既存ファイルがある場合 → 衝突確認（上書き or 差分）を質問に含める
  └─ クロスプロジェクト混入が疑われる場合は特に強調
  └─ Step 1 で取得済みの情報（URL・デプロイ先等）はスキップ

Step 3: ドキュメント生成
  └─ 上書き対象ファイルを事前に並列 Read してから Write
  └─ frontmatter / TL;DR / スニペット集を必ず含める

Step 4: 完了報告
```

---

## 実行フロー

### Step 1. 自動解析

以下をすべて並列で調査する（Read / Glob / Grep を使う）。

#### 1-a. プロジェクト基本情報

- プロジェクトルートの一覧（`Glob: /*` で直下ディレクトリを把握）
- `AGENTS.md` が存在すれば Read する（**クロスプロジェクト混入確認のため**）
- `.claude/agent_docs/` 配下のファイル一覧を確認する
- `README.md` が存在すれば読む（URL、ブランチルール、環境情報を抽出）
- `.github/workflows/*.yml` を確認（CI/CDの有無・デプロイ先）
- `package.json` / `composer.json` の有無を確認（ビルドツール・依存関係）
- `.editorconfig` / `.gitignore` を確認（開発スタイル）

**クロスプロジェクト混入の判定（重要）**:

- AGENTS.md のプロジェクト名（タイトルや本文に出現するサイト名）と、ディレクトリ名 / README のプロジェクト名が **一致しない場合**は混入の可能性が高い
- 例: ディレクトリ名が `stg-alpha` なのに AGENTS.md が別サイト名になっている → 別プロジェクトのコピペ
- Step 2 のヒアリングで「全上書きするか」を必ず確認

#### 1-b. WordPress の検出

**まず `Glob: **/wp-load.php` で全体検索する\*\*（最も確実）。複数ヒットした場合は複数の WP インストールがある。

以下のいずれかが存在すれば WordPress あり：

- `**/wp-load.php`（最優先で検索）
- `wp-config.php`（またはそれに類する config ファイル）
- `wp-blog-header.php`（ルートまたはサブディレクトリ）

> **注意**: `wp-content/` という名前以外（`wp-content-custom/`, `wp-content-sub/` 等）でも WP は動く。Glob より `wp-load.php` で探す方が確実。

検出した場合（インストールごとに調べる）：

- WordPress のルートディレクトリ名（`wordpress/`, `wp/`, `cms/` 等）
- wp-content のディレクトリ名（標準の `wp-content/` か非標準名か）
- テーマディレクトリ名
- `functions.php` または `functions/` ディレクトリの構造
- 使用プラグイン一覧（`wp-content*/plugins/` の直下ディレクトリ）
- テーブルプレフィックス（`wp-config.php` があれば `$table_prefix` の値）
- **複数インストールの場合**: それぞれの用途の違いを把握する

#### 1-c. フォームフレームワークの検出

以下のパターンを確認：

**パターンA — プロジェクト内にフォーム処理一式を持つ型**

- `[フォームルート]/base.php` または類似の一元管理ファイルが存在する
- `input.php` / `confirm.php` / `complete.php` がフレームワーク内に存在する

**パターンB — 複数フォームが共有ライブラリを使う型**

- `[共有フォームライブラリ]/` に共通関数・入力・確認・完了処理がまとまっている
- 各フォームのエントリーポイントがこの共有ライブラリを `require_once` で参照する
- 同じフレームワークが複数箇所に独立コピーとして存在することがある

**パターンC — 外部サービス（Google Forms / HubSpot 等）**

- フォーム処理 PHP が存在せず、外部サービスへの埋め込みのみ

**パターンD — フォーム無し**

- そもそも問い合わせフォームがない静的サイト

いずれも：各フォームのフィールド定義（config.php 等）があれば読んでおく。

#### 1-d. PHP 共通パーツの検出

- `assets/includes/` / `inc/` / `common/` 等に共通 PHP パーツがあるか確認
- `head.php` / `g-header.php` / `g-footer.php` 等の include 構造を把握
- 独自のキャッシュバスト関数の有無と定義場所を確認
- **PHP が使えない静的サイト**の場合：JS で共通要素を生成しているか確認（`data-*` 属性マーカーや `document.querySelector` で挿入するパターン）

#### 1-e. CSS・JS ビルド環境の検出

**Glob でサブディレクトリも含めて検索する**（ビルド設定がサブディレクトリに分離されていることがある）：

- `**/gulpfile.js` → Gulp（ルート以外のツール用ディレクトリに置かれる場合もある）
- `**/webpack.config.js` → Webpack
- `**/vite.config.*` → Vite
- `**/prepros.config` → Prepros（GUI ツール）
- ヒットしたディレクトリの `package.json` を読んで `scripts` とビルド対象を確認
- SCSS / Sass のソースディレクトリと出力先を確認

**ビルドツール名を MD に書くかどうか**:

- ユーザーが「ツール名を書かないで」と要望する場合がある（プロジェクトメンバー間でツールが揃っていない、または `gitignore` 対象になっている）
- その場合は「SCSS → CSS のローカルビルド」のような **ツール非依存な表現**にする
- Step 2 のヒアリングで確認するのが安全

#### 1-f. 静的 HTML サイト・LP 集合体の検出（v1.3.0 で追加）

WP もフォームも無い「**静的 HTML サイト**」「**複数 LP の集合体**」パターンを検出する：

- ルート直下のディレクトリに `index.html` + `assets/` が独立して並んでいる
- PHP ファイルが存在しないか、存在しても include 構造を持たない
- 各ディレクトリが独立した HTML / CSS / JS リソースを持つ（共通テンプレ無し）

このパターンの場合、各 LP は **独立した agent_doc 候補**になる。判別ポイント：

- LP 単位でディレクトリが切られている（例: `products/service-a/`、`campaign/summer/`）
- LP 固有の `assets/css/sass/` または `assets/css/` を持つ
- LP 固有の JS（`assets/js/`）を持つ
- 複数 LP が同じディレクトリで共通リソースを共有する場合は、同一カテゴリ単位で 1 つの agent_doc にまとめる判断もある

#### 1-g. HTML / CSS / JS 実コードのサンプリング解析（v1.3.0 で追加）

各 LP / 主要セクションについて、代表ファイルを並列 Read して**書き方の特徴**を抽出する：

| 抽出項目                                      | 取得元の例                                                                | 類す |
| --------------------------------------------- | ------------------------------------------------------------------------- | ---- |
| **ブレイクポイント**                          | SCSS の `@media (min-width:[N]px)`                                        |
| **メインカラー（カスタムプロパティ）**        | `:root { --main-color: ... }`                                             |
| **フォント**                                  | `<head>` の `<link rel="stylesheet">`（Typekit / Google Fonts）           |
| **JS のスタイル**                             | `<script type="module">` の有無、`import` 文、jQuery 使用、IIFE / defer   |
| **クラス命名規則**                            | `mod_` / `c-` / `state_` / `js-` 等の接頭辞傾向                           |
| **共通要素生成方式**                          | `data-*` 属性マーカー、JS による動的注入                                  |
| **GTM / 計測タグ**                            | `<script>...GTM-XXXX...` の存在                                           |
| **クリック計測の命名パターン（v1.4.0 追加）** | `data-gtm-click="[xxx]"` の値を全件抽出してプレフィックス・連番方式を分析 |
| **特徴的なカスタム属性**                      | `data-component`, `data-modal`, `data-gtm-click` 等                       |
| **CSS-only パターン**                         | `<input type="checkbox">` + `<label>` のドロワー等                        |
| **電話リンク無効化方式**                      | `@media (hover)` vs `@media (min-width:...)`                              |

**クリック計測命名パターンの抽出方法（v1.4.0）**:

各 LP / セクションで以下のように Grep して、命名規則を分る：

```
Grep pattern='data-gtm-click="([^"]+)"' path='[LPパス]/' output_mode='content'
```

抽出した値から以下を分析：

- **プレフィックス**: `[エリア名]-header-N` のエリア別 / `[商品名]-N` の商品別 / `[LP名]-N` の通し連番 など
- **連番管理**: 通し番号 / エリア別連番 / カテゴリ別連番
- **混在パターン**: コピペで残った別 LP の値、期間限定キャンペーンの別プレフィックス
- **未使用**: そのセクションで `data-gtm-click` が一切使われていないか

→ MD には**現状の最大番号は書かない**（古くなる）。代わりに「**新規追加時に Grep で最大番号を確認するコマンド**」を載せる。

サンプリング対象（代表的なもの 1〜2 ファイル/LP）：

- 各 LP の `index.html`
- 各 LP の `common.scss` / `common.css` / `_common.css`
- 各 LP の `common.js` / `_common.js`

得られた情報は **AGENTS.md のコーディング規約セクション**と **各 agent_doc のコーディング規約セクション**に反映する。

#### 1-h. 独立したセクション（サブシステム）の検出

以下の条件を**2つ以上**満たすディレクトリは「独自 agent_doc が必要な候補」：

1. 独自の `_config/config.php`（フォームフィールド定義）を持つ
2. 独自の `confirm.php` + `complete.php`（または `fin.php`）を持つ
3. 独自の CSS ファイル/SCSS ソースを持つ
4. 独自の JS / 設定を持つ
5. 独自の CMS / DB 接続設定を持つ
6. ルートとは異なる WordPress インストールを持つ（サブディレクトリ WP）
7. **独立した LP として完結している**（独自の HTML + assets/）
8. **LP 固有のメインカラー・ブレイクポイント・JS方針を持つ**（v1.3.0 追加）

---

### Step 2. ヒアリング（AskUserQuestion）

自動解析の結果を簡潔に提示してから AskUserQuestion で確認する。
**一度に3〜4問まで。多すぎると選びにくいので分割する。**

> **スキップルール**: Step 1 で取得できた情報（URL・デプロイ先など）は聞かない。

#### 既存ファイルの扱い（AGENTS.md / agent_docs が存在する場合のみ）

以下のどちらかを第1問として追加する：

- **クロスプロジェクト混入が疑われる場合**（プロジェクト概要が異なる）:

  > 「AGENTS.md が別プロジェクト（〇〇）のドキュメントになっています。全上書きしてこのプロジェクト向けに作り直しますか？」

- **同プロジェクトの更新の場合**:
  > 「AGENTS.md がすでにあります。上書きしますか？それとも差分だけ追加しますか？」

**AGENTS.md / agent_docs が存在しない場合（新規プロジェクト）**: この確認はスキップして次へ進む。

#### 第1ラウンド（Step 1 で取得できなかった情報のみ）

以下のうち、Step 1 で判明しなかったものだけを聞く：

1. **デプロイ方法**（`.github/workflows/` や README から判明していれば不要）
2. **本番 URL**（README.md から取得済みなら不要）
3. **テスト環境 URL**（同上）
4. **WordPress 管理画面のパス**（WP 検出時のみ）
5. **ビルドツール名を MD に書くか**（Prepros 等の場合、ツール名出力の可否を確認）

#### 第2ラウンド（必要な場合のみ）

セクション候補があれば、それぞれを agent_doc に分けるか確認する。

**静的サイト・LP 集合体の場合（v1.3.0 追加）**:

- LP の分類（どれを独立 agent_doc にするか、どれをまとめるか）を確認
- 複数 LP に共通リソースがある場合（同一 `assets/css/sass/` を共有）、まとめて 1 つの agent_doc にするか提案

> 「以下の LP が見つかりました。それぞれ agent_doc を作りますか？（複数選択可）」

#### 追加ヒアリング（任意）

- 特記すべき既知バグ・落とし穴はあるか（**「後で個別に教える」の選択肢を必ず用意**して、初回はスキップできるようにする）
- 検収検証で必須のコーディングルール（電話リンク無効化・特殊文字エスケープ・alt 設定など）があるか
- フォームの送信先メールアドレス管理の方針（記載する / しない）
- 今後よく触りそうな領域はどこか

---

### Step 3. ドキュメント生成

解析結果とヒアリング内容を統合して、以下のファイルを生成する。

> **⚠️ Claude Code の制約 — Write 前に Read 必須**: 既存ファイルを上書きする場合は Write の前に必ず Read すること。Read なしで Write するとエラーになる。新規ファイルは Read 不要。上書き対象が複数ある場合は事前に並列 Read してまとめておくこと。

**新規 vs 上書きの判断**:

- AGENTS.md が存在しない → `Write` で新規作成（Read 不要）
- AGENTS.md が存在する → `Read` してから `Write` で上書き
- agent_docs/xxx.md が存在しない → `Write` で新規作成（Read 不要）
- agent_docs/xxx.md が存在する → `Read` してから `Write` で上書き
- README.md が存在しない → `Write` で新規作成（Read 不要）
- README.md が存在する → **既存内容を読んだうえで判断**:
  - 実用的に整備されている（本番URL / FTP情報 / ディレクトリ構成等が揃っている）→ **触らない**
  - 不足や齟齬がある → 更新提案を出す（直接上書きはしない）

**不要になった旧 agent_docs の処理**:
上書き後に AGENTS.md から参照されなくなったファイルは、ファイル内容を以下に書き換える（削除は完了報告のチェックリストに記載してユーザーに委ねる）：

```markdown
# このファイルは旧プロジェクト用のドキュメントです

削除して問題ありません。
```

#### 3-a. `AGENTS.md`（最重要）

**構成テンプレート（v1.3.0）：**

```markdown
---
name: agents-[プロジェクト識別子]
description:
  [
    サイトの種別と特徴を1〜2行で。WP有無、フォーム有無、PHP可否、CSS方針、独立LP構成など、AIが最初に知るべき判断材料を含める,
  ]
when_to_use: このリポジトリで作業を始めるとき / プロジェクト全体の方針・行動原則・コーディング規約を参照したいとき / どの agent_doc を読むべきか判断したいとき
---

# [プロジェクト名] エージェント運用ガイド

## TL;DR

- [サイトの一行要約]
- [技術的特徴1: WP / フォーム / 静的サイトのいずれか]
- [技術的特徴2: CSS方針、PHP可否など]
- [触る前の最重要注意1〜2件]

## サイト構成（俯瞰）

[ツリー形式。各行に用途コメントを添える]

## どの agent_doc を読むか

[編集対象ディレクトリ → 対応する agent_doc の早見表]

## 技術スタック

- **サーバー**: [Apache / Nginx 等]
- **CMS**: [WordPress x.x / なし]
- **DB**: [MySQL / PostgreSQL / なし]
- **言語**: [PHP の可否含む]
- **CSS**: [SCSS の有無、ビルド方針]
- **JS**: [バニラ / React / Vue 等、jQuery 有無]
- **画像**: [WebP の可否含む]
- **デプロイ**: [FTP手動 / GitHub Actions 等]

## 行動原則（最重要）

1. **[プロジェクト固有の最重要ルール]**
2. **本番影響を伴う操作は事前確認**
3. **既存スタイルに合わせる**
4. **不要なリファクタを混ぜない**
5. **ファイル新規作成は最小限**
6. **秘密情報を出力に含めない**
   [プロジェクト固有のルールを追加]

## コーディング規約（全 LP / 全ページ共通）

[Step 1-g で抽出した実コードの規約]

### ブレイクポイント早見表

[LP ごとのブレイクポイント表]

### クラス命名規則

[接頭辞 表]

### やる ✅ / やらない ❌

[CSS編集 / 共通要素 / 電話リンク / 画像 / 色指定 / JS 等の対比表]

## スニペット集（全 LP / 全ページ共通）

[コピペ可能なコード断片。`<head>`定型・フォント読込・電話リンク CSS・レスポンシブ画像・GTM計測・YouTube・特殊文字エスケープ・SCSSリセット など]

### GTM クリック計測（data-gtm-click）の共通ルール

以下を必ず含める（v1.4.0 追加・絶対ルール）：

1. **既存の値は絶対に変えない**（計測の連続性が壊れる）
2. **ボタン要素・リンク要素**に付ける（装飾要素には付けない）
3. **新規追加時は、その LP の既存の最大番号 +1 から振る**（連番継続）
4. **命名パターンは LP ごとに違う**ので、対応する agent_doc を参照する
5. 新規追加前に Grep で最大番号を確認するコマンド例を載せる

## 構築時のコーディングルール（検証項目対応）

[検収検証チェックリストに対応する構築時ルール。プロジェクトに該当する項目だけ書く]

### 電話番号リンク（PC ではリンク無効化）

### alt 属性

### HTML 構文エラーをゼロにする

### 特殊文字はエスケープする

### クロスブラウザ対応

## ブランチ運用とデプロイ

[既存 README / .github/workflows から抽出]

## 補助ドキュメント（agent_docs）

[生成した agent_docs へのリンク一覧]
```

**記載ガイドライン：**

- AGENTS.md には「どこを見れば何がわかるか」を書き、実装詳細は agent_docs に委ねる
- ディレクトリ構造は把握に必要な粒度にとどめ、画像ファイル一覧などは省く
- 行動原則は抽象的にならず、具体的なファイル名・変数名を含める
- スニペット集は **全 LP / 全ページに共通する**ものに絞る（個別 LP のスニペットは各 agent_doc に書く）

#### 3-b. `.claude/agent_docs/wordpress.md`（WordPress 検出時）

**構成テンプレート：**

```markdown
---
name: wordpress
description: [サイト名] の WordPress（[WP パス]）とテーマ [テーマ名] の作業ガイド。[特徴を1行]
when_to_use: [WP パス] 配下のファイルを編集するとき / カスタム投稿タイプ・タクソノミーを変更するとき / プラグインを追加・更新するとき
---

# WordPress 作業ガイド

## TL;DR

- WP ルート: `[パス]`
- テーマ: `[テーマ名]`
- 主要プラグイン: [リスト]
- [触る前の最重要注意]

## 対象範囲と読み込み経路

## ディレクトリ（テーマ内）

## カスタム投稿タイプ・タクソノミー

## 管理画面まわりのカスタマイズ

## 使用プラグイン

## DB

## やる ✅ / やらない ❌

## スニペット集

[functions.php への追加方法 / カスタム投稿登録パターン / ACF フィールド取得 等]

## 触る前に確認すること

## よくある作業の入口

## 既知の落とし穴
```

#### 3-c. `.claude/agent_docs/forms.md`（フォーム検出時）

**構成テンプレート（フレームワーク型）：**

```markdown
---
name: forms
description: [サイト名] の共通フォームフレームワーク（[パス]）の作業ガイド。[input / confirm / complete の流れ] [フィールド定義の書式]
when_to_use: フォーム関連ファイル（[パス]）を編集するとき / 新規フォームを追加するとき / フィールド定義（[config.php]）を変更するとき
---

# フォームフレームワーク作業ガイド

## TL;DR

## 役割と読み込み

## フォームフロー

## 主要ファイル

## フィールド定義の書式

## バリデーションの責務

## やる ✅ / やらない ❌

## スニペット集

## 新規フィールドを追加するときのチェックリスト

## 既知の落とし穴
```

#### 3-d. セクション別 / LP 別 `agent_docs/[section].md`

ヒアリングで決定したセクションについて生成する。**v1.3.0 で frontmatter / TL;DR / スニペット集を必須化**。

**構成テンプレート（v1.3.0）：**

````markdown
---
name: [section-name]
description: [このセクションの役割と特徴を1〜2行で。ファイル構成・技術スタックの特徴を含める]
when_to_use: [パス] 配下のファイルを編集・追加するとき / [このセクション固有の機能名] を触るとき / [LP特有のUIや属性] を扱うとき
---

# [セクション名] 作業ガイド（`/[path]/`）

## TL;DR

- [このセクションの一行要約]
- ブレイクポイント [N]px、メインカラー `#XXXXXX`
- [JS の方針]
- [触る前の最重要注意1〜2件]

## 対象範囲

## ファイル構成

[ディレクトリツリーと各ファイルの役割]

## コーディング規約（このLP固有）

全 LP 共通の規約は [`AGENTS.md`](../../AGENTS.md) を参照。以下は [LP 名] の固有事項。

### ブレイクポイント

### カスタムプロパティ

### フォント

### JS の方針

### よく使うクラス

### やる ✅ / やらない ❌

## スニペット集

[このLPで頻出のコード断片。実コードからサンプリングしたものを集める]

### 1. [パターン名]

```html
[コード]
```
[補足説明]

### 2. ...

## 触る前に確認すること

## よくある作業の入口

## 既知の落とし穴

（追記予定 — ユーザーから個別共有を受けて追記する）

````

**スニペットに含めるべきもの（v1.3.0、v1.4.0 で項目追加）：**
- 共通要素の HTML 構造（ヘッダー・ドロワー・アコーディオン等）
- 特徴的なカスタム属性の使い方（`data-component`、`data-modal` 等）
- JS の読み込み方（ES Modules / defer / jQuery import）
- このLPで頻出の CSS パターン（`@media (hover)` 電話リンク・レスポンシブ font-size 等）
- 新規ページ・新規バリエーション作成時の手順
- **クリック計測（data-gtm-click）の LP 固有命名規則（v1.4.0 必須）**:
  - プレフィックスと連番管理方式（エリア別 / 商品別 / 通し連番）
  - 「既存の値は絶対変えない」ルール
  - 新規追加時の最大番号確認コマンド（Grep の使い方）
  - 期間限定要素や別 LP のコピペ残存がある場合の扱い
  - そのセクションで `data-gtm-click` が **未使用**の場合は「**未使用**」と明記し、計測導入時は担当者に確認するよう注記

#### 3-e. `README.md`

**重要（v1.3.0）：既存 README が実用的に整備されている場合は触らない**。判断基準：

- 本番URL / テスト環境URL が記載されている
- ディレクトリ構成が記載されている
- ブランチルール・デプロイ設定が記載されている
- FTP情報・サーバー情報の参照先（NAS等）が記載されている

これらが揃っていれば**触らずに完了報告のみ**にする。揃ってない or 旧プロジェクト用ならテンプレートで提案・生成する。

新規生成・大幅更新が必要な場合のテンプレート：

```markdown
# [プロジェクト名]

[サイトの1行説明]

## 🌐 本番環境
| 名称 | リンク |
|------|--------|
| トップページ | [本番URL] |
| [主要閲覧ページを Step 1 のディレクトリ一覧から網羅列挙] | |

### 🔐 FTP情報

[NASパス等。実際のFTP認証情報はここに直接書かない]

### 🔐 サーバーログイン情報
[プロバイダ名]契約のレンタルサーバー

[NASパス等]

### 🧭 CMS情報

[NASパス等]

---

## 🔎 テスト環境

[テストURL]

[Basic 認証の有無と、認証情報の管理場所（NAS パス等）。**実際のユーザー名・パスワードはここに直接書かない**]

---

## 📁 ディレクトリ構成（主要な箇所）

[絵文字付きツリー]

---

## 🔠 命名ルールについて
ファイル名は小文字で統一（ただしJSライブラリは除く）

---

## 📱 ブラウザ対応範囲
[対応表]

---

## 🌿 ブランチ命名ルール
[テーブル]

---

## 🌿 git絵文字
[絵文字一覧]

---

## 🌿 デプロイ設定
[テーブル]

---

## 🛠 使い方
[手順]
```

---

### Step 4. 完了報告

生成・更新したファイルの一覧と、**ユーザーが後から手動で埋める必要がある箇所**と**削除してよい不要ファイル**をチェックリストで出力する。

例（新規プロジェクト）：

```
✅ 新規作成:
  - AGENTS.md（frontmatter + TL;DR + コーディング規約 + スニペット集 入り）
  - .claude/agent_docs/wordpress.md
  - .claude/agent_docs/forms.md
  - README.md

📝 手動で補完が必要な箇所:
  [ ] README.md: 本番URLを確認して記載
  [ ] 各 agent_doc の「既知の落とし穴」セクション（初回は空）
```

例（既存プロジェクトのフルリニューアル）：

```
✅ 上書き更新（フルリニューアル）:
  - AGENTS.md（旧: [旧プロジェクト名] → 新: [新プロジェクト名]）
  - .claude/agent_docs/wordpress.md（frontmatter / TL;DR / スニペット追加）
  - .claude/agent_docs/forms.md

✅ 新規作成:
  - .claude/agent_docs/wedding.md
  - .claude/agent_docs/contact.md

🗑️ 不要になったファイル（削除して OK）:
  - .claude/agent_docs/recruit.md（旧プロジェクト用、deprecation note に書き換え済み）

📝 手動で補完が必要な箇所:
  [ ] 各 agent_doc の「既知の落とし穴」セクション
  [ ] AGENTS.md: DBのテーブルプレフィックスを確認して記載

ℹ️ 触らなかったファイル:
  - README.md（既に実用的に整備済み）
```

---

## 品質ガイドライン

生成するすべての MD において：

1. **AIが読む文書として書く**
   - 「何をするファイルか」ではなく「AIが変更を加える前に知っておくべきこと」を書く
   - 変更時のリスク・注意点・落とし穴を優先的に記載する

2. **具体的なファイルパスと変数名を使う**
   - 「設定ファイルを確認する」ではなく「`_config/config.php` の `$formContentsArray` を確認する」

3. **既存の書式を踏襲する**
   - 見出しレベル・テーブル形式・コードブロックは既存の agent_docs と揃える

4. **過去の変更履歴はコメントしない**
   - 「〜のために追加した」「〜の修正で変更した」はコードのコメントではなく git log に任せる

5. **秘密情報を含めない**
   - 実際のメールアドレス・パスワード・APIキーは「外部参照先（NAS/Notion等）」として記す

6. **frontmatter / TL;DR / スニペット集を省略しない（v1.3.0）**
   - 「短いから」「単純だから」を理由に省略せず、形式を統一する

7. **ツール名は慎重に書く（v1.3.0）**
   - ビルドツール（Prepros / Gulp 等）の名前は、プロジェクトメンバー間で揃っているかをヒアリングで確認してから書く
   - 揃っていない場合は「SCSS → CSS のローカルビルド」のように非依存表現にする

8. **計測値・連番の現状値を書かない（v1.4.0）**
   - `data-gtm-click="[プレフィックス]29"` のような **現状の最大番号は MD に書かない**（コミットですぐ古くなる）
   - 代わりに「**Grep で確認するコマンド**」を載せる
   - **既存値の変更禁止ルール**は必ず強調する（計測の連続性が壊れる）

---

## 判断基準：どのセクションを独立 agent_doc にするか

以下の条件を**2つ以上**満たすセクションは独立ドキュメントを作る：

| 条件                                                                | 例                                  |
| ------------------------------------------------------------------- | ----------------------------------- |
| 独自の `_config/config.php` を持つ                                  | フォームフィールド定義が独立        |
| 独自の `confirm.php` / `fin.php` を持つ                             | 多段フォームが独立                  |
| 既知のバグ・落とし穴がある                                          | インデックスずれ等の複雑な挙動      |
| メール送信先の管理が独立している                                    | エリア別送信先等                    |
| 別の WordPress インストールを持つ                                   | サブディレクトリに別サイト          |
| 独自の CSS/JS が重要な機能を担っている                              | 複雑なインタラクション              |
| **独立した LP として完結している（v1.3.0）**                        | `index.html` + `assets/` が独立     |
| **LP 固有のメインカラー・ブレイクポイント・JS方針を持つ（v1.3.0）** | デザイントーンが他 LP と異なる      |
| **独自のカスタムデータ属性パターンがある（v1.3.0）**                | `data-component` など特徴的なJS制御 |

**複数 LP を1つにまとめる判断（v1.3.0）：**

- 同じ `assets/css/sass/` を共有している
- 同じ商品・サービスカテゴリに属している
- メインカラー・命名規則が共通

---

## 参考：サイト種別ごとのドキュメント構成例

- **WP + フォーム型**
  - `AGENTS.md`、`wordpress.md`、`forms.md`
  - 加えて、独立した機能単位で agent_doc を必要数（例: `contact.md`）

- **静的 HTML サイト + LP 集合体型**（v1.3.0 で対応）
  - `AGENTS.md`（コーディング規約 + スニペット集 入り）
  - LP 単位の agent_doc（例: 商品 LP / 採用 LP / キャンペーン LP）
  - 同一カテゴリで共通リソースを持つ LP 群は 1 つの agent_doc にまとめる
  - CSS 直編集など、共通規約の例外を持つ LP はその旨を明記する

---

## スキル更新ルール

このスキル自体をフィードバックに基づいて更新する際は、必ず以下を守ること：

1. frontmatter の `version` のマイナーバージョンを 1 つ上げる（例: `1.2.0` → `1.3.0`）
2. `## 変更履歴` テーブルに新しい行を追加する（日付・変更内容）

バージョニング規則：

| 種別                     | 対象                                     | 例                                           |
| ------------------------ | ---------------------------------------- | -------------------------------------------- |
| **マイナー** (x.**Y**.z) | フィードバック反映・機能追加・フロー改善 | 検出ロジック変更、新セクション追加           |
| **パッチ** (x.y.**Z**)   | 誤字修正・説明文の微調整                 | 文言変更のみ                                 |
| **メジャー** (**X**.y.z) | 破壊的変更                               | フロー全面見直し、テンプレート構造の大幅刷新 |

---

## 変更履歴

| バージョン | 日付       | 変更内容                                                                                                                                                                                                                                                                                                                                                |
| ---------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1.6.0      | 2026-07-14 | 実案件由来と誤解される独自フォーム構成・関数名・金融商品カテゴリ・カスタム属性の例を、第三者に意味が通る汎用例へ置換。Markdown テンプレートのコードフェンス不整合を修正。                                                                                                                                            |
| 1.5.0      | 2026-07-14 | 公開リポジトリ向けに記述を汎用化。README テンプレートのテスト環境セクションから認証情報の実値を削除し、「実値はここに直接書かない」方針を明文化（FTP セクションと統一）。例示に使っていた具体名・計測値をプレースホルダに置換。                                                                                                                          |
| 1.4.0      | 2026-05-13 | GTM クリック計測（data-gtm-click）の命名規則抽出を 1-g に追加。AGENTS.md・各 agent_doc テンプレートのスニペット集に「クリック計測」セクションを必須化。**既存値は絶対変えない**・**ボタン要素に付ける**・**新規は最大番号 +1**・**最大番号は MD に書かず Grep で確認**の4ルールを明文化。未使用 LP もその旨を明記する判断を追加。                       |
| 1.3.0      | 2026-05-13 | 静的HTMLサイト/LP集合体対応（1-f）/ HTML/CSS/JS実コードサンプリング解析（1-g）追加。全テンプレートにfrontmatter/TL;DR/スニペット集/やる×やらない対比表を必須化。AGENTS.mdに「コーディング規約」「検証項目対応」セクション追加。READMEは実用整備済みなら触らない判断を明文化。ツール名出力の可否ヒアリング追加。クロスプロジェクト混入検出ロジック強化。 |
| 1.2.0      | 2026-05-08 | 本番環境テーブルから CMS管理画面行を削除 → ディレクトリ一覧から主要閲覧ページを網羅列挙する指示に変更                                                                                                                                                                                                                                                   |
| 1.1.0      | 2026-05-08 | README テンプレートを刷新（FTP/サーバー/CMS情報セクション追加・git絵文字追加・デプロイ設定表・使い方ステップ・ディレクトリ構成の詳細化）                                                                                                                                                                                                                |
| 1.0.0      | 2026-05-08 | 初回リリース                                                                                                                                                                                                                                                                                                                                            |