writing-dev-diary

Files (1)

• SKILL.md

SKILL.md (first lines)

# esa開発日誌の作成・更新

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

## 禁止事項

<important>

- 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モードだからできない」と拒否してはいけない

</important>

## 出力品質ルール

<important>

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

</important>

<examples>

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

**悪い例（構造化不足・省略）**:
```yaml
BigQueryクエリを最適化した。パーティションプルーニングの適用と不要カラムの除外により、月次集計クエリの実行時間を改善した。マテリアライズドビューも検討した。
```

</examples>

## 使用タイミング

<trigger>

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

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

</trigger>

## 実行手順

<procedure>

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

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

```bash
esa-llm-scoped-guard -help
```

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

<decision-criteria name="trigger-flow">

| トリガー | URL確認 | 次の手順 |
|----------|---------|---------|
| 「開発日誌を作って」 | 不要 | 手順4（新規作成） |
| 「開発日誌を更新」+ URL | URLあり | 手順3（更新） |
| 「開発日誌を更新」（URLなし） | ユーザーに確認 | URL取得後、手順3または手順4 |

</decision-criteria>

#### パターンA: 「開発日誌を作って」の場合

新規作成モードで、**手順4（YAML更新）へ直行**してください。

#### パターンB: 「開発日誌を更新」+ URLの場合

1. ユーザーが提示したesaのURLから`post_number`を抽出（例: `https://yasuhisa.esa.io/posts/123` → `123`）

2. **手順3（YAML取得）へ進む**

#### パターンC: 「開発日誌を更新」（URLなし）の場合

1. ユーザーに質問して、開発日誌のURLを確認：
   - 質問: 「更新する開発日誌のURLを教えてください」
   - 選択肢:
     - 「URLを提供する」→ ユーザーからURL入力を受け取る
     - 「新規作成する」→ 新規作成モード（手順4へ）

2. URLが提供された場合:
   - URLから`post_number`を抽出
   - 更新モードで**手順3へ**

3. 新規作成を選択した場合:
   - 新規作成モードで**手順4へ**

### 手順3: 既存記事のYAML取得（更新時のみ）

**目的**: 既存記事からYAMLを取得し、差分ゼロの状態を作る

#### 3.1 fetchコマンドで埋め込みYAMLを取得

From syou6162/agent-skills, MIT.

More from syou6162/agent-skills