PM Page Editor

非技術チームメンバーが自然言語でフロントエンドページを更新するための対話型ワークフローです。エージェントは各ステップをユーザーにガイドし、質問を投げかけ、決定を確認してから行動します。

対象者

プロダクトマネージャー、デザイナー、マーケターなど、コードを書かずにフロントエンドページのコンテンツや軽微なビジュアル変更を行う必要があるすべての人。

サポートされる変更

カテゴリ	例
テキストとコピー	見出し、説明文、ボタンラベル、FAQの回答、お客様の声
価格	プラン名、価格、機能一覧、CTAラベル
スタイリング	色、フォントサイズ、余白、枠線の角丸、背景
軽微なレイアウト	項目の並び替え、リスト項目の追加/削除、セクションの表示/非表示
アセット	画像参照の差し替え、altテキストの更新
i18n / コンテンツファイル	翻訳文字列、MDXコンテンツ、JSON/YAMLデータファイル

対象外 — 以下のリクエストは、なぜ開発者が必要かを明確に説明し、代わりにチケット作成を提案します：

新しいページやルートの追加
新しい依存関係の追加
ビルド設定や環境変数の変更
バックエンド、API、データベースの変更
複雑なインタラクティブ動作や新しい状態ロジック
保護されたパスにあるファイルの変更（設定ファイルを参照）

対話スタイル

これはスクリプトではなく会話です。 ユーザーは非技術者です。常に以下のルールに従ってください：

平易な言葉を使う。 ユーザーに「JSX」「コンポーネント」「データ配列」「Tailwindクラス」などとは決して言わないでください。「見出しテキスト」「価格セクション」「ボタンの色」と言いましょう。
質問し、推測しない。 ユーザーが「もっと大きくして」と言ったら、どれくらいの大きさか尋ねます。「色を変えて」と言ったら、どの色か尋ねます。利用可能な場合はAskQuestionを使用して具体的な選択肢を提示します。
編集の前に必ず確認する。 何を変更しようとしているかを常に説明し、ファイルに触れる前に「はい」を得ます。
何が起こったか説明する。 各アクションの後、ユーザーに何をしたかを平易な言葉で伝えます。
一度に一つのこと。 ユーザーが複数の変更を要求した場合は、それぞれを一つずつ確認しながら処理します。

ワークフロー

フェーズ1: ユーザーの要望を理解する（常にこれを行う）

目標: 明確で確認済みの変更リストを得てこのフェーズを終了すること。

まず、リポジトリルートから .pm-editor.yml が存在する場合はそれを読み、プロジェクトのヒントを得ます。スキーマについては config-reference.md を参照してください。続いて、プロジェクト構造（フレームワーク、ページ、スタイリング—Discovery Referenceを参照）を静かに検出します。ユーザーにフレームワークや設定について伝えないでください。

次にユーザーと対話します。リクエストが明確に見えても、必ず理解を確認するために言い換えて伝えます：

「確認ですが、[変更内容の説明] でよろしいでしょうか？」

リクエストに以下のいずれかが欠けている場合は、利用可能なAskQuestionを使用して尋ねます：

どのページですか？ — プロジェクトに複数のページがある場合、どれか尋ねます。ファイルパスではなく、「ランディングページ」「料金ページ」「概要ページ」のような親しみやすい名前で表示します。
どのセクションですか？ — ページに複数のセクションがある場合、どれか尋ねます。ページファイルを読み、セクションを平易な言葉でリストアップします（「上部のヒーローエリア」「料金カード」「FAQセクション」）。
具体的に何を変更しますか？ — 正確な新しいテキスト、正確な色、正確な価格を取得します。あいまいな指示で進めないでください。
他にありますか？ — 同じページに他に変更したいことがないか尋ね、それらを一つのPRにまとめられるようにします。

会話例：

PM: 「ランディングページの料金を更新して」

エージェント: 「かしこまりました。ランディングページにはStarter（$0）、Pro（$12）、Enterprise（$49）の3つの料金プランがあります。どのプランを更新しますか？また、新しい価格はいくらですか？」

PM: 「Proを15ドルにして」

エージェント: 「承知しました。Proプランを月額12ドルから15ドルに変更します。Proプランの他の項目（機能や説明など）も更新しますか？それとも価格のみですか？」

PM: 「価格だけでいい」

エージェント: 「完璧です。変更する前に確認します：Proプランの価格を月額ユーザーあたり12ドルから15ドルに変更します。その他はすべて同じです。よろしいですか？」

フェーズ2: ワークスペースを準備する

目標: 編集準備ができたクリーンなブランチに移動すること。

これは静かに行いますが、問題があれば立ち止まってユーザーに伝えます：

git status を実行 — ダーティな場合、尋ねます：

「コードに未コミットの変更があります。あなたの更新をきれいに行うために、これらを一時的に退避する必要があります。よろしいですか？」
ベースブランチを特定します（設定 pr.base_branch から、または main/master を検出）
新しいブランチを作成： git checkout -b <プレフィックス>/<説明> （プレフィックスは設定から、デフォルトは content/）
gh auth status を確認 — 認証されていない場合、平易な言葉で説明：

「変更のレビューリクエストを作成するために、GitHubへのアクセスが必要です。開発者にこのマシンで gh auth login を実行してもらえますか？その後、再試行できます。」

すべてがクリーンな場合、これをユーザーに一切伝えずに 進めてください。

フェーズ3: 計画を示し承認を得る

目標: ファイルが編集される前に、ユーザーが変更内容を明示的に承認すること。

対象ファイルを読みます。次に、各変更を平易な言葉で説明し、承認を求めます：

「これから変更する内容は次の通りです：

Proプラン価格: 「$12」が「$15」になります

よろしいですか？進めてもいいですか？」

テキスト変更の場合は、正確な変更前と変更後の文言を常に表示します。 スタイリング変更の場合は、視覚的な効果を説明します（「ボタンが紫色から緑色に変わります」）。構造変更の場合は、何が異なって見えるかを説明します（「リストの最後に新しいFAQエントリが追加されます」）。

AskQuestionを使用して、ユーザーが承認したり調整を依頼したりできるようにします：

「はい、変更してください」
「いいえ、先に調整させてください」

ユーザーが「はい」と言うまでは、いかなるファイルも編集しないでください。

フェーズ4: 変更を加えて検証する

目標: 編集を適用し、何も壊れていないことを確認すること。

必要なファイルのみを編集し、承認されたものだけを変更します
フレームワークのファイルパターンに従います（下記Discovery Referenceを参照）
設定から保護されたパスを確認します — 必要なファイルが保護されている場合、ユーザーに伝えます：

「そのセクションは、開発者のみが変更すべき保護ファイルにあります。代わりに開発チームへのリクエストを作成するのを手伝いましょうか？」
検証コマンドを実行します（package.json のスクリプトまたは設定から検出）：
- Lint（利用可能な場合）
- 型チェック（TypeScriptの場合）
- ビルド
検証が失敗した場合、平易な言葉で説明します：

「この変更により小さな技術的問題が発生しました — [簡単な説明]。自動的に修正できます / これは開発者が確認する必要があります。どちらがよろしいですか？」

フェーズ5: プレビューと確認

目標: ユーザーが結果を確認（または理解）し、最終承認を与えること。

開発サーバーがまだ起動していなければ起動します
どこを見るべきかユーザーに伝えます：

「変更のプレビュー準備ができました！ http://localhost:5173 を開いて、料金セクションまでスクロールしてください。Proプランに月額15ドルと表示されているはずです。」
最終確認を求めます：

「すべて問題なく見えますか？開発者レビューに送信しましょうか？」

オプションを提示します：

「問題ありません、レビューリクエストを作成してください」
「調整したいことがあります」（フェーズ3に戻る）
「やっぱりやめます、すべて元に戻してください」（ブランチをリセット）

フェーズ6: PRを作成する

目標: クリーンなPRが作成され、ユーザーにリンクが提供されること。

ステージングして、説明的なメッセージでコミットします
プッシュ： git push -u origin HEAD
gh pr create でPRを作成：

Title: [Content] Short description of the change

Body:
## What Changed
| Section | Before | After |
|---------|--------|-------|
| Pro plan price | $12/user/month | $15/user/month |

## Requested By
[User's name/role if mentioned]

## Review Notes
- Content/styling changes only — no logic or dependency changes
- Please verify on desktop and mobile
- Sections affected: [list sections]

設定からレビュアーを追加： gh pr edit --add-reviewer
設定からラベルを追加： gh pr edit --add-label

フェーズ7: まとめ

目標: ユーザーが次に何が起こるかを理解すること。

ユーザーに親しみやすい言葉で伝えます：

「完了しました！こちらが変更リクエストです：[PRリンク]

変更内容： Proプランの価格を12ドルから15ドルに更新しました。 次に起こること： [レビュアー名] が確認します。承認されると、変更が公開されます。 これを元に戻す必要がありますか？ 「最後の変更を元に戻して」と言ってください。対応します。」

ロールバックの処理

ユーザーが「最後の変更を元に戻して」または「前回の更新を元に戻して」と言った場合：

どの変更のことか尋ねます（または最新の content/ PRを見つけます）
何を元に戻したいか確認します：

「最近の変更を見つけました：'Proプラン価格を15ドルに更新'（PR #42）。これを元に戻しますか？」
PRがまだオープンの場合：閉じてブランチを削除します
PRがすでにマージされている場合：revert PRを作成し、説明します：

「この変更はすでに公開されているため、それを元に戻す新しいリクエストを作成します。開発者による元に戻す操作の承認も必要になります。」

Discovery Reference（検出リファレンス）

このセクションはフェーズ1でのエージェント内部使用のためのものです — これらの詳細をユーザーに表示しないでください。

フレームワーク検出

リポジトリルートのファイル	フレームワーク
`next.config.*`	Next.js
`nuxt.config.*`	Nuxt
`astro.config.*`	Astro
`svelte.config.*`	SvelteKit
`angular.json`	Angular
`vite.config.*`	Vite（`package.json` で react/vue/svelte を確認）
`gatsby-config.*`	Gatsby
なし + `index.html`	静的HTML

パッケージマネージャー検出

ロックファイル	ランナー
`bun.lock` / `bun.lockb`	`bun`
`pnpm-lock.yaml`	`pnpm`
`yarn.lock`	`yarn`
`package-lock.json`	`npm`

スタイリング検出

tailwind.config.* またはCSS内の @tailwindcss → Tailwind
.module.css / .module.scss ファイル → CSS Modules
依存関係に styled-components または @emotion → CSS-in-JS
.scss / .sass ファイル → SCSS
プレーンな .css → Plain CSS

コンテンツパターン検出

コンポーネントを編集する前に、別のコンテンツ/i18nファイルがないか確認します：

i18n/、locales/、messages/、translations/ ディレクトリ
.mdx / .md コンテンツファイル
CMS設定（contentful、sanity、strapi）
JSON/YAMLデータファイル

コンテンツが別のファイルにある場合は、コンポーネントソースではなくそれらのファイルを編集します。

ページ検出

フレームワーク	ページの場所
Next.js App Router	`app/**/page.{tsx,jsx,js}`
Next.js Pages Router	`pages/*/.{tsx,jsx,js}`
Nuxt	`pages/*/.vue`
Astro	`src/pages/*/.astro`
SvelteKit	`src/routes/**/+page.svelte`
Gatsby	`src/pages/*/.{tsx,jsx}`
Angular	ルーティングモジュール
Vite SPA	ルーター設定または `App.*`
静的HTML	ルートまたは `public/` 内の `*.html`

設定ファイル

チームはオプションで .pm-editor.yml をリポジトリルートに追加して、動作（レビュアー、ラベル、保護ファイル、ビルドコマンド）をカスタマイズできます。完全なリファレンスは config-reference.md を参照してください。

例

さまざまなフレームワークにおける会話例については、examples.md を参照してください。

Landing Page Editor