指示
指定された日付(デフォルト: 当日)のデイリーノートを読み取り、タグの整合性チェックと不足情報の補完を対話形式で行ってください。
対象日付: $ARGUMENTS(未指定の場合は今日の日付を使用)
手順
Phase 1: 事前チェック(Git)
- •
git branch --show-currentで現在のブランチを確認する- •
mainブランチでなければ、ユーザーに警告して 処理を中断 する - •メッセージ: 「現在
<branch名>ブランチです。mainブランチに切り替えてから再度実行してください。」
- •
- •
daily/<日付>.mdの存在を確認する。存在しない場合はその旨を伝えて終了する - •
git status -- daily/<日付>.mdでファイルの Git 状態を確認する- •untracked: ユーザーに「このファイルはまだ Git 管理されていません。先にコミットしますか?」と確認 → 承認されたら
git add daily/<日付>.md&&git commit -m "docs: add <日付>"を実行 - •未コミットの変更あり: ユーザーに「未コミットの変更があります。現在の状態をコミットしてから補完を開始しますか?」と確認 → 承認されたら
git add daily/<日付>.md&&git commit -m "docs: update <日付>"を実行 - •クリーン: そのまま Phase 2 に進む
- •untracked: ユーザーに「このファイルはまだ Git 管理されていません。先にコミットしますか?」と確認 → 承認されたら
Phase 2: 不足情報の特定と補完
- •
daily/<日付>.mdを読み取る - •
以下の 4 つの観点で問題を特定する:
a. タグの重複・類似チェック:
- •ノート内の全ての
### #ref/xxxからタグ名xxxを抽出する - •
work/,tech/,private/配下のファイル名(拡張子を除く)を走査し、既存タグ一覧を構築する - •各タグを既存一覧と比較し、類似タグを検出する(詳細は後述)
- •類似タグが見つかった場合は既存タグへの修正を 提案 する
b. 開始時間・終了時間:
- •
## workセクション内の各### #ref/xxxブロックに⏱ 開始と⏱ 終了が揃っているか確認する
c. 作業結果・成果:
- •作業内容の記載はあるが、結果や成果(何が完了したか、何が得られたか)が不明な項目を検出する
d. あいまいな記述:
- •「作業した」「対応した」「確認した」等の汎用表現のみで、具体的な対象・内容・結果が書かれていない項目を検出する
e. tech セクションへの抽出提案:
- •
## workと## privateセクションの各エントリを走査し、技術的な学び・発見・調査を含む内容を検出する - •以下のようなシグナルがある項目を抽出候補とする:
- •新しいツール・ライブラリ・フレームワークの導入・設定・検証
- •バグ調査・デバッグで得た技術的知見(原因特定、ワークアラウンド等)
- •アーキテクチャや設計判断に関する検討・決定
- •パフォーマンス改善・最適化の手法
- •インフラ・CI/CD・開発環境の構築や変更
- •技術記事・ドキュメントの調査結果
- •既に
## techセクションに同等の内容が記載されている場合はスキップする - •抽出候補が見つかった場合、ユーザーに以下を対話形式で確認する:
- •tech セクションに追記するかどうか
- •承認された場合、技術的なポイントを深掘りする質問をする(例: 「〇〇を導入した際に、比較検討した代替手段はありますか?」「この問題の根本原因は何でしたか?」)
- •ユーザーの回答をもとに
## techセクションに### #ref/xxx形式で追記する
- •タグ名は内容に応じた技術名・ツール名を提案し、ユーザーに確認する
- •既存の
tech/配下のファイル名と照合し、既存タグがあればそれを優先する
- •ノート内の全ての
- •
検出した問題をユーザーに報告し、対話形式で補完する:
- •タグの問題は最初に報告し、修正を確定させてから内容の補完に進む
- •不足情報(b〜d)は 1〜3 個ずつ質問する
- •tech 抽出提案(e)は不足情報の補完が完了した後に行う(補完で内容が充実した状態で判断するため)
- •
ユーザーの回答をノートの該当箇所に追記・更新する
- •
全ての項目を確認し終えるまで 6-7 を繰り返す
Phase 3: 事後コミット(Git)
- •更新内容のサマリーを表示する
- •変更がある場合のみ:
git add daily/<日付>.md&&git commit -m "chore: refine <日付>"でコミットする - •変更がない場合は「問題は見つかりませんでした」と報告して終了する
タグ類似度チェックの詳細
既存タグ一覧の構築:
- •
work/,tech/,private/配下のファイル名から.mdを除去してタグ一覧を得る - •ディレクトリが存在しない場合は空として扱う(エラーにしない)
類似と判定する条件(いずれかに該当):
- •ハイフン
-とアンダースコア_の揺れ(例:my-projectvsmy_project) - •末尾の複数形・接尾辞の違い(例:
api-testvsapi-tests) - •共通プレフィックスを持ち末尾のみ異なる短い差分(例:
infra-setupvsinfra-setup-v2) - •1〜2 文字の差異(タイポの可能性。例:
proejct-avsproject-a)
報告フォーマット:
類似タグを発見した場合:
code
⚠ タグの類似: `#ref/proejct-a` → 既存タグ `project-a`(work/project-a.md)のタイポの可能性があります。 → `#ref/project-a` に修正しますか?
新規タグ(類似なし)の場合:
code
ℹ 新しいタグ: `#ref/new-topic` は既存タグに該当するファイルがありません。新規タグとしてそのまま使用します。
質問のガイドライン
- •一度に聞く質問は 1〜3 個に抑える(多すぎると負担になる)
- •具体的に何が不足しているか明示する(例: 「〇〇の作業について、開始時間と終了時間を教えてください」)
- •ユーザーが「不明」「覚えていない」と答えた場合は無理に埋めず、次の質問に進む
注意事項
- •ノートの既存内容は勝手に書き換えない(追記・補完のみ。タグ修正はユーザー承認後のみ)
- •ノートの書き方やフォーマットは元のスタイルを維持する
- •
## memoセクションはチェック対象外とする - •Git コミットメッセージは Conventional Commits 形式に従う
- •
mainブランチ以外では実行しない - •
git addは対象のdaily/<日付>.mdのみをステージする(git add .は使用しない)