---
name: work-journal-daily
description: Create or append a dated work journal from GitHub activity, optionally enriched with Slack, Linear, Calendar, Notion, and Figma evidence.
disable-model-invocation: true
---

# Daily work journal

Create one source-bound markdown entry answering "what did I work on?". Completion means every distinct, attributable activity found for the date is represented once, and existing journal text remains unchanged.

## Workflow

1. Resolve the date and target file.
   - Default to today in the Mac's local timezone.
   - Accept an explicit date such as `2026-08-20`. Ask for a full date when the user gives only a month and day.
   - Stop before collection when the date is in the future.
   - Use `/Users/skull/personal/vournal/YYYY/MonthLongName/YYYY-MM-DD.md`, with the full English month name.
   - Read the existing file before collection. Create missing parent directories only when ready to write.
2. Pass the GitHub gate. Collect all GitHub activity classes below through an authenticated `gh` session or exact-date results supplied by the user. Each class must be checked, even when it returns no items. If any class errors, is partial, or lacks reliable attribution, stop before writing and ask for the matching GitHub export.
3. Collect each optional source that is already accessible through a live tool, authenticated CLI, or exact-date export. Run independent collection in parallel. An optional-source error or empty result does not block the journal.
4. If Calendar yields candidate meetings, ask one question listing all candidates and which ones the user attended. Resume after the answer. A meeting is eligible only when attendance is confirmed and its title or description identifies concrete work.
5. Reconcile the evidence. Keep actor, timestamp, link, and source attached until every item is categorized and deduplicated. Compare the draft with existing journal content by meaning, not wording.
6. Write only new bullets using the output contract. Then report the path and top-level bullet count appended. If no new meaningful activity remains, leave the file unchanged and say so.

## Source rules

### GitHub gate

Use `gh api user --jq .login` to establish the authenticated identity. Query all repositories visible to that account and use exact local-day bounds. Search broadly, then inspect pull requests, commits, reviews, and timeline events to verify the actor and event timestamp.

Account for each class:

- PRs authored by the user that opened, merged, or closed that day.
- PRs authored by someone else that the user personally opened, merged, or closed that day.
- PRs that received commits authored by the user that day.
- Standalone commits authored by the user that day.
- PR reviews submitted by the user that day.

Useful discovery queries include `gh search prs --author @me`, `gh search prs --reviewed-by @me --updated YYYY-MM-DD..YYYY-MM-DD`, and `gh search commits --author @me --author-date YYYY-MM-DD..YYYY-MM-DD`. Query created, merged, and closed PR dates separately. Search results identify candidates, not proof of the event actor. Inspect details and diffs before drafting, especially for state changes and standalone commits.

### Optional sources

- **Slack.** Use substantive channel messages authored by the user, including private channels. Eligible messages show a concrete decision, investigation, feedback, debugging, coordination, or customer-facing action. Keep thread links. Channel messages are eligible on their own; DMs and group DMs are outside the journal.
- **Linear.** Use issue creation or edits, comments, assignment actions, and state changes attributable to the user. Assignment to the user does not attribute someone else's action to them.
- **Calendar.** Consider non-declined meetings with at least one other attendee. Filter out focus blocks, reminders, out-of-office holds, and solo events before asking for attendance confirmation. Put confirmed meetings under Calls.
- **Notion and Figma.** Use attributable page or file creation, content edits, and substantive comments. Views, opens, and timestamps without an actor are not evidence of work.

## Reconciliation

- Attach commits to their PR when both describe the same change.
- Merge GitHub, Linear, Slack, document, and meeting evidence for the same work into one bullet.
- Group related reviews by project or change area instead of listing routine approvals separately.
- Keep substantive Slack-only work without requiring a second source.
- Preserve every distinct meaningful item. There is no bullet cap.
- Treat an existing bullet as a duplicate when it already represents the same work, even with different wording.

## Output contract

Use only these `###` sections, in this order, omitting empty sections:

1. `### Ships` for opened, merged, or closed PR lifecycle work and shipped standalone commits
2. `### Admin` for issue tracking, content management, and planning
3. `### Calls` for confirmed meetings
4. `### Reviews` for PR reviews
5. `### Personal` for non-work repositories and activity

Write top-level bullets as `- ` and nested details as tab-indented sub-bullets. Use verb-led, past-tense fragments, lowercase except for proper nouns, and backticks for known component names. Prefer the user's concrete wording or a useful PR title. Describe a standalone commit from its diff, not its raw commit message.

Link Vercel PRs as `[#12345](https://github.com/vercel/repo/pull/12345)`. For another owner, use `[owner/repo#123](https://github.com/owner/repo/pull/123)`. Link Linear issues by identifier, such as `[WEB-123](https://linear.app/...)`.

State the observed change or action. Include concrete, attributable work. Leave out inferred intent, business impact, sentiment, cosmetic-only changes, and passive views.

## Append rules

- For a new file, write the sections and a trailing newline.
- For an existing file, preserve its text byte-for-byte apart from the newline needed to attach new content.
- Add bullets to an existing matching section without duplicating the heading.
- Insert a missing recognized section before the next later section in the fixed order. If none follows, add it after the last existing section.
- When the file has no recognized sections, append the new content after the existing content.
- If existing content lacks a final newline, add one before the addition. Add one blank line when prose directly precedes the new list.

## Hard boundaries

- GitHub must pass the gate before any file is created or changed.
- Existing journal prose and bullets are immutable during an append.
- Authorship, links, attendance, and source support must come from evidence or the user's confirmation.
- This explicit-only skill coexists with `what-did-i-get-done`; it does not replace or modify that skill.