• 相談・壁打ち — 企画書や報告資料のたたき台を作らせ、手が止まった状態から動き出す
• 調べもの — 公式情報や添付資料を読ませ、要点・根拠・確認すべき論点を抜き出す
• 文章化 — 議事録・報告文・メール・サイト本文の材料を渡し、相手に伝わる順番に組み直す
• 比較検討 — 複数案のメリット・リスク・前提を並べ、どちらに進むか判断しやすくする

• コーディング — CSS・テンプレ・スクリプトの修正を頼み、画面や機能の違和感を直す
• アプリ開発 — 作りたいものの目的を渡し、動く試作品から少しずつ実用形に近づける
• 調査・検証 — repo の構造・差分・リンク・表示崩れを確認させ、どこを直すか絞り込む
• PR 支援 — 変更内容・検証結果・マージ前の注意点を整理させ、人が判断しやすい形にする

• 定点確認 — サイトの表示、リンク、PR、ニュース、数値など、毎回見るべきものを確認して変化を拾う
• 情報整理 — メール、議事録、資料、Web情報から、未対応事項や判断が必要な点を抜き出す
• 作業の下準備 — 調査、ファイル確認、差分整理、依頼文の作成など、人が判断する前の材料をそろえる

• デザイン・試作 — ページ構成や画面案を視覚化し、文章だけでは見えにくい違和感を確認する
• スライド — 報告資料や説明資料の流れを組み、聞き手に伝わる順番へ並べ替える
• 書き出し — 作った案を HTML/CSS やスライド形式にし、次の編集や実装に渡しやすくする

まず 2〜3 案を出させ、自分が 1 つ選び、それだけ作る。「ついで」の改善を混ぜないのが完走への近道。広げたくなったら、別タスクとしてメモに逃がす。

• 目的を 1 つに絞り、PR を小さく分ける
• auto モードで進めつつ、区切りごとに自分で確認する
• 会話が長いと前の指示が薄れる → 守らせたい禁止は docs やルールに置く
• 終わったらログと差分を必ず見る（任せきりにしない）

AI の記憶は文脈が切れると消える。判断・経緯・完了状態は docs に残し、次のセッションや別の AI が同じ前提で続けられるようにする。

repo だけで判断せず、公開側に手書きの変更がないか反映前に確認する。実際にこれで、当日手書きされた本文を上書きしかけた事故を防いだ。

取り消せない操作（公開・外部送信）や言葉選びは人が決める。実装と判断の担当を分けると、急ぎでも事故が起きにくい。

GitHub・filesystem・browser 系を実際に接続し、調べもの〜PR 作成までの流れを試したい。鍵になるのはスコープ設計と、許可するツールの絞り込み。

plan で調べてから実装、長時間は auto、など場面ごとの使い分けを実運用で確かめたい。どこまで任せて安全かの線引きを掴むのが目的。

よく出す依頼を型にして、毎回ぶれない頼み方にしたい。目的・現状・やること・成功条件・ログの貼り方をひな形に。