brainstorming

ブレインストーミング

コードや設定に手を加える前に、構造化された対話を通じて大まかなアイデアを検証済みの設計にします。

設計を提示し、ユーザーの承認を得るまでは、実装を開始しないでください。 これは、単純に思える場合も例外ではありません。「簡単な」タスクほど、検討されていない前提が無駄な作業を招きやすいためです。

プロセス

1. コンテキストを確認する

まずプロジェクトの状態を確認します。ファイル、設定、最近の変更、既存のパターンを調べます。質問する前に、現在あるものを把握してください。

2. 明確化のための質問をする

• 質問は一度に1つ。 質問を並べて相手を圧倒しないでください。
• 選択肢が決まっている場合は、選択式を優先します。本当に選択肢が定まらない場合は、自由回答形式にします。
• 目的、制約、成功の基準、ユーザーが最も重視することに焦点を当てます。

3. アプローチを提案する

トレードオフを添えて、2〜3個のアプローチを提示します。推奨案を最初に示し、その理由を説明します。欠点も率直に伝えてください。

妥当なアプローチが1つしかない場合は、その旨と、他の選択肢が適さない理由を説明します。見せかけの選択肢を作らないでください。

4. 設計を提示する

何を作るのか把握できたら、複雑さに応じてセクションに分けて設計を提示します。

• シンプルなセクションは数文程度
• 実際にトレードオフがある場合は、詳しく説明
• 各セクションの後に承認を得ることで、ユーザーが早い段階で軌道修正できるようにします

次の内容を扱います。変更する内容、変更しない内容、ユーザーに確認してもらう内容、実装時まで保留する判断事項。

5. 実装に移る

ユーザーが設計を承認したら、実装に進みます。移行の場合は、該当する移行フェーズに入ります。それ以外の作業では、実行を開始します。

使用する場面

• 移行 — 開始前にサイト構造を調査し、編集可能性に関するトレードオフ（ページビルダーか静的ページか、編集可能にする範囲、コンテンツ再構成の判断など）を話し合います
• 機能追加 — 既存のサイトにスニペット、ビジュアル編集、設定を追加する前
• 再構成 — コンテンツ、コレクション、設定を再編成する前
• 曖昧な依頼 — ユーザーが範囲を指定せずに「これをCCで動くようにして」と言った場合

使用しない場面

• 明確に定義され、実装方法も明白な単独のタスク（「_editables に snippet: true を追加する」など）
• 問題と解決策が明確なバグ修正
• ユーザーが「そのままやって」と明示した場合、または詳細な仕様を提示した場合

内容

このスキルは単一のファイルで構成されており、詳細な解説はありません。設計の承認後は、作業を担当するスキルで実装を続けます。

次に進むスキル	対象となる作業
migrate-to-cloudcannon	移行全般。フェーズ1から開始
cloudcannon-configuration	コレクション、入力、構造、コレクション URL
cloudcannon-visual-editing	編集可能な領域
cloudcannon-snippets	コンテンツ内の MDX コンポーネントまたはインライン HTML
make-site-multilingual	Rosey と CloudCannon コネクタ

主な原則

• 質問は一度に1つ — 質問を並べて相手を圧倒しない
• 選択式を優先 — 選択肢が決まっている場合、自由回答形式より答えやすい
• YAGNI — 設計から不要な複雑さを取り除く
• 代替案を検討する — よりシンプルな別のアプローチがないか、常に考える
• 率直である — 複雑になりすぎていると思ったら、そう伝える。スコープの拡大には歯止めをかける
• 段階的に検証する — 設計をセクションごとに提示し、次に進む前に承認を得る

よくある誤解

言い訳	実際のところ
「簡単な作業に設計は必要ない」	簡単な作業ほど、思い込みによる無駄が生じやすいものです。設計は短くても構いません。
「何をすべきかはもう分かっている」	分かっているのは、自分ならどうするかです。ユーザーには異なる優先事項や制約があるかもしれません。
「質問すると作業が遅くなる」	誤った思い込みのほうが、作業をさらに遅らせます。今ひとつ質問すれば、後のやり直しを防げます。
「問題があればユーザーが教えてくれる」	ユーザーは、誤った結果を見るまで何を指摘すべきか分からないことがよくあります。事前に確認しましょう。
「進めながら考えればいい」	そうすると、結局やり直すことになります。まず選択肢を検討しましょう。