メニュー
「開発日誌更新」「開発日誌作って」の言及時に使用。esa-llm-scoped-guardで開発日誌を新規作成・更新します。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
調査、裏取り、検証、コードリーディング、外部URL確認、GitHub PRやIssue確認、BigQueryなどのコマンドやクエリ実行を行う際に自動的に使用。清書用ドキュメントとは分離して、.agent_work/investigations/ にエージェント向けの内部調査ログを根拠URL、実行コマンド、クエリ、結果、未確認事項つきで残します。
Devin CLIから /handoff でDevin Cloudにタスクを引き継ぐ際に発動。ハンドオフ先のDevin Cloudに対して、タスクの実行をCursor Cloud Agentに委譲するよう指示を含める。
Cursor Cloud Agentにタスクを委託するよう依頼された際に発動。エージェント作成、SSEストリーム監視（stream）、実行キャンセル（cancel）、ステータスポーリング（フォールバック）、Pull Request状態確認、Linear紐付け、レビュー・フォローアップを行う。
Linearに大きなタスクを複数のIssueに分割して作成する際に使用。新しいプロジェクトを作成し、その中にフラットなIssueを作成し、依存関係はblockedByリレーションで表現する。
planモードの計画に基づいて実装を開始する。planファイルからタスクリスト作成→タスク順次実行→各タスク完了時にコミット→最後にcodex-reviewを実行する。
planファイルのレビューを依頼された際に使用。Codex CLIを使ってplanファイル自体の実現可能性・技術的妥当性・抜け漏れをレビューし、指摘をタスクリスト化して収束するまで繰り返します。
| name | writing-dev-diary |
| description | 「開発日誌更新」「開発日誌作って」の言及時に使用。esa-llm-scoped-guardで開発日誌を新規作成・更新します。 |
| compatibility | Requires esa-llm-scoped-guard and gh (GitHub CLI) |
esaに開発日誌を投稿・更新するスキルです。esa-llm-scoped-guard CLIを使用して、許可されたカテゴリ配下の記事のみを安全に編集します。
.claude_work/dev_diary.yamlに作成すること（ファイル名固定）create_esa_post, update_esa_post, read_esa_post, read_esa_multiple_posts, search_esa_posts）は使用禁止。既存記事の取得には必ず esa-llm-scoped-guard fetch コマンドを使用することesa-llm-scoped-guard fetch で取得した .claude_work/dev_diary.yaml を参照するよう指示すること。esa MCPツールで直接取得させてはいけないesa-llm-scoped-guard -helpで確認してから生成すること.claude_work/ は .gitignore の対象であり、リポジトリの変更にならないため、Planモードでも書き込みが許可されている。esa-llm-scoped-guard コマンドの実行も同様。「Planモードだからできない」と拒否してはいけない`xxx`）またはコードブロック（```）で囲む良い例（箇条書き・ネスト活用・情報完全）:
tasks:
- description: BigQueryクエリ最適化
status: completed
details:
背景: 月次集計クエリが30分以上かかっている
アプローチ:
- パーティションプルーニングの適用
- 不要カラムの除外（SELECT * → 必要カラムのみ）
- マテリアライズドビューの検討
結果: 実行時間を30分→5分に短縮
悪い例（構造化不足・省略）:
BigQueryクエリを最適化した。パーティションプルーニングの適用と不要カラムの除外により、月次集計クエリの実行時間を改善した。マテリアライズドビューも検討した。
以下のトリガーワードで発動します：
最初に必ず最新のYAMLスキーマを確認してください：
esa-llm-scoped-guard -help
| トリガー | URL確認 | 次の手順 |
|---|---|---|
| 「開発日誌を作って」 | 不要 | 手順4（新規作成） |
| 「開発日誌を更新」+ URL | URLあり | 手順3（更新） |
| 「開発日誌を更新」（URLなし） | ユーザーに確認 | URL取得後、手順3または手順4 |
新規作成モードで、手順4（YAML更新）へ直行してください。
ユーザーが提示したesaのURLからpost_numberを抽出（例: https://yasuhisa.esa.io/posts/123 → 123）
手順3（YAML取得）へ進む
ユーザーに質問して、開発日誌のURLを確認：
URLが提供された場合:
post_numberを抽出新規作成を選択した場合:
目的: 既存記事からYAMLを取得し、差分ゼロの状態を作る
fetchコマンドで既存記事からYAMLを直接取得：
esa-llm-scoped-guard fetch -post <post_number> | tee .claude_work/dev_diary.yaml > /dev/null
fetch成功の場合: YAMLが取得できたので、そのまま手順4へ進む（差分ゼロ確認は不要）
fetch失敗の場合: 古い形式（YAML埋め込みなし）の記事のため、更新はできません。ユーザーに以下を報告してください：
esa-llm-scoped-guardでの更新ができませんWriteツールで.claude_work/dev_diary.yamlを作成（ファイル名固定、常に上書き）
YAMLの構成内容：
create_new: trueを指定、post_numberは含めないcategory: Claude Code/開発日誌/yyyy/mm/dd形式（今日の日付）name: 日付ベースのタイトルbody: 会話コンテキストから抽出したタスク情報を構造化形式で作成手順3で取得したYAMLに変更を加える（Editツール使用）
category、name、post_numberは維持すること（create_newは含めない）GitHub URL状態の確認と反映:
a. body.tasksからgithub_urlsを抽出（URLがなければスキップ）
b. 各URLの状態と内容をgh CLIで確認
PRの場合:
gh pr view <URL> --json state,isDraft,title,body
Issueの場合:
gh issue view <URL> --json state,title,body
c. に従ってGitHub状態を判定
d. に従ってタスクstatusを更新
e. タスクdescriptionの更新要否を判定（参照）
以下のいずれかに該当する場合、タスクdescriptionを更新：
| 判定条件 | 説明 |
|---|---|
| タイトル差分 | GitHubタイトルがタスクdescriptionと実質的に異なる（スコープの追加・削除） |
| 本文の追加スコープ | bodyに、タスクdescriptionにない追加機能・領域が記載されている |
| 前提/実装変更 | bodyに前提や実装アプローチの変更が記載されている |
更新内容の形式：
validateで形式確認：
esa-llm-scoped-guard validate -yaml .claude_work/dev_diary.yaml
diffで差分が意図通りか確認：
esa-llm-scoped-guard diff -yaml .claude_work/dev_diary.yaml
+で表示される（全体の最終確認）ユーザーの承認後、投稿を実行：
esa-llm-scoped-guard post -yaml .claude_work/dev_diary.yaml
| リソース | 条件 | 判定結果 |
|---|---|---|
| PR | state=MERGED | マージ済み |
| PR | state=OPEN, isDraft=true | ドラフト（WIP） |
| PR | state=OPEN, isDraft=false | レビュー中 |
| PR | state=CLOSED | クローズ |
| Issue | state=OPEN | オープン |
| Issue | state=CLOSED | クローズ済み |
| GitHub状態 | タスクstatus |
|---|---|
| PRがマージ済み | completed |
| PRがドラフト（WIP） | in_progress |
| PRがレビュー中 | in_review |
| PRがクローズ（マージなし） | （変更なし） |
| Issueがクローズ | completed |
| Issueがオープン | （変更なし） |