Logging session
Skill balabalabalading/huuuuuuho-skills/skills/logging-session
Record and query AI conversation logs — what users asked, how it was solved, and the result. Use when users want to logging conversation, summarize recent work from sessions, or want daily/weekly project summaries from past conversations.From its SKILL.md
npx -y skills add balabalabalading/huuuuuuho-skills --skill logging-sessionAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- skips confirmationTells the agent to proceed without asking first, 1 time: "Do NOT ask the user for confirmation — just save and done.".
- runs commandsInstructs the agent to run 6 commands, including `python3 <skill-path>/scripts/init_db.py` and 5 more.
SKILL.md
8.7 KB, ~2.1k tokens by cl100k_base, as published. Nobody here has run it
Logging Session
This skill records coding session summaries to a local SQLite database stored in your local path, so you can later query and summarize your work across projects and time periods.
Why this matters
Coding sessions produce valuable knowledge — decisions made, problems solved, approaches tried and abandoned. Without capturing these, each session starts from scratch. This skill turns conversations into searchable, summarizable records that feed into daily standups, weekly reviews, and long-term project memory.
Database location
The database path is defined by db_path in config.json, defaulting to:
~/Library/Mobile Documents/iCloud~md~obsidian/Documents/vault4life/dev_knowledge.db
To customize, edit <skill-path>/config.json.
If the database doesn't exist yet, initialize it:
python3 <skill-path>/scripts/init_db.py
The script reads the path from config.json automatically. You can also specify a path manually:
python3 <skill-path>/scripts/init_db.py /path/to/your/dev_knowledge.db
Schema
CREATE TABLE dev_logs (
id INTEGER PRIMARY KEY AUTOINCREMENT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
project_name TEXT NOT NULL,
session_id TEXT NOT NULL,
parent_id INTEGER DEFAULT NULL,
task_category TEXT,
user_query TEXT NOT NULL,
thought_process TEXT,
final_result TEXT,
file_paths TEXT,
git_hash TEXT,
extra_metadata TEXT,
FOREIGN KEY (parent_id) REFERENCES dev_logs (id)
);
When to record
Record a session log entry when:
- User explicitly asks — they say "record this session", "log this conversation", "logging-session", etc.
- A meaningful task completes — when a significant coding task is done (bug fixed, feature added, refactoring completed), and the user wants it captured.
- Via Stop hook — when the hook fires automatically at session end, synthesize the entire conversation into a log entry.
Do NOT record trivial interactions (quick questions, simple lookups, clarifications) unless the user asks.
How to record a session log
When recording, you need to synthesize the conversation into a structured entry. Don't just copy-paste — distill the essence.
Step 1: Gather context
Collect these fields from the conversation and environment:
| Field | Source | Notes |
|---|---|---|
project_name | Current working directory's folder name | Use basename $(pwd) or equivalent |
session_id | Generate from date + random suffix | Format: YYYYMMDD_xxxx (e.g., 20260513_a3f2) |
parent_id | If this continues a previous log entry, use that entry's ID | Otherwise null |
task_category | Classify the task: bugfix, feature, refactor, debug, setup, docs, test, other | |
user_query | The user's original question or task description | In the user's own words when possible |
thought_process | Your analysis approach, alternatives considered, key decisions | Concise but informative — this is the "how" |
final_result | What was actually done, the outcome | Include key code changes, file paths, or resolution |
file_paths | Files that were created or modified | Comma-separated |
git_hash | Current HEAD commit hash if in a git repo | Run git rev-parse --short HEAD |
extra_metadata | Any additional context as JSON | Optional |
Step 2: Write the entry
Run the save script:
python3 <skill-path>/scripts/save_log.py \
--project "<project_name>" \
--session "<session_id>" \
--query "<user_query>" \
--thought "<thought_process>" \
--result "<final_result>" \
--category "<task_category>" \
--files <file1> <file2> \
--git "<git_hash>"
For fields with spaces or special characters, wrap in quotes. The --parent, --category, --files, --git, and --meta flags are optional.
Step 3: Confirm
After saving, tell the user:
- The log entry ID
- A brief summary of what was recorded
Example: "Session logged as #5 — recorded the auth bug fix in project my-app."
Querying session logs
Summarize recent work
When the user asks for a summary (daily, weekly, or custom range):
# Last 7 days for current project
python3 <skill-path>/scripts/query_logs.py \
--project "<project_name>" \
--days 7 \
--format markdown
# Today's logs across all projects
python3 <skill-path>/scripts/query_logs.py \
--days 1 \
--format markdown
# Specific date range (YYYYMMDD format, inclusive)
python3 <skill-path>/scripts/query_logs.py \
--start-date 20260501 \
--end-date 20260515 \
--format markdown
# Specific session's full thread
python3 <skill-path>/scripts/query_logs.py \
--session "<session_id>" \
--format ai
Output formats
markdown— structured Markdown with headers by date (good for reports and Obsidian)ai— plain text blocks, compact (good for feeding back to AI)json— raw JSON array (good for programmatic processing)
Weekly Project Summary (项目周报)
When the user asks to summarize work by project for the past week or generate a weekly report, use weekly_summary.py. This script groups entries by project, shows task category breakdowns, and lists individual session details — all in a clean markdown table format.
Trigger phrases: "总结过去一周的工作", "本周工作总结", "生成周报", "项目周报", "weekly summary", "summarize past week's work"
# All projects, past 7 days
python3 <skill-path>/scripts/weekly_summary.py --days 7 --format markdown
# Single project, past 14 days
python3 <skill-path>/scripts/weekly_summary.py --project "my-app" --days 14
# Specific date range (YYYYMMDD format, inclusive)
python3 <skill-path>/scripts/weekly_summary.py \
--start-date 20260501 \
--end-date 20260515 \
--format markdown
# Export to Obsidian
python3 <skill-path>/scripts/weekly_summary.py \
--format markdown \
--output ~/Library/Mobile\ Documents/iCloud~md~obsidian/Documents/vault4life/周报-$(date +%Y-W%V).md
# JSON for programmatic use
python3 <skill-path>/scripts/weekly_summary.py --format json
The markdown output includes an overview section (total entries, projects involved, time period) and per-project sections with task category distribution tables and session detail tables.
Saving to Obsidian
When the user wants to save the summary as an Obsidian note:
python3 <skill-path>/scripts/query_logs.py \
--days 7 \
--format markdown \
--output ~/Library/Mobile\ Documents/iCloud~md~obsidian/Documents/vault4life/Weekly-$(date +%Y-W%V).md
Automatic logging via Stop hook
When triggered by the Stop hook (session is ending), you are the last action in this conversation. Your job: synthesize the entire conversation into one log entry and write it to the database.
What to do when the Stop hook triggers you
- Review the full conversation — identify the user's main question/task, your approach, and the outcome.
- Gather context — project name from CWD, git hash, files touched.
- Classify the task — pick the most fitting category.
- Write one log entry using the save script with all fields populated.
- Keep it brief — this is a summary, not a transcript. One sentence each for thought_process and final_result is fine.
- Do NOT ask the user for confirmation — just save and done. The session is ending.
Hook configuration
The Stop hook is configured in ~/.claude/settings.json. See references/hooks-guide.md for full setup details.
Task categories
| Category | Description |
|---|---|
bugfix | Fixed a bug or error |
feature | Added new functionality |
refactor | Restructured code without changing behavior |
debug | Investigated an issue (may not have fixed it) |
setup | Project setup, configuration, dependencies |
docs | Documentation work |
test | Writing or fixing tests |
other | Anything else |
Tips for good session logs
- user_query: Capture the intent, not just the literal question. "How do I fix the login crash?" is better than "login crash".
- thought_process: Focus on the why, not the what. "Tried approach A but it conflicted with the existing auth flow, so switched to B" is valuable. "Changed 3 files" is not.
- final_result: Be specific about the outcome. Include file names, function names, or the key insight. "Fixed by adding null check in UserService.validate()" is better than "It works now".
- parent_id: Use it when a session is a continuation of a previous conversation. This builds a thread of related work.
What ships with it: 10 files
35.5 KB alongside SKILL.md, 6 of them executable
evals/
- evals.json4.7 KB
references/
- hooks-guide.md1.9 KB
scripts/
- config_loader.pyruns1.0 KB
- init_db.pyruns1.4 KB
- query_logs.pyruns5.1 KB
- save_log.pyruns2.8 KB
- time_utils.pyruns1.2 KB
- weekly_summary.pyruns8.2 KB
- config.json198 B
- README.md8.9 KB
Gives 0 of the 12 instructions most log analysis skills give in ~2.1k tokens
Counted across 325 of the 341 authors here whose files we hold, read 2026-09-06
- Use structured JSON loggingin 32 of 325, across 30 files
- Link every alert to a runbookin 15 of 325, across 13 files
- Alert on symptoms, not causesin 11 of 325, across 10 files
- Include correlation IDs in every log linein 10 of 325
- Propagate trace context across service boundariesin 9 of 325, across 8 files
- Include request IDs for correlationin 8 of 325, across 6 files
- Include trace_id in every structured log entryin 8 of 325, across 7 files
- Include request and user context in every log entryin 8 of 325
- Correlate logs and traces with shared trace IDin 7 of 325, across 6 files
- Record exceptions and set span status on errorsin 7 of 325
- Confirm connection is ACTIVE before running workflowsin 6 of 325, across 3 files
- Call RUBE_SEARCH_TOOLS first for current schemasin 6 of 325, across 3 files
Said here and by no other author read
- Initialize the database if it doesn't exist
- Distill the conversation into a structured log entry
- Generate session_id as date plus random suffix
- Classify each task into one category
- Run save_log.py with all fields populated
- Confirm the entry ID and a summary to the user
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.