AI運用の設定資産、
ぜんぶこの1ページに。

判断が必要な通常タスクや、軽微でも判断に迷う作業はOpus 4.8で処理する。クレジット消費を抑えつつ品質を確保するため、タスクの性質に応じてモデルを使い分ける方針の中核。メインセッションは常にOpus 4.8のまま維持する。

対象は「すぐ結果が欲しい質問」「CRUD実装」「軽微な修正」「単純な置換」など。モデルIDは claude-sonnet-5 と明記されている。判断に迷う場合はSonnet 5ではなく既定のOpus 4.8を使う。

該当基準は①アーキテクチャ設計・大規模な設計判断、②コードベース全体の監査／大規模移行・modernization、③複雑なバグの根本原因調査、④長時間の自走を要する作業の4つ。これらに該当しないタスクではFable 5を起動しない、と明示的に禁止されている。

「重いタスク」4類型に該当する作業は、直接実行せず専用サブエージェント heavy-task に委譲する。heavy-task の model は claude-fable-5。メインセッションはOpus 4.8のまま維持し、Fable 5は必要時のみ呼び出す二層構成。

セッション全体をultracodeにすると全タスクにワークフロー層が適用され消費が膨らむため禁止。動的ワークフローが本当に有効な単発タスクのときだけ、プロンプトに ultracode キーワードを付けて起動する。ワークフロー完了後は通常作業に戻す。

具体則は4つ: ①新規プロジェクト・新機能の着手時は実装より先に検証ループ（テスト・リンタ・型チェック・ビルド・起動確認）を整備し、検証手段がないまま実装を積み上げない、②同じ指示・訂正の繰り返しに気づいたらCLAUDE.md／スキル／hooks／settingsへの恒久化を提案、③環境の摩擦（曖昧な手順・壊れたビルド・毎回の権限プロンプト・手作業前提フロー）は回避せず環境側の修正を優先、④プロジェクト固有のハーネスは各プロジェクトのCLAUDE.mdに書き、グローバルには原則のみを置く。

①ハーネス整備フェーズは実装より前に置き、検証ループ構築（テスト・リンタ・型チェック・起動確認コマンドを動く状態に）、.claude/settings.json の作成・更新（権限allowlist・編集後自動リンタ等のhooks）、プロジェクトCLAUDE.mdの作成・更新を行う。②運用があるプロジェクトではループ設計フェーズ（デプロイ・動作確認・ログ観測の手順定義、繰り返し作業のhooks/cron/スクリプト自動化明記）を含める。新規プロジェクトで未整備ならプランの最初のステップは機能実装ではなくハーネス整備、既存で整備済みならプラン冒頭で「ハーネス確認済み」と一言確認してから実装ステップに進む。

具体則は3つ: ①修正・変更を入れるときは効果を観測する手段（ログ・メトリクス・検証コマンド・確認手順）をセットで用意・明記する、②同じ形の作業が繰り返されるなら自動化（hooks、cron／スケジュール実行、/loop、スクリプト化）への昇格を検討・提案する、③失敗や手戻りが起きたら個別対処に加え「ループのどこが欠けていたか（観測不足か・検証不足か・手順の曖昧さか）」を一言添える。

対象=スキル/CLAUDE.md設定/hooks・自動化・進捗ボード等の仕組み/配布・可視化HTML/初めて使った外部スキル・MCP・プラグイン。追記先=HTMLプレビュー/_一覧データ.json＋設定ハブ/data/可視性.json（外部由来は外部リソース.json）→_build_site.py と _generate_inventory.py で再生成。作りっぱなし・使いっぱなしでハブから漏らさないための台帳ルール。

対象サイトは rutinelabo.com。1本の収録から複数プラットフォームへ横展開する制作・自動投稿パイプライン全体の前提定義。収益化チャネル（LINE/Udemy/メンバーシップ）まで含めた設計思想が書かれている。

# コンテンツ展開の基本方針
- 1本のコンテンツを [動画] → [ブログ] → [note等の配信媒体] → [SNS] → [ショート動画] の順に展開する
- 各媒体の役割（SEO/拡散/誘導/収益化）を明確に分ける
- 収益化チャネル（[LINE/講座/メンバーシップ等]）への導線を各媒体に組み込む

「前半は初心者でもわかりやすく解説」「後半はIT/AIに興味を持つ人や専門家でも面白いと感じるほど専門的にまとめる」という品質基準。月間PV・登録者数などのペルソナ設定を含む。

# コンテンツの二層構成
- 前半は初心者でもわかりやすく解説する
- 後半は [分野] に興味を持つ人や専門家でも面白いと感じるほど、情報を専門的にまとめる

AIセッションの出力言語を日本語に固定する規約。コード内コメントのみ柔軟（既存コードのスタイルに合わせる）。

## 言語
- ユーザーへの応答は **日本語** で行うこと
- コード内のコメントは日本語 or 英語どちらでも可（既存コードに合わせる）

「アイデアに常に疑問を持ち、肯定するだけではなく専門家として議論を深める」「より良い代替案があれば積極的に提案」「問題点やリスクは率直に指摘」の4原則。イエスマン化を防ぐ設定。

## 対話スタイル
- ユーザーの意見に同意するだけでなく、**知的な議論相手**として振る舞う
- アイデアに常に疑問を持ち、専門家としての知識の観点から議論を深める
- 理論を問い直し、より良い代替案があれば積極的に提案する
- 問題点やリスクがあれば率直に指摘する

AI_prompt(Auto)=WordPress自動化、complete_note/complete_x=完成記事、note_auto_publisher/x_auto_publisher=Playwright投稿ツール、SNS発信用/=blog-sns出力集約先、ショート動画概要欄・返信=旧フォルダ（過去ログ）等。新規SNSコンテンツはSNS発信用/へ置く。

SNS発信コンテンツはYouTube URLが必要なため/blog-createに含めず、動画投稿後の/blog-snsで生成し「SNS発信用/YYYYMMDD トピック名.md」の1ファイルに集約する。見本テンプレートは既存の出力ファイルを参照。差し込み画像は所定のDrive symlinkフォルダに置く。

# コンテンツ制作パイプラインの分割原則
1. `/create` … 素材→記事下書きまで（URL不要な工程）
2. `/finish` … 校正・画像・リンク・投稿まで
3. `/sns` … 動画URL確定後にSNS発信物を **1ファイルに集約生成**
- 動画URLなど後で確定する情報に依存する工程は、前段のコマンドに含めず後段に分離する

blog_image_automation.py / blog_link_automation.py / blog_image_upload.py / wordpress_auto_post.py の順に実行。校正のみ手動、記事スコアリングはClaude評価。

# ブログ公開の工程分解
1. Markdownで執筆
2. 画像タグをプレースホルダー化するスクリプト
3. 校正（手動チェックポイント）
4. 内部/外部リンク自動埋め込み
5. 画像アップロード＋プレースホルダー置換
6. AIによる記事スコアリング
7. 収益導線（アフィリ等）の文面生成
8. CMSのAPIで下書き投稿
- 各工程を独立スクリプトにし、手動確認ポイントを明示する

コマンドは cd note_auto_publisher && source venv/bin/activate && PYTHONUNBUFFERED=1 python note_publisher.py --article "{ファイル名}"。画像は投稿画像/RoutineLabo/今回の差し込み画像/（Drive symlink）。

コマンドは cd x_auto_publisher && source venv/bin/activate && PYTHONUNBUFFERED=1 python x_publisher.py --article "{ファイル名}"。画像はnoteと同じ所定フォルダを使う。

instagram_auto_dm/ フォルダに実装。ローカル実行は cd instagram_auto_dm && python app.py。

各コンポーネントごとの技術選定表。CMS投稿はAPI、note/XのようにAPIが無い媒体はPlaywrightのブラウザ自動化で下書き投稿する構成。

例: 20260129 ClawdBot.md、FlovaAI-images1。日付プレフィックスで時系列ソートと突合が可能になる。

## ファイル命名規則
- 記事ファイル: `YYYYMMDD トピック名.md`
- 画像プレースホルダー: `{記事プレフィックス}-images{番号}`
- プロジェクトフォルダ: `YYYYMMDD トピック名/`
- 日付プレフィックスで時系列ソート・記事との突合を可能にする

A=速報（文字起こし3,000字未満・手順なし）、B=ニュース＋使い方（3,000-8,000字）、C=徹底比較・完全ガイド（8,000字以上）。判定ロジックは02_ブログ記事作成.mdのSTEP0、基準はR1が保持。判定結果は記事冒頭にコメント出力し、無い場合のデフォルトはタイプB。動画で説明した内容は省略せず、ステップ偏重を避けてボックス等を織り交ぜる。

# 記事タイプ自動判定
記事の文字数は固定指定せず、元素材の内容から自動判定する:
| タイプ | 目標文字数 | 判定条件 |
|---|---|---|
| A 速報 | 2,500〜3,500 | リリース情報中心・手順なし・素材3,000字未満 |
| B 解説 | 5,000〜6,000 | 情報＋操作手順あり・素材3,000〜8,000字 |
| C 完全ガイド | 7,000〜9,000 | 詳細比較・専門情報多数・素材8,000字以上 |
- 判定結果を記事冒頭にコメントで出力する（例: `<!-- 記事タイプ: B -->`）
- 判定不能時のデフォルトはタイプB
- 元素材で説明された内容は省略せず記事化する

日付/タイトル/URL/YouTube/カテゴリー/タグのカタログ。YouTube列は各記事フォルダのタグ情報.mdをWP URLで突合。実行は cd "AI_prompt(Auto)" && source venv/bin/activate && python article_index.py。要ネットワーク＋wordpress_config.json。

# 記事インデックスの自動生成
- CMSのAPIから全公開記事（日付/タイトル/URL/カテゴリ/タグ）を取得し、1つのインデックスファイルに書き出すスクリプトを用意する
- 内部リンクを貼るときは必ずこのインデックスを参照元にする（SSOT）
- 動画URLなど関連メディアの列も、各記事のメタファイルと突合して同じ表に持たせる

python3 AI_prompt\(Auto\)/new_article_setup.py "トピック名" [日付YYYYMMDD]。命名規則に沿った雛形を自動生成し、手作業のブレを防ぐ。

# 新規作業フォルダのセットアップスクリプト
- `setup.py "トピック名" [日付]` の1コマンドで、命名規則に沿ったフォルダ＋テンプレートファイル一式を生成する
- 毎回の手作業コピーをやめ、命名規則をスクリプトに埋め込んで強制する

個別指定（フォルダ名）と --all の一括モードがある。作業ディレクトリを常に「進行中のみ」に保つ運用。

# 完了物のアーカイブ自動化
- 完成した作業フォルダを `archive.py <フォルダ名>`（または `--all`）で年別フォルダへ移動し、同時にインデックスを更新するスクリプトを持つ
- 作業ディレクトリには進行中の案件だけが残る状態を保つ

撮影前リサーチ〜撮影後の記事・SEOまでを1指示で回す。SNS共有・ショート概要欄はYouTube投稿後に/blog-snsで別途生成。

# プロンプトチェーンの設計原則
- 連続実行できる工程は「一括実行」プロンプト1つでチェーン化する
- ただし後から確定する情報（公開URL等）に依存する工程はチェーンに含めず、確定後の別コマンドに分離する

01=リサーチ台本、02=ブログ記事、02-2=AIアバター台本、03=YouTube SEO。04/05は/blog-snsから呼ばれる文体・構成の定義ファイル。R1〜R8はルール・タグ・リンク・インデックス・概要欄テンプレート等の参照データ。

# プロンプトファイルの2種別管理
- **実行系**: 番号付き（01_リサーチ→02_執筆→03_SEO…）のワークフロープロンプト
- **参照系**: 文体定義・ルール・リンクDB・テンプレート（R1〜Rn）。実行系から呼び出して使う
- ルールの正本は参照系に置き、実行系は判定・実行だけを担う

自動処理スクリプトが本文を書き換えるパイプラインのため、破壊的変更からの復元手段を常に確保する。

- 記事ファイル編集時は **バックアップを作成** してから変更する（自動処理が本文を書き換える前提の安全策）

自動化は下書きまで、公開判断は人間という承認ゲート設計。誤公開事故の防止。

# 自動投稿の承認ゲート
- 自動投稿ツールは全媒体デフォルトで **下書き** として保存する
- 公開は必ず人間が内容確認のうえ手動で行う（誤公開の防止）

blog_link_automation.pyがこのDBを使ってキーワードにリンクを自動付与する。リンク先の正本を1ファイルに集約。

# リンクDBの一元管理
- 内部/外部リンクは1つのリンクDBファイル（キーワード→URL）に集約する
- 記事へのリンク埋め込みはこのDBを参照するスクリプトで自動化し、リンク先の正本を1箇所に保つ

自動アップロード・差し込みスクリプトがこれらのパスを見るため、置き場所を固定する。

自動投稿ツール群が各種APIキーを使うため、秘密情報はファイル直書き・git管理外とする。

- `.env` ファイルやAPIキーをコミット・共有しないこと（秘密情報はgit管理外・環境変数で扱う）

note/Xはvenv有効化＋PYTHONUNBUFFERED=1付きで実行。WPは blog_auto_process.py、IG DMは app.py のローカル実行。毎回調べ直さないためのコマンド正本。

noteにWordPressと同じ本格記事を載せない、X Articleはnoteよりさらに要約・結論ファースト。Udemy=買い切り教科書、メンバーシップ=継続課金の応用・実践という商品の棲み分けも定義。

# 媒体別の役割分担
- [自社ブログ] = SEO重視の本格記事（収益のメイン）
- [配信プラットフォーム] = 軽めの配信・拡散用（ブログ/動画への誘導）
- [SNS長文] = テンポよい要約・結論ファースト（拡散と誘導）
- 同じ本格記事を複数媒体に完全コピーで載せない（SEO競合・カニバリ回避）
- 買い切り商品と継続課金商品の役割（教科書 vs 応用・実践）を分ける

config/style.jsonが「見た目とAI生成挙動」の唯一の正典。詳細はconfig/README.md参照。直接コード改変は禁止で、設定を経由することで再現性と一元管理を担保する。

## スタイル設定の単一正典ルール
- 見た目（フォント・色・サイズ）やAI生成のスタイル指示を変えるときは、必ず `config/style.json`（設定の単一正典）だけを編集する。
- コンポーネントやスクリプトへの直接ハードコードは禁止。
- 新しい設定項目は「①設定ファイルにキー追加 → ②型/スキーマに反映 → ③読む側から参照」の順で追加する。

設定→型/バリデーション→利用箇所という一方向の流れを守ることで、未検証の値がパイプラインに入るのを防ぐ。Zodスキーマにより設定ミスを起動時に検出できる。

## 設定項目の追加手順
新しい設定項目を追加するときは必ずこの順で進める:
1. まず設定ファイル（例: `config/style.json`）にキーを追加
2. 型定義とスキーマ（例: Zod）に反映してバリデーションを効かせる
3. その値を読む側（コンポーネント/スクリプト）から参照
コード側に先にハードコードしない。

generation.lookPresets(ペア定義)/imageStylePresets/videoStylePresets/lookChoice(グローバル既定)の構成。/video-start実行時にlookを選択しstyle_choice.txtに保存、以降の/video-finish・/video-export-edit・/edit-shortが読む。look追加は「中身プリセット追加→lookPresetsに1エントリ→既存動画はstyle_choice.txt書換」。

中間生成物はwork/<name>/（audio_normalized.wav, silences.json, transcript.json, jetcut.mp4, broll_plan.json, broll/）に置かれ、最終出力はoutput/main/<name>_main.mp4とoutput/shorts/<name>_short*.mp4。Bロール計画はGemini、素材生成はRenoiseを使用。

01-preprocess.ts=音声抽出+Whisper、02-jetcut.ts=無音除去カット、03-broll.ts=Bロール計画+生成、04-main-video.ts=本編オーケストレーター、05-short-video.ts=ショート抽出。編集対象はstyle.jsonのみ。

Step1で文字起こしとテロップ確認ファイル生成後に停止しユーザー確認を待つ。Step1.5でカタカナ・固有名詞・英語表記を人間が修正。Step2で本編完成、Step2.5で/edit-short input/xxx.mp4 2のようにショートも生成可。

## 人間チェックを1箇所に集約する2段階ワークフロー
- [Step 1] 自動処理（文字起こし等）を実行し、確認用ファイルを生成して**停止**する
- [Step 1.5] 人間が確認用ファイルを修正（固有名詞・誤認識の訂正のみ）
- [Step 2] 残りの処理を最後まで全自動で仕上げる
人間の確認ポイントをパイプラインの1箇所に固定することで、全自動と品質担保を両立する。

/video-cutが推奨で「無音+フィラー+AI判断カット＋テロップ校正→Premiere直行XML(非破壊・停止なし)」の完全自動。/edit-mainはテロップ確認なしのため非推奨。/video-cleanupはwork/キャッシュのみ削除しoutput/は保護。

Premiere直行はoutput/edit/<name>/に元動画参照XMLを出し編集作業ほぼゼロ。焼き込み版はoutput/main/<name>_main.mp4でそのまま投稿可。編集ソフト用はjetcut.mp4参照XML一式。用途で使い分ける。

どちらのモードで生成されたかはバンドル内README.mdに明記される。/video-cut後の/video-finish・/edit-shortは無音+フィラー+AIカットをそのまま使用。無音のみに戻すにはwork/<name>/cut_plan.jsonを削除する。両モードはpreprocess/jetcut/broll planのキャッシュを共有し二重処理は起きない。

npm run preprocess -- input/xxx.mp4 (Step1のみ)、npm run main -- input/xxx.mp4 (preprocess含む本編)、npm run short -- input/xxx.mp4 2 (ショート2本)。デバッグや部分再実行に使う。

preprocess実行で自動生成され、再実行時に編集内容が自動反映される。例: [# 0 0.00- 2.50] こんにちは、せなおです。タイムコード部を壊すと対応付けが崩れるため右側のみ編集する。

## 文字起こし手動修正ファイルのルール
自動文字起こしの誤認識（カタカナ語・固有名詞・英語）は専用の編集用ファイルで直す:
- 各行の識別子/タイムコード部（例: `[#番号 開始-終了]`）は**絶対に変更しない**
- 行を増やしたり減らしたりしない
- 識別子の右側のテキストだけを編集する
編集内容は永続化され、再レンダリングしても保たれる。

raw(transcript.json)と人間編集(transcript_edit.md)を分離することで、キャッシュ再利用と手修正の両立を実現。入力動画差し替え時のみ編集ファイルが新内容で作り直される点に注意。

## raw出力と人間編集の分離原則
- AIの生出力（raw）と人間の手修正は**別ファイル**で持つ
- 再実行・再レンダリング時はrawを再生成せず、手修正ファイルを優先して反映する
- 入力素材そのものを差し替えたときだけ手修正ファイルを再生成する
これにより「再実行したら修正が消えた」を防ぐ。

スタイル変更時はwork/を残したままnpm run main再実行でAPIコストゼロ。Bロールの方針自体を変えたい場合はwork/<name>/broll_plan.jsonとwork/<name>/broll/を削除して再実行する。

## 高コスト工程のキャッシュ設計
- API課金や時間のかかる工程（文字起こし・AI生成など）の結果は作業ディレクトリにキャッシュする
- 再実行時はキャッシュをスキップし、安価な最終工程（レンダリング等）だけやり直す
- 方針レベルでやり直したいときだけ、該当キャッシュファイルを削除して再実行する
スタイル・見た目の変更でAIコストを再発生させない。

入力素材は読み取り専用扱いで非破壊を保証。output/は自動生成物なので手編集すると再実行で消える。見た目の変更は必ずconfig/style.json経由。

## パイプラインの禁止事項
- 入力素材ファイルは読み取り専用扱いとし、絶対に変更しない（非破壊）
- 自動生成物の出力ディレクトリ（`output/`等）を手動編集しない（再実行で消える）
- 見た目・挙動の変更をコンポーネント直書きでやらない（設定ファイル経由のみ）

fixtureはtest/fixtures/sample24s/（凍結・手編集禁止）、goldenはtest/golden/sample24s/。golden更新は意図的変更時のみ npm run verify:regression -- --update を明示実行し、黙って上書きしない。2026-07-05導入。

## 検証ハーネス必須ルール
- 実装を変更したら `npm run verify:all`（typecheck + 設定検証 + golden回帰 + E2Eスモーク、外部API不要・数十秒）を**必ず実行**してから完了報告する
- テスト用fixtureは凍結し手編集禁止
- golden（期待出力）の更新は意図的な仕様変更時のみ、更新フラグ付きコマンドを明示実行する。黙って上書きしない

パラメータの散在を防ぎ、設定変更と仕様書が常に同期する状態を保つ。spec:genは設定から仕様書を自動生成する仕組み。

## パラメータ集約と仕様書同期
- 数値パラメータはコードにハードコードせず、設定ファイルに集約する
- 設定を変更したら、仕様書生成コマンドで仕様書を自動再生成し、設定と文書が乖離しない状態を保つ

外部ソフト(Premiere Pro)へのインポート互換は自動テストで完全担保できないため、実機プローブで確認済みの構造だけを信頼する運用。XML構造を変更した場合は再度xml-smokeを実施する。

## 外部ソフト互換フォーマットの検証原則
- 外部アプリケーションが読み込むファイル形式（XML等）は、実機で検証済みの構造のみを信頼する
- 構造を変更したら必ずスモークプローブ（実機インポート確認）を再実施する
- 「仕様上は正しいはず」を根拠にしない

読み順は ①ショート動画作成ルール.md（構図・テロップ・BGM・尺・宣伝導線の全ルール・最優先）②フック辞書.md（冒頭フックの型）③形式比較KPI.md（形式A〜Fの実測比較）④連番カウンター.md（シリーズ連番の現在値・作成時に更新）。ルールを1枚のSSOTに集約し、AIセッションが毎回同じ基準で制作できるようにしている。

# 作業前に読むSSOT
このフォルダで作業する前に、以下を必ずこの順で読むこと。
1. **[制作ルール].md** — 制作の全ルール。最優先。
2. **[フック辞書].md** — 冒頭フックの型。
3. **[KPI比較].md** — 各形式の実測比較。形式選択の判断材料。
4. **[連番カウンター].md** — シリーズ連番の現在値。作成時に更新。

「トレンド収集/」は config.json 設定の毎朝cronで自動実行されるトレンドスカウト。「維持率観測/」は retention_report.py で YouTube Analytics から維持率レポートを取得する。作った動画の結果を観測し、次の制作にフィードバックするループ構造。

# 実行→観測→修正ループ
コンテンツ制作は作って終わりにしない。以下の観測手段をセットで常設する。
- **トレンド収集**: 毎朝cronで自動実行し、ネタ選定の入力にする
- **成果観測**: [Analyticsツール]から維持率/KPIレポートを定期取得する
観測結果は次回制作の判断材料（形式選択・フック改善）に必ず反映する。

技術説明は README.md / topview_pipeline_spec.md / scripts/README.md。スキル正本は .claude/commands/ の short-video.md（形式A/G）・promo-short.md（形式H）・topview-short-video.md（旧版）。自作スクリプトは scripts/（short_common=共通基盤、make_teaser=形式C、hybrid_composite=形式G、tts=TTSラッパー、promo_assemble=形式H、wipe_composite=形式D）。TopView vendorスキルは .agents/skills/topview-skill/ が実体で、.claude/skills/ と skills/ はそこへのsymlink（日本語訳は README_ja.md）。

形式カタログは形式比較KPI.md。選択肢とコストは Avatar4通常A（約5.3cr）/ ハイブリッドG（約5.3cr・後半本編差し替え）/ フードトーク風B（約31.8cr・Aの約6倍高い）/ 切り抜きティーザーC（¥0）/ ナレーション宣伝H（約5cr+画像$1）。コストと効果を提示した上で人間が形式を選ぶゲートを固定化している。

# 制作方式の毎回確認
コンテンツ生成の前に、必ず方式をユーザーに質問する。
- 選択肢は [方式カタログ].md に実測コスト・実測KPIつきで一覧化しておく
- 例: 方式A（低コスト標準）/ 方式B（高コスト高品質・◯倍高い）/ 方式C（¥0再利用型）
- AIが勝手に方式を決めない。コスト差が大きい判断は人間ゲートとして固定する。

同じキャラの連続使用による視聴者の飽きを防ぐルール。前回使用キャラの記録（メモリ）と突き合わせて選ぶ。男性キャラ選択時はボイスも男性にする運用がメモリ側に補足されている。

# キャラ/スタイルのローテーション
AIアバターや定型ビジュアルを使うシリーズでは、[N]種類をローテーションし、
**前回使用したものを必ず避けて**毎回変える。
前回使用分は記録（メモリ/カウンターファイル）に残し、選定後に更新する。

上22〜28%は背景で埋めて空け、キャラは中央寄りMEDIUMショットに配置する。縦型ショートで上部に固定テロップを載せるため、頭が上端で見切れたり白帯が入ったりする失敗の再発防止ルール。

# 縦型動画用画像のヘッドルーム
テロップを上部に載せる縦型動画の画像生成では、
- 画面上部 [22〜28]% は背景のみで空ける（白帯で埋めるのはNG）
- 被写体は中央〜やや下寄りのMEDIUMショットで、頭を上端で見切らせない
この構図指定を画像生成プロンプトに毎回含める。

根拠はショート動画作成ルール.md §7.5。実装上は spec の title キーで指定する。動画全体を通して上部に固定表示されるタイトルカードで、何の動画かを常時明示する。

リポジトリの正体は「配布用プロダクト」であり、プロンプト資産（.mdスキル）が製品本体。したがってスキル文面・README・設定テンプレの品質管理が最優先事項になる。

# プロンプト資産を製品として扱う
- このプロジェクトは[配布物の種類]を配布するプロダクトであり、**プロンプト資産（.mdスキル）が製品本体**。
- コードではなくスキルの文面・README・設定テンプレの品質がプロダクト品質そのもの、として扱うこと。

validate.shは①設定テンプレのJSON妥当性 ②rootと.claude/commands/の同期ドリフト ③個人情報リーク（禁止語）の3点を検証する。加えて.claude/settings.jsonのPostToolUse hookにより配布ファイル編集時は自動実行される（ハーネス化済み）。

# 配布ファイルの検証ハーネス
- 配布ファイルを編集したら必ず `bash scripts/validate.sh` を実行する。
- validate.sh の検証項目: ①設定テンプレのJSON妥当性 ②マスター↔ミラーの同期 ③個人情報リーク（禁止語スキャン）。
- `.claude/settings.json` の PostToolUse hook で配布ファイル編集時に自動実行させる。
- 禁止語を増やすときは validate.sh の BANNED 配列に追記する。

禁止語スキャンはvalidate.sh内のBANNED配列がSSOT。新たに漏らしてはいけない語（個人名・タグ等）が出たらこの配列に足すだけで以後の検証に反映される。

編集フローは「root を編集 → cp <file> .claude/commands/ で同期」。逆方向（ミラー側編集）を禁止することで配布物と動作確認環境の乖離を防ぐ。同期ドリフトはvalidate.shが検知する。

# 配布マスターとミラーの一方向同期
- root の配布ファイルが**配布マスター**。`.claude/commands/` は動作確認用ミラー。
- 編集は必ず root 側で行い、`cp <file> .claude/commands/` で同期する（ミラー側を直接編集しない）。
- マスター↔ミラーの同期ドリフトは検証スクリプトで自動検知する。

個人利用と配布物を物理的にディレクトリ分離することで混入を構造的に防ぐ。禁止語スキャン（validate.sh）が保険として機能する二重防御。

# 配布物と個人利用の分離
- 配布物に個人情報を含めない（アフィリエイトタグ・個人のスケジュール・個人フォルダのパス・個人名）。
- 個人用の拡張は `personal/` に置き、配布対象から除外する。
- 保険として検証スクリプトの禁止語スキャンでリークを自動検知する。

配布物は購入者が任意の時点で使うため、固定日付は即座に陳腐化・誤動作の原因になる。相対表現にすることで賞味期限のないプロンプトになる。

# 日付ハードコード禁止
- 配布・共有するプロンプトやスキルに具体的な日付・スケジュール例をハードコードしない。
- 「今日の日付」「現在の月」「来週の月曜」等の相対表現で書くこと。
- 理由: 利用者が任意の時点で使うため、固定日付は陳腐化と誤動作の原因になる。

具体仕様: v2はBearer認証／メディアはPOST /v2/social-sets/{SS}/media/upload でupload_urlを取得しcurl -Tで生PUTする2段階（/v2/media/uploadへのmultipartは誤り）／file_nameは英数字のみ（スペース・日本語不可）／publish_atはUTC(Z)記法必須で+09:00は時刻ズレ事故の実績あり／無料プランではpublish_atが配信スロットにスナップするため作成後PATCHで強制する。

# 外部API記述は実機検証済み仕様のみ
- スキル・ドキュメント内の外部API手順は、公式ドキュメントの推測ではなく**実機検証で通った仕様**に合わせて書く。
- 特にタイムゾーン記法（UTC/Z必須か）・ファイル名制約・アップロードの多段手順は事故りやすいので、検証結果と既知の失敗例（例: +09:00指定で時刻ズレ）をCLAUDE.mdに残す。

1タスク=1サイクルで「実行→検証→記録→コミット」を完結させる日次ループ。安定してきたら /loop や schedule（cron）への昇格を検討すると明記されている。

# 日次TODOループ
- `/todo-next` で `TODO.md` の先頭未完タスクを1件実行 → 完了条件を検証 → チェック → 検証スクリプト → git commit までを一気通貫で行う（1日1回が目安）。
- タスクの追加・並べ替えは `TODO.md` を直接編集し、各タスクに必ず【完了条件】を付ける。
- 運用が安定したら /loop や cron スケジュールへの昇格を検討する。

完了条件を明文化することでAIが自己検証でき、「やったつもり」で終わらない。タスク管理をファイル1枚（TODO.md）に集約している。

# タスクには完了条件を必須で書く
- `TODO.md` の各タスクには必ず【完了条件】（検証可能な合格基準）を付ける。
- AIは実行後に完了条件を自分で検証してからチェックを付ける。
- 条件が書けないタスクは粒度が大きすぎるサインなので分割する。

チェック項目: ①bash scripts/validate.sh がgreen ②READMEのセットアップ手順をコピペで完走できるか新規ユーザー視点で通し読み ③CHANGELOG.md更新とgit tag vX.Y.Z ④配布zip生成（将来はscripts/package.sh。root配布ファイルのみ同梱、personal/・.claude/settings.json・scripts/は除外）。

# リリースチェックリスト（配布プロダクト）
- [ ] 検証スクリプトが green
- [ ] README のセットアップ手順を**新規ユーザー視点**で通し読み（コピペで完走できるか）
- [ ] CHANGELOG.md 更新・バージョンタグ（git tag vX.Y.Z）
- [ ] 配布zip生成 — 配布ファイルのみ同梱し、`personal/`・ローカル設定・内部スクリプトは除外

各スキル・youtube_playlist.py・cost_config.json・.claude/verify-works.sh 等がフォルダ名を直書き参照しているため、改名するとスクリプト／スキル／OpenClaw指示書／別マシンが壊れる。README.mdの制作パイプライン表にも「変更禁止 → 理由はCLAUDE.md」と明記されている。

3台のMacで同じGoogle Driveパスを共有する前提のメディア受け渡しレーン。役割は 今回の収録動画=/work-startの入口、完成動画(アップロード)=完成動画置き場、今回のアウトプット=collect-output.shのジョブ別集約先、OpenClaw系=受付・通知係との受け渡し。

収録データ/ はblog-create系の収録コピー先で空でも削除禁止。ショート動画返信/ はinstagram_auto_dmのsync_keywords_from_md.pyがDEFAULT_MD_DIRとして読むため移動不可。ショート動画概要欄/ は2026-07-06監査で実行時参照無しと確認済みだが、当面は保護継続・移動しない。

TODO・作業メモ・引き継ぎは やること/ に「<トピック>_<内容>_YYYYMMDD.md」形式で。設計書・手順書・テンプレは ドキュメント/（全体設計書.htmlと作業ログ.htmlの置き場）。バックアップ・凍結物は _archive/<元の相対パス>/ へ置き、.bakを作業フォルダに残さない。戦略ドキュメントは 運用戦略/ に置き、追加したらREADMEの一覧表に1行追記する。

作業ドキュメントの種類は 提案/実装/引き継ぎ/作業メモ/議論メモ（例: ショート宣伝強化_提案_20260702.md）。収録ジョブIDは下準備・収録動画・ブログ記事フォルダ共通の背番号。「_」始まりフォルダ（_archive・_済み・_テンプレ）はwork-start等が無視する規約。

サブフォルダ側のスキルmdを編集したら bash .claude/sync-commands.sh でrootへ反映（スキルmd編集時はhookが自動実行）。root専用スキル（work-start・youtube-publish等、元ファイルが無いもの）だけはrootを直接編集する。

_現在地.mdはセッション開始時にhookが自動でコンテキストへ注入する「単一の再開入口」。トークン上限が近い・作業を中断するときは、他のチェック項目より先に✍️中断メモ欄へ「何をしていた/どこまで/次の1手」を書いて即コミットする。2026-07-05導入。

Air・mini・スマホから確認できる状態にすることが完成条件。今回のアウトプット/ はDrive symlinkのジョブ別集約先。

エントリ形式は { date, area, title, status: "done|wip|hold", items: [], next: "" }。残タスクがあればnextに書く。追記位置は配列の末尾ではなく先頭。

将来のSenao Botの学習素材とするための蓄積。気づきが無ければスキップ可の唯一の任意項目。

ハンドオフ文書にはフェーズ状況表・ユーザー待ち・▶再開手順・回すべきループを書き（例: やること/動画編集自動化_進捗ハンドオフ_20260705.md）、突然停止しても「ハンドオフを読む→verify系ループ→続きから」が成立する状態を保つ。個別ハンドオフを作ったら_現在地.mdの進行中の作業表からリンクする（_現在地=全体入口1画面、個別ハンドオフ=詳細の2層）。auto-sync hookが保険で動く（開始時pull ff-only／毎ターン未pushの自動push／終了時自動commit+push）が、hookのメッセージは「auto:」なので手動の意味のあるコミットが基本。

毎回ではなく構造変更時限定の条件付き項目。全体設計書.htmlはプロジェクト全体像をブラウザで見る文書、README.mdは全体マップ。

移動・改名後は bash .claude/verify-works.sh "<旧パス名>" で旧パスの残存参照も同時検索する。bash .claude/sync-commands.sh はスキル集約の同期（正本→root反映）。旧daily-pipeline.shは2026-07-06に_archive/.claude/へ退避済みで、定常ループ（トレンド/維持率/コスト）はSessionStartのloop-catchup＋launchdで自動実行（.claude/launchd/README.md参照）。

トークン値: --bg:#f6f2e9(パーチメント地)/--surface:#fffdf8/--surface-2:#f0ead9/--ink:#241f18/--ink-soft:#5c5346/--ink-faint:#8a7f6d/--line:#e2d9c6/--line-soft:#ece4d4/--accent:#b9791a(アンバーゴールド主アクセント)/--accent-ink:#8a5a10/--accent-bg:#f6e7cd/--teal:#2f6f68(副色・見出し/リンク)/--code-bg:#26221b/--code-ink:#ece3d2/--shadow: 0 1px 2px rgba(40,32,18,.05), 0 8px 30px rgba(40,32,18,.06)/--radius:14px。フォントは--font-jp(Hiragino Kaku Gothic ProN等)と--font-mono(SFMono-Regular等)。コードブロックだけ暗背景＋明文字、ゴールド＋ティールの2色アクセントを守り、紫/青の原色は避ける（使うなら沈んだトーン）。見本= 下準備/Routine Labo/20260703_Fable5準備5選/LINE配布_Fable5重タスクプロンプト完全版.html

2026-07-04に.gitignore監査済み。キー名の一覧はAPI_CATALOG.md（値は書かない）、キーの地図は.env.example（コミット可）。非秘密の運用パラメータは共通設定.mdに置く。

Playwright系は3.14だとドライバが落ちるため3.12固定。AI_prompt(Auto)のvenvはactivateが破損しているため、activateせず ./venv/bin/python3.14 を直接実行する。

引数=ジョブID(省略時は最新フォルダ)。鉄則=hubの生成物は絶対削除しない(配布は常に複製・hub=バックアップ兼正本)。質問はStep1の1回に集約。承認済みショートは/youtubeshort-publishへも連鎖可。

引数=省略で全部実行、"blog"/"cut"/"short"/"xreview"で部分実行、動画名指定可。frontmatterでmodel: claude-opus-4-8に固定(2026-07-03方針)。冒頭Step0で全質問を聞き切り、以降ゴールまで追加質問なしで自動進行。

引数=トピック名(例 DomoAI)または空(動画名から自動推測)。SNS発信用コンテンツは含まず、YouTube URL確定後の/blog-snsに委ねる。エラー時はその時点で停止・報告。

00_一括実行.mdの「第1段階」に準拠。文字起こしは cd "AI_prompt(Auto)" && python blog_transcribe.py、記事は01_記事作成プロンプト.mdに従いGutenberg(Sangoテーマ)形式で生成。

引数=記事フォルダ名(例 20260409 DomoAI)または空(Blog_RoutineLabo直下のYYYYMMDD最新フォルダ自動検出)。対象は*記事完成.md。X/note自動投稿・採点・アフィリエイト誘導文まで含む第2段階。

前提=/blog-create-site2完了＋投稿画像/AIの教科書/今回の差し込み画像/に画像配置。画像変換は blog_image_automation.py <記事> step3。最新記事フォルダを自動検出。

引数=入力動画パス。input/存在確認→npm install→.envのOPENAI_API_KEY/GEMINI_API_KEY確認→config/bgm/からBGM選択質問→レンダリング。

引数=入力動画パス。無ければnpm run preprocessで生成。角括弧[#番号 開始-終了]の変更・行の追加/削除/並び替えは禁止(テキスト部分のみ編集)。修正完了後は/edit-mainへ。

引数=[routinelabo|aibook]<ツール名/ねらい>。下準備/keyword_research/の無料サジェスト＋/deep-researchでKW確定→SEO設計.mdに記録し下流(blog-create/概要欄/目次)と表記統一。②スライドには裏側の都合(CTA/LINE導線等)を一切含めない。

引数=入力動画またはbasename。npm run archive -- で実行、出力=output/edit/<basename>.zip。/video-export-edit未実行なら先に案内して停止。元フォルダは削除しない。

npm run cleanup -- で実行し削除容量を報告。再処理時はWhisper/Bロール生成のAPIコストが再発生する旨を案内。output/配下や他動画のwork/は絶対に削除しない。

引数=input/xxx.mp4。停止はStep1.5の冒頭一括質問(AskUserQuestion 1回3問)とStep4dのナレーション提案時のみ。テロップテーマ制(config/style.jsonのtelop.themes・既定tech_navy)。出力=output/edit/<name>/(timeline.xml/subtitles.srt/markers/cut_report.md等)。要OPENAI_API_KEY(Whisper)。

引数=入力動画パス。npm run export-edit -- で実行。/video-finish(焼き込み版)とは独立。transcript_edit.mdの手動修正が反映される。

引数=入力動画パス。前提=work/<name>/transcript.jsonとtranscript_edit.md(/video-start済み)。編集が一切無い場合のみ1度確認。BGM選択を挟む。

npm run listを実行して結果を表示・補足。クリーンアップしたい動画があれば/video-cleanup <name>を案内する。

引数=入力動画パス。input/存在確認→.envのOPENAI_API_KEY/GEMINI_API_KEY確認→preprocess実行。ユーザーがtranscript_edit.mdを修正後、/video-finishへ進む前提。

引数=<動画パス> [本数](省略時2本)。npm run short -- で実行、preprocess/jetcutはキャッシュ再利用。出力=output/shorts/<name>_short*.mp4、選定理由はwork/<name>/highlights.jsonから提示。

引数=食材名。.claude/skills/food-talk.mdのフローに従い、台本承認で1回だけ停止→承認後はキャラ画像3枚→Avatar4リップシンク3本→ffmpeg結合まで全自動。30秒結合版＋個別クリップを出力。

TTS=scripts/tts.py(topview text2voice 0.1cr/件)、Bロール=GPT Image静止画+Ken Burns基本＋見せ場のみSeedance i2v、組み立て=scripts/promo_assemble.py(純ffmpeg)。コスト目安≈5cr+画像$1弱。固定トップタイトルカード標準。

台本前にAskUserQuestionで形式を必ず確認: A=Avatar4通常(≈5.3cr)/G=ハイブリッド/B=フードトーク(→/food-talk)/C=ティーザー(make_teaser.py)/H=ナレーション宣伝(→/promo-short)。形式G/HはBGM＋SE既定ON(scripts/audio_fx.py)。入力=テーマまたは本編動画の2モード。

入力=テーマ入力モードA(Web検索で3選自動選定)または本編動画モード。ショート動画作成/配下がカレントディレクトリ前提(ルートから呼ぶ場合は cd "ショート動画作成" が必要)。

引数=[routinelabo|aibook][動画ファイル名(省略可)]。入力=完成動画(アップロード)/のサイト別サブフォルダ、サイト未指定時はどちらに動画があるかで自動判定。目次.mdを同フォルダに保存。

引数=入力動画パス。前提=work/<name>/transcript.jsonとcut_plan.json(無ければ/video-start・/video-finishを案内)。npm run youtube -- で実行、Geminiが生成し出力=output/edit/<name>/youtube.md。

引数=記事フォルダ名/YouTube URL/空(最新自動検出)。差し込み先はタグ情報.md・R6_記事インデックス.mdから自動取得。WP=REST更新、note=note_auto_publisher/note_video_embed.pyのブラウザ操作。note URLは初回タイトル照合で自動取得し索引に保存。

対象=指定フォルダまたは2026 ブログ記事/内の最新フォルダ。記事完成.md・文字起こし.md・タグ情報.mdを読み込み、AI_prompt(Auto)/03_YouTube_SEO情報.mdのルールで生成。タイトルは40〜60文字。

引数=[routinelabo|aibook][動画ファイル名(省略可)]。/make-tocと/youtube-uploadの合体。チャプターは手元mp4からGroq Whisperで実測(アップ前に目次確定)。公開・予約は人間がYouTube Studioで行う。

エンジン=GPT Image 2.0(ai_image_gpt.py・1792x1008・quality high・AI_IMAGE_CMDで切替可)。既定デザイン=design4(感情訴求型)・--design Nで切替。実体=サムネイル資料/プロンプト参考/thumbnail_generator.py、検品=thumb_verify.py。キャラは毎回ローテーション(--charで前回と別キャラ指定)。

引数=完成動画パス(任意・未指定なら完成動画(アップロード)/等から確認)。実体=YouTube自動投稿/youtube_upload.py、メタ情報はYouTube構成案・概要欄.mdから自動抽出。鍵は~/.config/youtube-upload/(Drive同期外)に配置済みが前提。

引数=動画ファイル名(省略時は完成動画(アップロード)/ショート動画/直下の最新)。YT=youtube_upload.py --shorts --privacy public、TikTok=SNS自動投稿/tiktok_upload.py、IG=wp_video_upload.py＋instagram_reels_upload.py --mode url、LINE=register_keyword.py(Step4.7)。YT/IGは即ライブなのでStep3.5でタイトル/概要を必ず目視。通常は/output-approveが承認済みショートを配置してから呼ぶ。

引数=フォルダ名または空(最新フォルダ自動検出。/blog-finishアーカイブ後は年別フォルダも検索)。/blog-create→/blog-finish→YouTube投稿→本スキルの流れの最終段階。Discord Webhook自動投稿(STEP2.8)も連動。

引数=XポストURL(翻訳モード・FxTwitter APIで取得)またはテキスト(独自投稿モード)。引用リポスト風コメントは言い切り/インフルエンサー調のスタイルルールあり。

引数=キーワード(任意・例 "OpenAI")。Bright Data MCPでXの実エンゲージメント上位5件を実数ベースで取得(未接続時はWebSearchのみ)。Typefully Creatorプラン・1日3件がアルゴリズム最適値。

引数=SNS共有投稿のmdパス(例 SNS共有投稿/20260331 YouWare.md)または空(フォルダ内最新を自動選択)。SNS共有投稿作成.mdのテンプレ形式(タイトル+✅ポイント)前提。

引数=ツール名と機能説明(音声入力テキスト)。動画は X Post/動画アップロード/ 直下の.mp4/.movを自動検出。Web検索でツール情報を補完し統一スタイルで作成。

引数=記事フォルダ名/本編URL/空(最新自動)。本編URLをStep0で1回だけ確定し二重に聞かない。本編が非公開ならSTEP1(SNS発信用生成)のみで停止→公開後の再実行でSTEP2が冪等に進む。/blog-sns・/video-embed本体は壊さず順に呼ぶだけ。/youtube-publish Step6の自動連鎖と同内容の手動入口。

引数=[配信日YYYY-MM-DD省略可][実使用ツール(🟢用・任意)]。Bright Data MCP主軸の5観点並行調査→Blog_メンバーシップ/週報/<配信日>/に①台本②スライド資料を出力。週報_フォーマット.md準拠、🟢実体験/🟡ニュースの2モード・出典付き・盛らない。

引数=<ツール/プロジェクト名> | <なぜ良かったか(任意)>。型=前の困りごと→見つけた→どう変わった→誰に効く。🟢は実際に使ったものだけ・盛らない・機微情報は出さない。週次メンバー配信フォーマット.md準拠。

引数=<プロジェクトのフォルダパス(必須・例 /Users/senao/VideoEditor)>[回番号][配信日]。出力=Blog_メンバーシップ/プロ限定_開発と収益化/第NN回_<名>_<日付>/。機微情報は出さない・未公開数字は「設計値」明記。

引数=--target <yt|member> <HTMLパス> [slug]。実体=共有ページ/publish_share.sh。memberはslugにランダム付与で推測回避。業者向けは別コマンド bash 共有ページ/publish_vendor.sh pr-<vendor> <html>(Cloudflare Pages・案件ごと独立)。公開前に裏側情報の有無を必ず目視確認。

トリガーはSessionStart（timeout 30秒）。`auto-commit-push.sh pull` として実行され、mainブランチ以外・マージ/リベース中・gitリポ外では何もしない安全装置つき。失敗しても常にexit 0でセッションをブロックしない。

トリガーはSessionStart（timeout 10秒）。`$CLAUDE_PROJECT_DIR/やること/_現在地.md` が存在すれば「🧭 作業再開ポイント」ヘッダ付きで全文出力し、単一の再開入口として機能する。作業終了チェックリスト項目0でこのファイルを更新する運用とセット。

トリガーはSessionStart（timeout 20秒）。findで.git/node_modules/venvを除く全symlinkを走査し、リンク切れがあれば「⚠⚠⚠ symlink切れを検出」とリンク先つきで出力。Drive側フォルダ誤削除で7本切断されたインシデント（2026-07-05）を契機とした観測ループ。

トリガーはSessionStart（async・timeout 30秒）。trendは今日のレポートが無ければ実行など鮮度判定つきのanacron方式で、launchdがTCC未付与で動けない環境でも「Macを開いた日は必ずループが回る」主経路。launchdは無人日カバーの補完扱い。

トリガーはPostToolUse（matcher: Edit|Write、timeout 60秒）。正本（プロジェクト側）編集→sync自動実行、root集約コピーを直接編集した場合は「次のsyncで上書きされて消える」警告を出す。対象外ファイルの編集では即終了する軽量設計。

トリガーはStop（async・timeout 60秒）。`auto-commit-push.sh push-only` で未pushコミットの有無だけ確認してpushする。コミット作成は行わないため、意味のある手動コミットが基本という運用と両立する。

トリガーはSessionEnd（timeout 90秒）。`auto-commit-push.sh full` として実行。機械的なコミットメッセージになるため、あくまで保険であり手動の意味あるコミットが優先という位置づけ。なお .claude/settings.json にはhooksのみで、permissionsセクションは定義されていない。

run-job.shラッパ経由で実行され、ログは .claude/launchd/logs/trend.log、非0終了時はnotify.shでDiscord警告。~/DownloadsのTCC保護のため /bin/bash へのフルディスクアクセス付与が有効化条件（未付与だとOperation not permitted）。手動発火は `launchctl kickstart -k gui/$(id -u)/com.senao.works.trend`。

run-job.sh経由でlogs/retention.logへ記録・失敗時Discord通知。launchdはMacスリープ中は発火せず起動後に持ち越し実行（cronと違い取りこぼさない）。TCC未付与時はSessionStartのloop-catchup.shが代替経路。

run-job.sh経由でlogs/costs.logへ記録・失敗時notify.shでDiscord警告。Python標準ライブラリのみで動く設計（venv不要）。登録/更新は `bash .claude/launchd/install.sh`（冪等）、解除は `--uninstall`。

「実行」と「実行されなかったことの観測」を分離する番犬。監視6点＝①今日のtrendレポート有無 ②retentionが8日以内 ③cost_data.jsonが32日以内 ④symlink切断（check-symlinks.sh） ⑤origin/mainより先行の未pushコミット ⑥YouTube公開済なのにWP/note未埋込の記事（embed_gap_check.py）。正常時は無音、手元実行は `bash .claude/launchd/watchdog.sh`。

使い方は `run-job.sh <ジョブ名> <作業dir> <コマンド...>`。出力を .claude/launchd/logs/<ジョブ名>.log に追記し、非0終了なら .claude/scripts/notify.sh でDiscordへ警告（サイレント失敗の撲滅）。launchdの最小PATH問題対策でhomebrewをPATH先頭に追加する。

使い方は `bash .claude/scripts/notify.sh "⚠️" "本文"`。DISCORD_WEBHOOK_URLは環境変数＞中央.envの順で解決し、通知自体の失敗では絶対にブロックしない（常にexit 0）。2026-07-06ループ監査で「失敗が人間に届く経路ゼロ」と判明したことを受けて新設された観測の脚。

旧DRY_RUN daily-pipelineの後継。チェック内容＝①中核スクリプトのマニフェスト全数 test -e ②Drive symlink 7本の生存（check-symlinks.sh流用）③スキル集約ドリフト等。使い方は `bash .claude/verify-works.sh`、移動・改名後は `bash .claude/verify-works.sh "旧パス名"` で残存参照も検索できる。

正本は各プロジェクト側で、rootは生成先（元ファイルは一切書き換えない）。各コピー先頭に `<!-- 集約元: <相対パス> -->` を付与し、frontmatterがある場合は終了---直後に挿入。root専用スキル（元がないもの）は削除しない。手動実行のほか、post-edit-sync-commands.sh hookから自動実行される。

使い方は `bash .claude/collect-output.sh <ジョブID> <工程サブフォルダ> <コピー元...>`。元の保存先は残したままコピーし、Air・mini・スマホから確認できる状態にするのが完成条件。ユーザー確認・公開後に手動削除する運用。

hub側は絶対に削除しない（複製のみ・バックアップ扱い）、配布先の既存ファイルは上書きしない（手動差し替えが常に勝つ・冪等）が2大原則。配布内容＝①差し込み画像→投稿画像/<サイト>/今回の差し込み画像/ ②サムネ→アイキャッチ画像/ ③アップ用JPG→完成動画(アップロード)/<サイト>/（youtube-publishのサムネ自動検出が拾う）。

再生成は python3 "ドキュメント/進捗ボード/_build_board.py"（標準ライブラリのみ・1〜2秒）。Stop/SessionStart hook の regen-board.sh が作業が進むたび自動再生成（120秒ガード）し、ページ自体も60秒ごと自動リロード＝開きっぱなしでライブ表示。12工程中11工程は実ファイルで全自動判定、ショート公開のみ overrides.json に手動記録（done/skip/_archived）。判定スナップショットは board_data.json。macOSのNFD正規化とDrive symlinkに対応。デザインは_デザインサンプル.htmlの暖色トークン準拠。

_build_site.pyがビルド前に毎回自動実行するため、他プロジェクトでスキルが登録されると次のビルドで設定ハブの🗺️セクションに自動反映される。node_modules/venv等は除外・深さ3制限。regen-hub.sh(Stop/SessionStart hook)で無人更新。2026-07-07新設。

起動= python3 "AI Office/server/office_server.py" → http://localhost:4780（UI=office_page.html・再起動なしで編集反映）。3カラム=指示センター(送信履歴・配達状況)/オフィス/社員詳細+フィード。データ源=~/.claude/projects/*.jsonl末尾解析(読み取りのみ)。承認待ち推定=最終イベントがtool_useのまま75秒超。指示配達=office_inbox+グローバルStop hook(asyncRewake)。アセット再生成=assets_gen.py(gpt-image-2・スプライトはマゼンタ背景→PILクロマキー透過)。キャラ割当=office_config.jsonのsprite。標準ライブラリのみ。

標準ライブラリのみ・http://localhost:4788。http経由で開くとEventSourceで版変化の瞬間だけreload(無変更時リロードせずチラつきなし)、file://は従来60秒にフォールバック。多重起動しない。ポート=BOARD_PORT・ログ=.server.log。

実行は `bash 共有ページ/publish_share.sh --target yt <html> <slug>` またはスキル `/share-html --target yt`。URLは `https://senao-routine.github.io/yt-share/<slug>.html` で配布前提の完全公開。載せるHTMLは画像data URI等の自己完結が前提で、公開取り消し後もキャッシュに残り得るため機密は載せない。

実行は `bash 共有ページ/publish_share.sh --target member <html>` でslugに自動でランダム文字列を付与（URL推測回避）。ただしgithub.com側でリポの中身自体は見えるため、秘密度が高いものは③業者向けの独立入れ物へ回す。ルートに一覧index.htmlを置かず、勝手に全ページを辿らせない設計。

実行は `bash 共有ページ/publish_vendor.sh pr-<vendor> <共有用HTML>` → `https://pr-<vendor>.pages.dev/`（wranglerアカウント=routinelabo_senao・無料）。GitHub公開リポだとアカウントのリポ一覧で「複数社とPR中」がバレる＋git履歴は消えないため、案件ごと完全分離を構造で担保（削除は任意: `wrangler pages project delete pr-<vendor>`）。業者向けは必ず裏側なしの共有用版にしつつPR/提供表記は残す（景表法/ステマ規制）。初弾実績=pr-hi3d。

①タスク完了→HTML（チャット貼付） ②プロジェクト全体→HTML（一撃）の2プロンプト＋レベル1(CLAUDE.mdに数行)/レベル2(regen-preview.sh=120秒ガード・常にexit0のStop hook自動再生成)。実配線のregen-board.shを汎用化。works共通パレット・4タブ・全プロンプトにコピーボタン。publish_share.sh --target yt でGitHub Pages公開。

引数=レポートのテーマ/対象/空。:rootトークン(パーチメント地+アンバーゴールド+ティール)と部品CSS(カード/kicker/表/状態バッジ/進捗バー)を雛形として内包。外部CDN/フォント禁止・自己完結・レスポンシブ。works内はHTMLプレビュー運用+設定ハブ統合に従い、他プロジェクトはreports/へ。正本パレット=共有ページ/HTMLプレビュー/_デザインサンプル.html。

/x-research Step2.5の注目投稿トップ5収集と/ai-weeklyの情報収集の主軸。search_engine・scrape_as_markdown・web_data_x_posts等80超のツールを提供。トークンは~/.config/brightdata/tokenで管理。

note/X等のログイン済みセッションを使った確認作業や、Web UIしかない設定画面の操作に使用。GIF録画機能もあり。

text-to-video・image-to-video・シーン生成・プロダクトシート生成・動画ダウンロード(yt-dlp)まで1パッケージ。クレジット残高はstatusLine表示に対応。

performance-engineer（プロファイリング/キャッシュ戦略）とload-testing-specialist（負荷テスト設計）。Webアプリ開発案件で使用。

KPI追跡・収益分析・ロードマップ策定用。戦略ドキュメントの壁打ち相手として使用。

Workers・Pages・KV・D1・R2などCloudflare開発全般をドキュメント参照ベースで支援。LINE自動応答bot(Workers)や業者向け共有ページ(Pages)の構築で実使用。

白背景＋方眼グリッド＋ピンク#e02fd0→紫#8b3bf2→青#2f6bff グラデの高品質デザイン。テンプレのCSS/JSエンジンは完動品で改変禁止・中身の.slideだけ差し替える設計。references/design-system.mdにパーツカタログとパターン10種。X投稿/セミナー/告知動画向け。成果物の置き場=works直下スライド制作/<YYYYMMDD_テーマ>/(HTML/PDF/MP4の3点セット・PDF/MP4はPlaywright venvで決定論的レンダリング)。2026-07-07導入(X記事「Fable5使ったらクオリティ高すぎて」経由・zipハッシュ照合とコード検品済み・外部通信はGoogle Fontsのみ)。