Use Cases

Ayumi is deliberately narrow: it captures thoughts and writes them to disk as Markdown. The interesting part is what you build on the other side of that folder.

This page collects patterns people actually run. They all share the same shape:

capture (Ayumi) → a folder of Markdown → an agent or script reads it on a schedule → output goes somewhere you’ll actually look.

Nothing here is a built-in Ayumi feature. Ayumi’s job is to make step one fast and to leave the files in a format the rest of the pipeline can read without an API.

The shared foundation

Everything below depends on two facts about how Ayumi writes entries — see Markdown Format for the full reference.

Entries are nested by date under your journal folder:

journal/
  2026/09/13/
    2026-09-13_08-12-44-201.md
    2026-09-13_08-12-44-201.assets/
    2026-09-13_21-40-03-118.md

And each file starts with flat YAML frontmatter:

---
id: "550e8400-e29b-41d4-a716-446655440000"
created_at: "2026-09-13T17:12:44+09:00"
updated_at: "2026-09-13T17:12:44+09:00"
tags:
  - daily
transcription_model: "gemini-2.5-flash"
transcription_prompt: "Reflection"
---

That is the whole integration surface. Any agent, script, or editor that can walk a directory and parse YAML can consume your journal.

Directories are UTC, timestamps are local

The YYYY/MM/DD folders and the filename are generated in UTC, while created_at carries your local time with its offset. If you group by calendar day in a non-UTC timezone, read created_at from the frontmatter rather than trusting the folder name — an entry written late at night can land in the next day’s folder.

A minimal “everything from the last 24 hours” selector, which most of these pipelines start with:

find "$JOURNAL" -name '*.md' -newermt '24 hours ago' | sort

---

1. A voice journal for daily reflection

The simplest loop, and the one worth building first.

During the day, capture is hands-free. Bind Start Recording to the Action Button or Back Tap (iOS Shortcuts), talk through whatever is on your mind while walking or between meetings, and stop from the Dynamic Island. Each recording becomes an entry once transcription finishes.

In the evening, you read the day back. Because the entries are already on disk, “reading back” can be as simple as opening the app — or you can hand the day to an AI:

Read every entry in my journal from today. Give me:
1. What I actually spent the day thinking about (not what I planned to).
2. Anything I said twice — repeated worries are signals.
3. Three questions I should answer tomorrow.
Write it to reviews/2026-09-13-daily.md. Don't modify the entries.

What makes this work

Choice	Why it matters
A transcription prompt preset that keeps your words	Reflection needs what you said, not a tidy summary. Use a light-touch preset, or Apple’s on-device transcription for verbatim text.
A daily tag	Gives every downstream job a cheap filter.
Reviews written to a separate folder	Entries stay an append-only record; derived text lives elsewhere.

Tip

Resist the urge to have the AI rewrite entries in place. The value of a journal is that it is a record of what you thought at the time. Derived documents are cheap; the original is not.

---

2. Scheduled agent reviews that land in Slack

Once a daily review works by hand, schedule it — and let the scheduled job route different kinds of material to different specialists.

The shape

A single scheduled job runs once a day (or weekly), collects the recent entries, and dispatches them:

1. Collect entries from the last 24h.
2. Classify each one: career / research / product / personal / noise.
3. For each non-empty bucket, hand the entries to a subagent with
   a prompt written for that bucket.
4. Collect the subagent outputs.
5. Write reviews/2026-09-13.md, and post the short version to Slack.

Subagents matter here because the prompts genuinely differ. A career-coaching pass and a research-recap pass are not the same job:

Bucket	Subagent prompt, roughly
Career coaching	”You are a career coach who has read six months of this person’s journal. What’s the pattern in what they’re avoiding? What would you push them on this week? Be specific and uncomfortable.”
Research recap	”These entries are me thinking out loud about things I was investigating. Summarize what I learned, what’s still open, and what I should read next.”
Product ideas	”Extract every concrete product or feature idea. One line each, with the entry it came from.”
Personal	”Summarize for me only. Never include this in anything posted externally.”

Wiring the schedule

The scheduler is your choice — anything that can run a command on a timer works:

• launchd / cron on the Mac, running an agent CLI against your journal folder.
• A scheduled cloud agent pointed at a synced copy of the folder.
• A Shortcuts automation, for lightweight, phone-side jobs.

Posting to Slack is a webhook or an MCP Slack tool — the agent already has the summary as text, so delivery is the easy part. Keep a Markdown copy on disk regardless of where the notification goes; Slack is a notification channel, not an archive.

Make the job idempotent

Store the timestamp of the last processed entry in a state file and select entries strictly after it. Otherwise a retry — or a laptop that woke up twice — produces duplicate reviews. Filtering on created_at rather than file mtime also protects you from iCloud touching files during sync.

Decide what leaves the device

A scheduled job that posts to Slack is the point where a local-first journal stops being local. Be deliberate:

• Bucket entries you never want forwarded (the personal bucket above) and stop them at the subagent boundary.
• Post the distilled summary, not raw entries.
• Consider a #private tag that the collection step filters out before anything else runs.

---

3. Feeding an LLM wiki-style knowledge base

A journal is a stream. A wiki is a structure. Running a job that converts one into the other gives you both, without asking you to think about organization at capture time.

The division of labor

Layer	Role	Mutability
Ayumi entries	Timestamped record of what you thought	Append-only
Wiki pages	One page per concept, person, project, or decision	Rewritten freely by the agent

The wiki lives in its own folder — often the same Obsidian vault, since Ayumi entries are already Obsidian-compatible — and every wiki page links back to the entries it was distilled from.

The distillation pass

A weekly job that reads new entries and updates the wiki:

For each entry since <last run>:
  - Identify the concepts, projects, and people it touches.
  - For each, update wiki/<concept>.md:
      * Merge the new thinking into the existing page.
      * If it contradicts what the page says, keep both and
        mark the change with its date — don't silently overwrite.
      * Append a source link to the entry file.
  - Create pages that don't exist yet, and link them with [[wiki links]].
Then list every page you touched, so I can review the diff.

Why it works well with Ayumi

• Backlinks are free. [[Wiki Link]] syntax in the wiki plus relative links to entry paths means Obsidian’s graph view works across both layers.
• Frontmatter is structure. tags, created_at, and location_place_name give the distiller real metadata to organize on.
• The wiki is disposable. Because the entries are the source of truth, you can delete the entire wiki and regenerate it with a better prompt. This is the main reason to keep the two layers separate.

Tip

Version the wiki folder with git and let the agent commit. The commit log becomes a readable history of how your understanding of a topic changed — which is hard to get any other way.

---

4. From spoken idea to pull request

The most direct payoff of fast capture: ideas you have away from the keyboard become code.

You are walking, and you say out loud, “the export sheet should remember the last folder you picked — right now it resets every time, which is annoying.” That sentence is now an entry. A nightly job can turn it into a pull request.

The pipeline

Nightly:
  1. Read entries from the last 24h.
  2. Extract anything that is a concrete change to one of my repos.
     Ignore vague wishes — require a specific behavior change.
  3. For each one:
       a. Match it to a repository. Skip it if the match is unclear.
       b. Open the repo, read the relevant code, and confirm the
          change is actually small and self-contained.
       c. If yes: implement it on a branch and open a DRAFT pull request.
          Quote the journal entry in the PR description.
       d. If no: write it to backlog.md instead, with what makes it big.
  4. Post the list of opened PRs and deferred items to Slack.

Guardrails that make this safe to leave running

These are the difference between a useful pipeline and one you turn off after a week:

Guardrail	Why
Draft PRs only, never merges	You review every change. The agent’s job is to remove the blank-page cost, not to ship.
An explicit repo allowlist	The agent works only on repositories you named. Ambiguous matches get deferred, not guessed.
A size ceiling	”If this touches more than N files or needs a design decision, write it to the backlog instead.” Small, verifiable changes are where this succeeds.
Tests must pass before the PR opens	An unverified PR costs more to review than the idea was worth.
Quote the source entry in the PR body	Three days later you’ll want to know why this PR exists and what you actually meant.

Marking intent at capture time

Give the extractor an easy signal. A second transcription profile — or just a habit of starting those recordings with “idea for Ayumi:” — is enough for the classifier to be reliable. A #dev tag works too, and costs one tap.

Note

Expect a low hit rate, and that’s fine. Most spoken ideas are not implementable changes. The pipeline earns its keep on the handful each month that would otherwise have been forgotten on a walk.

---

Building your own

The patterns above are variations on the same four decisions:

1. What triggers capture? A hardware button, a Shortcut, the Watch, the widget — whatever removes the pause between thinking and recording.
2. What shape should the text be? Verbatim for reflection, structured for extraction. This is what transcription prompt presets are for.
3. What runs on a schedule, and how often? Daily for review, weekly for distillation, nightly for automation.
4. Where does the output land? Slack for things you must see, Markdown for things you’ll search later, a pull request for things that become work.

Ayumi’s contribution is the same in all of them: the thought is on disk, in plain Markdown, within seconds of having it.

Related pages

• Concept — why capture speed is the constraint worth optimizing
• iOS Shortcuts — hardware triggers and background recording
• Voice Recording — transcription engines and prompt presets
• Markdown Format — the file layout and frontmatter your scripts will parse
• Sync with iCloud — getting the folder onto the machine that runs your jobs