The mining flow

Mining turns work you actually did into content ideas. It runs on your machine, not on the server.

your machine                                      postlyra
──────────────────────────────────────────────    ──────────────────────
git log ─┐
         ├─► the agent reads it ──► drafts ideas ──► push_ideas ──► Ideas
notes  ──┘   (it runs here, the server does not)                     │
                                                                     ▼
                                                    Planning, then promote
                                                    to a draft, then approve

Raw commit messages and note text never leave the machine they were written on. Only finished ideas travel.

The four steps

An agent should follow the same shape the CLI does.

1. Get the context

Call get_mining_context. You get back the brand's voice, pillars and persona, plus refs: every source ref already attached to an existing idea, within a 90 day window.

2. Read the material yourself

The agent runs on the user's machine. The server does not. So the agent reads the git log, the notes, whatever the material is.

git log --since="7 days ago" --no-merges --pretty=format:'%h%x09%ad%x09%s' --date=short

3. Drop what is already known

Build a ref for each item, then discard anything whose ref appears in the refs from step 1.

This is the important step. Doing it before the drafting means you never spend tokens re-analysing work that already produced an idea, and it works across machines because the state lives server side.

4. Push

Call push_ideas with up to 25 ideas, each carrying source_refs built the same way.

Refs

A ref is a stable identity for the material an idea came from. The conventions the CLI uses:

Material	Ref	Example
A commit	<repo-label>@<short-sha>	myrepo@a1b2c3d
A note file	vault:<filename>	vault:2026-08-14-queue-bug.md
One bullet in a list file	vault:<filename>@<hash>	vault:content-inbox.md@3f9a21bc

Use these if you also use the CLI, so the two agree about what has been mined. Otherwise invent your own, as long as the same material always yields the same string.

Why refs and not text

Idea text is AI output. Ask two models about the same three commits and you get two different headlines, so text can never answer "have I already covered this". A ref can, because it identifies the source rather than the output.

There is a nice consequence: reformatting a note bullet keeps its ref, so it is not mined again, but rewording it changes the ref and it is mined again. Which is correct. The idea changed.

Re-running is safe

push_ideas computes an idempotency key from the sorted source_refs plus the headline. Pushing the same headline with the same refs updates the existing idea rather than creating a duplicate.

So a failed push can simply be retried, and an overlapping window does not produce doubles.

After the push

Ideas land with status new, in Studio under Planning, in the Library view. From there a human shortlists, dismisses, or promotes an idea into a draft. See Planning.

Nothing an agent does moves an idea past new.

Writing a draft directly

create_draft skips the idea stage and writes a draft straight into Planning, with an optional planned date and time.

A planned date is a calendar note, not a publish slot. The draft still sits at status draft until a human approves it, and approval is what makes scheduling possible at all. See Approve and schedule.