Generate structured Obsidian daily report content from Lode weekly change entries and git commit statistics. The daily report is the daily compounding layer of the Lode habit loop: it not only records what was done today, but also preserves the decisions, risks, open questions, and high-value source links that should be remembered when starting work tomorrow.
Configuration System
Configuration file locations (priority from high to low)
| Priority | Location | Description |
|---|---|---|
| 1 | Project root directory .lode/config.yaml |
Project-level override |
| 2 | ~/.lode/config.yaml |
Global configuration |
| 3 | $WEEKLY_PPT_PATH Environment variable |
legacy fallback |
| 4 | ~/.weekly-ppt/ |
legacy fallback default value |
Migration notes: The old version
.daily-note-config.yamlis deprecated. Daily report settings are now unified under the.lode/config.yamlofdaily_note:child node. If an old configuration file is detected, prompt the user to migrate.
Configuration file structure
# Lode Configuration
# 全局: ~/.lode/config.yaml | 项目级: {project-root}/.lode/config.yaml
knowledge_vault: /path/to/your/knowledge-vault
# 日报设置（可选，原 .daily-note-config.yaml）
daily_note:
path: /path/to/your/Daily Note.md # 默认 {vault}/Daily Note.md
repos: # 工作仓库列表
- /path/to/repo1
- /path/to/repo2
categories: # 自定义类别
- name: 【安全加固】
patterns: ["security", "auth", "permission"]
- name: 【性能优化】
patterns: ["perf", "optimize", "speed"]
enable_smart_classify: false # LLM 语义分类（默认 false）
First-time use
If no configuration file is found:
- Prompt the user to run
/lode:cold-start-interviewto create a global configuration - If the user directly provides a path, the minimal configuration can also be written to
~/.lode/config.yaml - If the user wants project-specific configuration, write it to the project root directory's
.lode/config.yaml
Configuration merge rules
Project-level configurationoverridesfields with the same name in the global configuration. Unconfigured fields are inherited from the global configuration. This skill's main output depends on {vault} or an explicit daily_note.path; if the path cannot be resolved, prompt the user to run /lode:cold-start-interview or configure knowledge_vault。
Writing and Classification Rules
Read references/daily-note-writing.md before classifying fallback commits or
writing final Daily Note content. Keep SKILL.md focused on execution flow; the
reference contains category mapping, semantic writing rules, merge rules, and
the exact output format.
Workflow
Step 1: Load configuration
1. 检查项目根目录 .lode/config.yaml
2. 检查 ~/.lode/config.yaml
3. 如果都不存在 → 回退到 legacy `$WEEKLY_PPT_PATH` → `~/.weekly-ppt/`
4. 如果仍无法解析 → 提示运行 `/lode:cold-start-interview`，或在用户直接提供路径时创建最小全局配置
5. 合并配置（项目级覆盖全局级）
6. 如果 config 中没有 repos，尝试从 {vault}/raw/projects.json 读取项目路径作为补充
| Parameter | Source | Default value |
|---|---|---|
daily_note_path |
Configuration file daily_note.path |
{vault}/Daily Note.md |
repos |
Configuration file daily_note.repos → {vault}/raw/projects.json |
Current directory |
date |
User-specified | Today (YYYY-MM-DD) |
date_end |
User-specified | Same as date (single-day mode) |
Step 1.5: Raw Data Coverage Check
Before processing, check how much raw entry data exists for the target date(s):
- Count raw entries matching the target date from
{vault}/raw/weeks/{week}/{slug}.json - Count git commits for the same date range
- Report coverage:
| Coverage Level | Raw Entries | Git-Only Commits | Quality |
|---|---|---|---|
| Full | >= 1 | any | High — raw entries carry intent and decisions |
| Partial | 0 | >= 1 | Medium — git-only; lacks motivation and trade-offs |
| None | 0 | 0 | Empty — no work signal available |
If coverage is Partial or None, include a warning at the top of the output:
- Partial: "No raw entry coverage for this day; the daily report content comes from git log and lacks decision rationale and context. It is recommended to run /lode:capture to record key decisions."
- None: "No raw entry or git commit for this day; it is recommended to confirm whether the date range is correct."
Step 2: Read weekly change entries (primary data source)
From {vault}/raw/weeks/{week}/{slug}.json read the existing change entries for the day.
- Calculate the ISO week of the target date (
date +%Y-W%V） - Iterate over the slugs corresponding to all repos, read
{vault}/raw/weeks/{week}/{slug}.json - Filter entries whose timestamp matches the target date (compare the date part YYYY-MM-DD)
- By
references/daily-note-writing.mdmap entries to daily report categories.
JSON entries are already high-quality structured data(with summary + context, possibly impact/status/project_area/evidence_refs), no further diff analysis or classification is needed. Prefer using impact to write the daily report description;status: ongoing do not write as completed,status: risk preserve the risk tone. Proceed directly to the intelligent merge in Step 5.
If multiple raw entries describe the same work from different sources, merge them into one daily-note item instead of duplicating the same change. Prefer adaptive-depth session-recap for intent and artifact evidence; treat legacy arch-doc as historical evidence/context. Preserve conflict or risk language explicitly when entries disagree.
Compounding requirements:
- Preserve raw-entry decisions, risks, open questions, and follow-up signals.
- Link high-value artifacts from
{vault}/raw/artifacts/{slug}.jsonwhen metadata is present. - Do not duplicate full architecture docs into the Daily Note.
- Include what should matter tomorrow when an entry has
open_questions,status: risk, or lifecycle language. - Missing artifact index is acceptable and must not block output.
If {vault}/raw/ does not exist or the corresponding week directory does not exist, skip this step and go entirely to Step 3 for gap filling.
Step 3: Git log gap filling (secondary data source)
Use git log --stat to get all commits for the day, compare with JSON entries, and find uncovered commits.
git log --since="<date> 00:00:00" --until="<date> 23:59:59" --pretty=format:"%h %s" --stat
Coverage determination: Compare the commit subject with the summary of the JSON entry. If the semantics of the commit are already covered by an entry, skip that commit.
Uncovered commits go through the simplified analysis process:
- Only look at the commit subject + stat (file change statistics),do not perform full diff analysis
- Use keyword matching of the classification system to classify (no LLM semantic classification needed)
- Generate lightweight daily report entries
If scripts/git-stats.sh is accessible, it can also be used to obtain structured data (but still skip the full diff):
bash <skill-path>/scripts/git-stats.sh <repo_path> <date>
Step 4: Classification (only for commits supplemented in Step 3)
Use references/daily-note-writing.md for keyword categories, optional LLM
semantic classification, and same-task merge rules. These rules apply only to
fallback commits. Do not reclassify raw entries.
Step 5: Intelligent merge
JSON entries (from Step 2): only merge obviously duplicate or same-origin work items, do not reclassify, do not rewrite facts.session-recap + legacy arch-doc The same change is merged into one entry, retaining evidence/context.
Supplemented commits (from Step 3-4): processed according to the original merge rules — multiple commits for the same feature can be merged into one entry.
Finally, merge the two sets of data, arrange them by category and module, and proceed to Step 6.
Step 6: Generate daily report content
Multi-date support
The user can specify a date range (e.g. "supplement the daily reports for the past three days"); in this case, date_end > date：
- generate a separate date entry for each day
- arrange by date from newest to oldest
Incremental update detection
Before generation, first check whether the daily report file already has an entry for the day (matching ### YYYY.MM.DD or ### YYYY-MM-DD）：
- already exists → merge the newly added content under the day's entry, do not repeatedly create the date heading
- does not exist → create a new date entry
Output format
Use the exact output format and module label rules in references/daily-note-writing.md.
Execution checklist
Configuration:
- The configuration file exists (global or project-level) or has been created
- The daily report file path is valid
Commit analysis:
- All commits for the day were obtained (reflog cross-validation)
- Each supplemented commit has subject + stat information
- The scale of changes was quantified (+N/-M lines)
Output quality:
- Semantic description (intent/effect, not function names/field names)
- Each change is annotated with its module attribution
- The raw entry's
impact/statushas been correctly reflected in the daily report wording (if present) - The raw entry's open questions / risks / decisions have been retained as handoff signals for tomorrow (if present)
- High-value source links in the artifact index have been cited as needed, without copying the full text into the daily report
- The format is consistent with the existing daily report
- Checked whether there are duplicate entries for the day
- Related commits have been intelligently merged
- Classification is accurate (semantic classification was used when necessary)
Reference files
| File | When to read |
|---|---|
references/daily-note-writing.md |
Classification, merging, writing style, output format |
references/config-template.yaml |
Configuration file example |