From daytrace
1日の活動ログから、その日全体の流れを読者向け narrative draft に再構成する。記事を書きたい、ブログにまとめたい、ふりかえりを書きたい、学びを共有したい時に使う。topic / reader は任意で上書きできる。
How this skill is triggered — by the user, by Claude, or both
Slash command
/daytrace:post-draftThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
その日のローカルログから、date-first で narrative draft を組み立てる。
その日のローカルログから、date-first で narrative draft を組み立てる。
主目的は媒体を選ぶことではなく、その人だけが書ける一次情報ベースの Context & Narrative を下書き化すること。
workspace default ではなく date-first default + optional workspace filter として扱うtopic と reader だけ optional override として受け付けるtodayYYYY-MM-DD を使うclaude-history / codex-history / chrome-history はその日全体のログを返しうる入力は自然言語抽出と引数なし実行の 2 経路を前提にする。
reader を抽出するtopic を抽出する/path/to/repo で」などから workspace を抽出するtoday を使うreader は自動推定するtopic は narrative policy で自動選定するdocs/output-polish.md §10)Escalation Conditions の機密確認は従来どおり別枠Escalation Conditions を除き、入口でも途中でも質問しないこの節は daytrace-session のような orchestration が、この skill を自動起動する時の契約を定義する。
個別実行時の UX を変えるものではなく、いつ自動で呼んでよいかだけを明文化する。
sources に git-history と (claude-history または codex-history) が両方 success で含まれるsummary.total_groups >= 4topic や reader の override が明示されている場合はそれを優先し、自動起動条件は呼び出し可否の判断にのみ使う必ず最初に post_draft_projection.py を 1 回だけ実行し、中間 JSON を取得する。
この adapter は shared derived data を優先して読み、該当 slice が store に無い場合だけ内部で aggregate.py を 1 回実行して hydrate する。
返却 JSON の主要 shape は aggregate.py 互換で、sources / timeline / groups / summary をそのまま読める。cached patterns があれば追加で添付される。
aggregate.py はこの SKILL.md と同じ plugin 内の scripts/ ディレクトリにある。
この SKILL.md のあるディレクトリから ../.. を辿った先を ${CLAUDE_PLUGIN_ROOT} として扱う。
date-first デフォルト:
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/post_draft_projection.py --date today --all-sessions
特定日:
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/post_draft_projection.py --date 2026-03-09 --all-sessions
workspace の git / file 根拠を current repo に固定したい場合:
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/post_draft_projection.py --date today --all-sessions --workspace /absolute/path/to/workspace
この指定の意味:
git-history と workspace-file-activity は --workspace で絞り込まれるclaude-history / codex-history は --all-sessions が付くと workspace を無視するchrome-history は現状常に workspace を無視するsources[].scope を見て、repo ローカルの根拠と全日根拠を混同しない中間 JSON の主な読みどころ:
sources: source ごとの success / skipped / error / scopegroups: 近接イベントを束ねた活動グループtimeline: 詳細な時系列summary: 件数と source 利用状況report_date / output_dir: 単日スコープ時に付く(docs/output-polish.md §7)output_dir が非 null のとき、生成した narrative を post-draft.md に保存する。チャットには要約・パス・成否のみ返す。
daily-report と同様。daily_report_projection / post_draft_projection は返却前に output_dir をコード側でも用意する)この skill は date-first だが、source には all-day と workspace の 2 種類がある。
all-day
claude-history, codex-history, chrome-historyworkspace
git-history, workspace-file-activityworkspace 未指定でも、出力は全日ログと cwd 起点の workspace ログが混在しうる。
workspace 指定時も mixed-scope は解消されず、repo ローカルの根拠密度が上がるだけで all-day ログまで strict な repo filter にはならない。
date-first の narrative を組み立てつつ、mixed-scope を隠さないこと。
主題選定は Python helper に切り出さず、この SKILL.md の policy として実装する。
aggregate.py が返す groups / events を読み、主題選定と narrative 構成を一体で行うこと。
--topic が明示されている場合は、それを最優先する。
未指定時は groups から以下の 3 段フォールバックで主題を 1 つ選ぶ。
sources に git-history と (claude-history または codex-history) が両方含まれるevent_count が最大の group を選ぶconfidence_categories に ai_history を含み、かつ group 内の claude-history / codex-history イベント数が 3 件以上event_count が最大の group を選ぶevents[].summary や type から、転換点、詰まり、判断理由、学びを narrative 構成で拾うnarrative では以下のどこが今日の転換点だったかを、本文で明示的に拾う。
転換点は説明的につなげるのではなく、「ここで流れが変わった」と読者に伝わる narrative の起伏として描く。
優先順位は --reader override > 自然言語から抽出した reader > デフォルト読者 とする。
ただし Escalation Conditions の判定はデフォルト読者の適用前に行う。
reader を抽出できた場合はそれを使う--reader override も無く、かつ escalation 判定が発火しない場合のデフォルトは 同じ技術スタックを使う開発者--reader overridereader が明示されている場合は、その読者像に合わせてトーンと粒度を調整する--reader "社内の非エンジニア" の場合、技術用語を減らし、背景、プロセス、成果を中心に書く--reader "個人ブログの読者" の場合、一人称で試行錯誤や学びのストーリーを前に出すask は使わず、読者と主題から以下を自動で決める。
chrome-history 主体で git commit がほぼない(実装ではなく調査が中心)post_draft_projection.py を 1 回だけ実行するsources を読み、取得できた source と scope を把握するgroups を読み、主題選定の 3 段フォールバックで中心 group を決めるtimeline を補助参照し、背景や前後関係を補うall-day source を repo 限定の根拠として扱わないchrome-history は補助的文脈として使い、単独では主題化しすぎないworkspace-file-activity 単独の場合は「作業痕跡」として控えめに扱うteam-summary / slack を main UX に戻さない出力は日本語 Markdown。 少なくとも以下の要素を含む narrative draft として返す。
# タイトル案docs/output-polish.md §9-3)標準:
# タイトル案(8–20 字)
## 背景
## 今日の中心
## 気づき(根拠が弱い場合は省略可)
非技術者向け・調査中心の別構成は Reader Policy のテンプレートに従う。
次は使わない: 寄り道、今日の重心(置換: 「別の作業をした時間」「今日の中心作業」など、行動レベルの表現)。
追加で避ける:
実装密度の高い1日〜でしょうハッカソン提出を控え置換方針:
今日の中心 は、可能なら 2 段落以上で 主作業 → 転換点 / 判断 → 結果 の流れを見せる確認したい点 セクションは作らないskill_miner_prepare.py → パターン抽出の準備段階ISSUE-observation-contract-unification.md → 観測コントラクトの統合作業worktree_status snapshot → 作業ディレクトリの状態記録「ドキュメントと実装の乖離は LLM に直結する」 → 何がズレていて、何が不安定になったかまで半歩具体的に背景 は 1-2 文まで。主題がすでに明確な日は、省略または極小化してよい今日の中心 の第1段落で、主作業とその結果を先に述べる背景 / 今日の中心 / 気づき の各見出しの中を 1 行メモだけで終わらせないテストを先に書くことで境界が明確になったテスト追加を通じて、入出力の境界が明確になりましたテスト追加により、どの入出力を固定すべきかが見えましたDayTrace の心臓部を直す:observation contract 統合 → 内輪寄りAI エージェントが "過去の自分" を正確に読めるようになるまで → 意味が伝わる# タイトル案
## 背景
## 今日の中心
## 気づき
「詰まった点」「判断したこと」は固定セクションにせず、「今日の中心」の narrative 内で evidence があれば自然に触れる。 「気づき」が evidence から読み取れない日は、「今日は実装に集中した日だった」のように正直に短く閉じてよい。
# タイトル案
## 何に取り組んだか
## 今日の中心
## 気づき
成功した sources[] の scope を見て、注記の要否を決める。
all-day と workspace の両方が含まれる場合
daytrace-session のセッション完了チャットで §5-5 が必須この下書きは、1日のログと workspace ローカルの変更ログをもとに再構成しています。all-day のみ、または workspace のみの場合
根拠の具体性で信頼度を表現する。Confidence: high のようなラベル明示は行わない。
弱い箇所だけ注記を残す。
high
medium
と見られる 中心だった などで断定を弱めるlow
注記: ファイル変更からは確認できるが、最終的な意図は断定できない注記: ブラウザログのみからの補助推定ですsource 欠損の判定は summary と sources から行う。
source_status_counts.success == 0
source が 0 本 とみなすsource_status_counts.success が 1-2
source が 1-2 本だけ とみなすsources[].status に skipped / error があっても、成功 source が残っていれば継続するsummary.no_sources_available は空結果を示すメタ情報であり、実際の分岐判定は source_status_counts.success を優先する以下のような空 narrative を返す。
# タイトル案
## 背景
利用可能なローカルログが見つからず、その日の活動から narrative を組み立てられなかった。
## 今日の中心
今日は組み立てに使えるログが不足していたため、中心的な活動を再構成できなかった。
## 気づき
少なくとも 1 系統のログが取れる状態で再実行すると、下書きを組み立てやすくなる。
取得できたログは限定的 と導入で明記してよいタイトル / 背景 / 今日の中心 / 気づき の骨格は維持するteam-summary 的な共有は、main UX ではなく daily-report の 共有用 へ役割を移したとみなすslack 用途は main UX から外す下書き生成時に以下の structured log を [PostDraft] タグで出力する。
これによりデバッグ時に「なぜこのトピックが選ばれたか」を追跡可能にする。
[PostDraft] judgment: selected_group_id={group_id} | topic_tier={1|2|3} | topic_reason={reason} | reader={auto|override} | reader_reason={reason} | degrade_level={full|limited|empty} | source_count={N}
フィールド定義:
selected_group_id: 中心トピックとして選んだ group の ID(例: group-003)topic_tier: 3段フォールバックのどの tier で決まったかtopic_reason: tier 内の選定理由(例: highest_event_count_with_ai+git)reader: auto(自動推定)または override(ユーザー指定)reader_reason: reader 推定根拠(例: default_technical_developer or user_specified_非エンジニア)degrade_level: full(3+ sources)/ limited(1-2 sources)/ empty(0 sources)source_count: 成功した source の数以下の場合のみ確認を入れてよい:
--reader 未指定で、入力から reader を抽出できず、かつ公開境界シグナルが判定不能な時は「公開記事向けと私的メモのどちらですか?」と 1 回だけ確認してよい。推定可能なら ask しない
記事, ブログ, 投稿, 公開, 共有)と私的メモシグナル(自分用, 個人メモ, 日記, 非公開)が同時に出ていて矛盾するpost-draft の価値は wording と narrative continuity にあり、決定論的 helper に閉じないからaggregate.py の shape、mixed-scope 表示、graceful degrade など決定論的な部分だけに限定するサンプルと fixture review 手順は references/sample-outputs.md を参照すること。
以下を満たすまで出力を確定しない。
post-draft が Context & Narrative の skill として一貫して説明されている0 ask + optional override になっているteam-summary / slack が main UX から外れているSKILL.md だけで読めるreader の自動推定と --reader override の扱いが読めるsources[].scope ベースで一意に読めるこの skill は、その日の一次情報から narrative draft を 1 コマンドで完走させる前提で使う。
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub matz-d/daytrace-plugin --plugin daytrace