| name | hyday-lifelog |
| description | Write, read, and summarize Hyday journal entries with Life Log marks for time-stamped events, thoughts, and highlights. Use whenever the user writes, reads, summarizes, lists, or extracts data from journal `.md` files (filename matches `YYYY-MM-DD.md` or `YYYY.MM.DD.md`) — e.g. "今天做了什麼", "幫我寫今天的日誌", "撈出這週的待辦/想法", "我這個月寫了什麼", "yesterday's journal", "summarize this week" — or mentions journal, daily entry, life log, task start/end, or the special marks `>()`, `<()`, `-()`, `%()`, `!()`. |
Hyday Life Log Skill
First time in this conversation? Run Step 0 from hyday-vault-layout to find the vault root. This skill assumes you already know where the user's Hyday folder lives on disk. Resolve it from ~/Library/Application Support/Hyday/settings.json (macOS) or %APPDATA%\Hyday\settings.json (Windows) — journalPath field. Don't guess, and don't ask the user unless the config lookup fails.
Hyday's journal is a per-day Markdown file decorated with five Life Log marks — short inline annotations that turn a free-form daily log into something Hyday can parse for task ranges, thoughts, and highlights.
When this skill applies
A journal entry is a .md file whose filename is a date:
2026-05-17.md ← preferred form2026.05.17.md ← also accepted (dot-separated)
Files matching this pattern are auto-typed as journal. Do not set type: "journal" in frontmatter — the filename does it.
Journal files normally live under journal/<year>/<date>.md. See hyday-vault-layout for placement details.
Workflow: Writing a Journal Entry
- Use the correct filename —
YYYY-MM-DD.md, placed under journal/<year>/.
- Optional frontmatter — usually omitted for journals. If used,
tags is the most common field.
- Write the body in plain Markdown.
- Sprinkle Life Log marks where appropriate (see below). Use them inline within sentences, not as bullet prefixes.
- Save — Hyday picks up the change. The marks render as styled chips and feed task tracking, lifelog insights, and tag exploration.
The five Life Log marks
Marks split into two categories by what goes inside the parentheses.
Time marks — content is HH:mm
The mark itself only carries the time. Write the event description as plain text on the same line, next to the mark.
| Mark | Type | Meaning |
|---|
>(HH:mm) | taskStart | Started a task / event |
<(HH:mm) | taskEnd | Finished a task / event |
-(HH:mm) | current | Snapshot of "what's happening right now" |
>(09:00) Inbox triage and morning planning
<(09:45) Done with inbox — 12 emails left for tomorrow
-(10:30) Stuck on the migration script, taking a walk
Content marks — content is free text
The text inside the parentheses is the content; nothing else needs to be written.
| Mark | Type | Meaning |
|---|
%(text) | thought | A passing thought, a hunch, a "note to self" |
!(text) | important | Something to flag — decision, surprise, takeaway |
%(maybe the bug is in the migration, not the API)
!(decided to ship v2 without the dashboard rewrite)
Mark placement rules
- Inline, not as block prefixes.
>(09:00) Did X ✓ — - >(09:00) Did X puts the mark inside a list item, which still works but is less common.
- One mark per occurrence.
>(09:00) <(10:00) ... (two marks on one line) is technically valid but harder to read; usually you write <(10:00) on its own line later.
- No nesting. Marks cannot contain other marks.
%(>(09:00) thought) is treated as literal text.
- Code-block safe. Marks inside fenced code blocks (
```) or inline code (`) are not parsed — useful when documenting the syntax itself.
- Time format is 24-hour
HH:mm for time marks. >(9:00) works (single-digit hour); seconds are not parsed.
When to use which mark
| Situation | Mark |
|---|
| About to start something — meeting, deep-work block, errand | >(HH:mm) <description> |
| Just finished something | <(HH:mm) <description> |
| Pausing mid-task to capture state | -(HH:mm) <description> |
| Random idea you don't want to lose | %(<idea>) |
| Worth remembering — decision, insight, surprise | !(<thing>) |
A common pattern: >(...) and <(...) bracket a focused block of work, the body in between describes what happened, with %(...) and !(...) scattered throughout for thoughts and highlights.
Hyday-specific inline content
Inside a journal body you can also use everything from hyday-markdown:
#tag — inline tags@(Label) — entities (people, projects, places)[[note-id]] — links to other notes or other journal dates- Standard Markdown — headings, lists, tables, code blocks, callouts, math
Complete example
journal/2026/2026-05-17.md:
---
tags:
- "monday"
---
# 2026-05-17
>(08:30) Morning routine — coffee, glanced at #news
<(09:00) Done — feeling alert
>(09:00) Inbox triage and replies to @(Aaron) about the launch
%(Aaron's last reply suggests we should rethink the onboarding copy)
<(09:45) Done — 12 emails left for tomorrow
-(10:30) Working on the migration script for [[Project Alpha]]
!(Realized the old script assumes UTC; new one needs to honour user timezone)
>(11:00) Standup
<(11:15) Done — decided to defer the dashboard work to next sprint
## Afternoon
>(13:00) Deep work on [[Atomic Habits — Chapter 3 notes]] writeup
%(I should batch this kind of synthesis work into one slot, not three)
<(15:00) Wrapped — draft is ready for review
!(Big takeaway today: the migration timezone bug would have shipped if I hadn't run the seed script manually)
Validation checklist
After writing a journal entry, verify:
- Filename matches
YYYY-MM-DD.md (or YYYY.MM.DD.md).
- Frontmatter (if present) does not set
type: "journal".
- Time marks use
HH:mm inside parentheses, with description as plain text next to the mark — not inside the parens.
- Content marks (
%(), !()) have the meaningful text inside the parens.
- No mark is nested inside another.
- Marks you intend to be parsed are not inside fenced code blocks (unless that's intentional).
References
- Hyday Markdown basics (frontmatter, tags, entities, backlinks): see
hyday-markdown skill
- Where journal files live: see
hyday-vault-layout skill
