dev-journal

name	dev-journal
description	実装中の設計上の気づき・疑問・バックログ送りにしたタスクを spec/dev-journal.md に記録するスキル。USE WHEN: ユーザが「ジャーナルに書いて」「メモしておいて」「dev-journal に追記して」「これ記録して」「あとで見返せるようにして」「バックログに入れて」「後回しにしたい」など、実装中の気づきや先送りタスクの記録を依頼したとき。spec/dev-journal.md を読み書きするときは必ず参照すること。

開発ジャーナルスキル

実装中に発生する設計上の気づき・疑問・バックログ送りタスクを spec/dev-journal.md に時系列で蓄積するスキル。 仕様書にするほどでもないが、後から振り返れるようにしておきたい情報の置き場として使う。

ファイル配置

• 記録先は spec/dev-journal.md の 1 ファイルに集約する
• ファイルが存在しない場合は新規作成する (初期内容は後述)
• テーマが膨らんで独立した設計判断が必要になった場合、該当エントリを削除し spec-format スキルで仕様書に昇格させる

エントリ形式

## YYYY-MM-DD: {タイトル}

### 現状

{現在の実装・設計がどうなっているか}

### 観察

{何が問題か、何を改善できるか}

### 方針

{対応策・回避策、または先送りの判断理由}

• エントリ見出し: H2 (##) + 日付 (ISO 8601) + タイトル
• 本文ラベル: H3 (###) で 現状 / 観察 / 方針 の 3 セクションを立てる
• タイトル: 対象と論点が一読で分かる表現にする (例: edge アルゴリズム切替時のメッシュ再生成コスト)
• 新しいエントリを既存エントリの末尾に追記する (時系列順)

記述内容

各セクションは一文で済むなら一文でよい。エントリ全体で 10 行以内を目安にする。

バックログ送りのタスクも同じ形式で書く。「方針」に先送りの理由と再検討の条件を記載すると、後から拾いやすくなる。

同一テーマの追記

同じテーマで進展があった場合は、新しいエントリとして追記する。その際、前回エントリを 前回: YYYY-MM-DD タイトル として本文冒頭 (最初の H3 の前) に記載すると追跡しやすい。

記述規約

• 事実ベースで書く。主観的評価 (「良い設計」「微妙」など) は避ける
• コード例やデータ構造は言語指定付きコードブロックで記載する
• 関連する仕様書・ソースファイルへのパスを含める

書かないこと

• 実装手順や TODO リスト (それは仕様書のチェックリストに書く)
• 議論の経緯 (結論と根拠のみ記録する)
• 装飾や絵文字

ワークフロー

1. spec/dev-journal.md の存在を確認する。なければ初期テンプレートで作成する
2. 既存エントリを読み、同一テーマがないか確認する
3. 同一テーマがあれば新規エントリで参照しつつ追記する。なければ新規エントリを末尾に追加する
4. communication.instructions.md の記述規約に従って本文を記載する

初期テンプレート

ファイル新規作成時は以下の内容で作成する:

# Dev Journal

実装中の設計上の気づき・疑問・バックログ送りタスクの記録。