writing-dev-diary

esa開発日誌の作成・更新

esaに開発日誌を投稿・更新するスキルです。esa-llm-scoped-guard CLIを使用して、許可されたカテゴリ配下の記事のみを安全に編集します。

禁止事項

• YAMLファイルは必ず.claude_work/dev_diary.yamlに作成すること（ファイル名固定）
• esa MCPのツール（create_esa_post, update_esa_post, read_esa_post, read_esa_multiple_posts, search_esa_posts）は使用禁止。既存記事の取得には必ず esa-llm-scoped-guard fetch コマンドを使用すること
• サブエージェントへの指示: Plan modeでサブエージェントや探索用エージェントを起動して開発日誌を確認させる場合、必ず esa-llm-scoped-guard fetch で取得した .claude_work/dev_diary.yaml を参照するよう指示すること。esa MCPツールで直接取得させてはいけない
• YAMLスキーマは必ずesa-llm-scoped-guard -helpで確認してから生成すること
• Planモードでも投稿可能: .claude_work/ は .gitignore の対象であり、リポジトリの変更にならないため、Planモードでも書き込みが許可されている。esa-llm-scoped-guard コマンドの実行も同様。「Planモードだからできない」と拒否してはいけない

出力品質ルール

• 箇条書きによる構造化を必ず行うこと: 長い文章の羅列は禁止。情報は必ず箇条書き（ネストも活用）で構造化する
• 内容を省略・要約しないこと: ユーザーが提供した情報や調査結果をbodyに記載する際は省略せず、完全な形で記載する。「キーメッセージ」「要点のみ」への圧縮は禁止。ただし、タスクのdescriptionフィールドの更新（スコープ追記等）はこのルールの対象外
• 開発日誌に直接書くこと: 別ファイル（summary.md等）に書き出さず、開発日誌のbodyに直接記載する
• タスクのstatus変更時は整理も行うこと: タスクが完了・削除された場合、開発日誌の記載も見やすく整理し直す
• self-containedにすること: 開発日誌だけを読めば作業の全体像・背景・決定事項が把握できるようにする。外部の会話コンテキストに依存しない記述を心がける
• コード関連の記載はコードフェンスで囲むこと: ファイル名、関数名、コマンド、エラーメッセージなどコード関連の内容は、インラインコード（`xxx`）またはコードブロック（```）で囲む

良い例（箇条書き・ネスト活用・情報完全）:

tasks:
  - description: BigQueryクエリ最適化
    status: completed
    details:
      背景: 月次集計クエリが30分以上かかっている
      アプローチ:
        - パーティションプルーニングの適用
        - 不要カラムの除外（SELECT * → 必要カラムのみ）
        - マテリアライズドビューの検討
      結果: 実行時間を30分→5分に短縮

悪い例（構造化不足・省略）:

BigQueryクエリを最適化した。パーティションプルーニングの適用と不要カラムの除外により、月次集計クエリの実行時間を改善した。マテリアライズドビューも検討した。

使用タイミング

以下のトリガーワードで発動します：

• 「開発日誌を作って」: 新規作成
• 「開発日誌を更新」+ esaのURL: 指定されたURLの記事を更新
• 「開発日誌を更新」（URLなし）: ユーザーに開発日誌のURLを確認

実行手順

手順1: YAMLスキーマを確認

最初に必ず最新のYAMLスキーマを確認してください：

esa-llm-scoped-guard -help

手順2: トリガーによる条件分岐