What Is Chronicle?

Chronicle is a context skill for resolving “what am I looking at / what was I just doing?” ambiguity from your local screen history. It works in two layers: 1. **Live/recent screen frames** It reads Chronicle’s rolling screen-recording buffer under `$TMPDIR/chronicle/screen_recording/`. The latest frame files show the current screen per display, and the `1min/` folders hold privacy-filtered historical frames. 2. **Persistent Chronicle memories** It can also use summaries stored under `~/.codex/memories/extensions/chronicle/`, including rolling 10-minute and 6-hour markdown summaries that can be referenced later through Codex memory. The intended workflow is conservative: first verify Chronicle is currently running, then check whether the recording files are fresh, then use the latest frame or OCR sidecars only to get enough context to route the task properly. OCR is meant for searching terms or timestamps, not as an authoritative source. Once the relevant app/document/repo/error is identified, the assistant should switch to a better source like the filesystem, GitHub, Google Drive, Gmail, or another app connector. In this session, Chronicle appears to be running, so the skill is available. I did not inspect your current screen because your request was to explain the skill, not resolve screen context.

I’m going to treat this as a Chronicle question, so I’ll verify the local Chronicle state and check memory for prior mentions rather than answering from the skill text alone.

The memory registry has many Chronicle-generated entries, and it also has a repo-specific note that `chronicle` was deliberately left with uncertain provenance during the skill-labeling cleanup. I’m checking the repo history now to separate “installed/used locally” from “known author/source.”

Repo history shows `skills/chronicle/SKILL.md` first appearing in a May 15 public skills library refresh commit, not in the later Maggie-created-skill normalization work. I’m checking that commit’s contents so I don’t overstate authorship.

Chronicle came from the **Codex screen recording / memory feature**, not from this repo originally. The skill text says it is enabled when Codex Chronicle screen recording is enabled, and it stores rolling screen frames plus generated memory summaries. It also points to the original implementation as `openai/codex`. Repo-local provenance is less certain: in `/Users/maggielerman/Github/codex-skills`, `skills/chronicle/SKILL.md` first appears in commit `46774fd` on **May 15, 2026**, titled `Refresh public skills library`. That commit added `skills/chronicle/SKILL.md` and added `chronicle` to `skills/SUITE_SKILLS.txt`. Prior repo memory explicitly says `chronicle` was **left unresolved / uncertain-provenance**, not classified as Maggie-created. Yes, we have used it. There are currently **294 Chronicle memory summary files** under `~/.codex/memories/extensions/chronicle/resources`, spanning at least **May 28, 2026 through June 4, 2026**. Memory also has many “Chronicle adds…” notes where prior work used Chronicle summaries to reconstruct context across Hyphenomenon, RPS, TMORA, OpenAI Platform, and codex-skills work. In this thread specifically, I verified Chronicle is currently running, but I have not inspected your live screen. <oai-mem-citation> <citation_entries> MEMORY.md:1389-1392|note=[chronicle provenance left uncertain during skill labeling cleanup] MEMORY.md:1403-1406|note=[do not classify chronicle as Maggie-created without confirmation] MEMORY.md:1357-1360|note=[example Chronicle memory resource tied to codex-skills work] MEMORY.md:1133-1134|note=[example prior use of Chronicle for validation and upload context] MEMORY.md:1664-1664|note=[example prior use of Chronicle for cross-surface fulfillment context] </citation_entries> <rollout_ids> 019e7e66-8dcb-7443-9876-40b7a870ed75 019e8406-a75d-7a80-9206-1502de35ec52 </rollout_ids> </oai-mem-citation>

I’ll answer this from the Chronicle skill contract plus the local storage layout, and I’ll only inspect filenames/counts rather than opening your screen captures.

Yes, you’re understanding the broad idea correctly, with one important distinction: Chronicle stores **work-visible evidence**, not a clean canonical project-state database. Right now Chronicle is running. Locally I see: - **Raw recent screen data** in temp storage: latest screen frame, capture metadata, OCR sidecar, and historical frame JPGs. - **Persistent Chronicle memory summaries** under `~/.codex/memories/extensions/chronicle/resources`. - Current counts: `1` latest frame, `1` OCR stream, `1390` historical frame JPGs, and `295` Chronicle memory summary files. - The persisted summaries currently span at least **May 28, 2026 to June 4, 2026**. What it stores: - **Latest screen frame**: what was visible recently. - **Historical sampled frames**: visual snapshots over time. - **OCR sidecars**: searchable text changes from the screen, useful for finding terms/timestamps but not reliable as final text extraction. - **Markdown summaries**: rolling 10-minute / sometimes 6-hour summaries of recent screen activity, persisted into Codex memory. So yes, it could support a **visual timeline of projects**, especially questions like: - What project was I working on around this time? - What app/page/file was visible? - What did the homepage/dashboard/proof/admin page look like then? - What did I review before switching projects? - What was the apparent state of a workflow before/after a Codex run? But for true **project state**, Chronicle should be paired with stronger sources: - Git history for committed code state. - Working tree snapshots for local uncommitted state. - Generated artifacts/screenshots/PDFs for review state. - App/browser QA records for visual state. - Docs/checkpoints for lifecycle state. Best framing: Chronicle can provide the **visual and activity timeline**, then we reconcile that with repo/app evidence to produce a reliable project-state timeline.

For this, I’m using Chronicle as the subject matter, not as a reason to open your captures. The key design question is whether this is a passive visual library first or a project-state system first.

Yes. A clean white “Photos for work history” viewer is a very reasonable first version, and it is much smaller than a full project-state system. **Lift Estimate** - **Simple visual gallery:** 0.5-1 day Local web page that scans Chronicle frames/summaries, groups by date, shows a dense white canvas, and opens frames in a detail view. - **Useful project timeline:** 2-4 days Add project labels from Chronicle summaries, `cwd`, visible app/page hints, search, date scrubber, and “nearby frames.” - **Reliable project-state timeline:** 1-2+ weeks Reconcile Chronicle visuals with Git commits, branches, docs checkpoints, screenshots, generated artifacts, and app routes. - **Polished private product:** 3-4+ weeks Persistent indexing, thumbnail cache, privacy controls, filters, export packets, timeline annotations, and cross-project evidence linking. The important distinction: Chronicle can show **what was visible and what you were doing**, but “project state” needs corroboration. A screen frame can show a PR page, app preview, Photoshop proof, or Shopify admin screen; Git/docs/artifacts tell us whether something was committed, pushed, merged, shipped, or only reviewed. A strong MVP would be: - White endless canvas, grouped by day/month. - Dense thumbnail grid like Apple Photos. - Right-side date/time scrubber. - Click any frame to see larger image, timestamp, nearby frames, OCR matches, and Chronicle summary. - Filters for projects like `hyphenomenon`, `rps-etsy`, `family-shapes`, `codex-skills`, TMORA, etc. - Local-only serving. No upload, no cloud, no public docs-site exposure. I’d build it as a private local viewer first, not as part of the public `docs-site`. The first useful version is probably just: index Chronicle resources, generate thumbnails, render a gallery, and let you scrub through time. Then we can add project-state overlays once the visual timeline is working.

Copy this into a fresh thread: ```text Build a private local Chronicle visual timeline viewer. Context: Chronicle stores recent/historical screen frames and persisted memory summaries. I want a clean white endless-canvas interface inspired by Apple Photos / Google Photos: dense thumbnails grouped by time, with a date scrubber, click-to-open detail view, and project filters. Repo: Use /Users/maggielerman/Github/codex-skills unless there is a better private local-tool location. Do not put this on the public docs-site. Keep it local/private. Goal: Create an MVP that lets me browse Chronicle as a visual work-history library. Requirements: - Inspect the Chronicle skill first: /Users/maggielerman/.codex/skills/chronicle/SKILL.md - Verify Chronicle is currently running before reading live/recent captures. - Do not upload anything or expose screenshots publicly. - Index local Chronicle resources: - $TMPDIR/chronicle/screen_recording/ - ~/.codex/memories/extensions/chronicle/resources/ - Build a local web viewer with: - clean white canvas - dense thumbnail grid grouped by date/time - month/day headings - right-side date/time scrubber if practical - click thumbnail to open larger frame/detail view - show timestamp, source path, nearby frames, and related Chronicle memory summary when available - basic search over filenames, summary text, and OCR sidecars - project filters based on summary/cwd hints like hyphenomenon, rps-etsy, family-shapes, codex-skills, TMORA, Shopify, Gmail, etc. - Treat OCR as noisy search metadata only, not authoritative text. - Use generated thumbnails/cache so browsing is fast. - Keep the implementation lean and local-first. - Start a local dev server when done and give me the URL. Important: This is a visual timeline, not yet a canonical project-state database. If you add project-state labels, mark them as inferred unless confirmed by Git/docs/artifacts. ```