My Long-Horizon Codex × Obsidian Handoff Workflow

Lately I have been trying to answer a simple question: if I want Codex to become my main handoff partner for research work, what should my workflow actually look like?

My earlier setup looked fairly traditional: project cards in one area, daily logs in another, plus overview pages to pull tasks together. It worked, but one problem became increasingly obvious:

I was maintaining the same context over and over again.

Project goals lived in project cards. Today’s work lived in the daily log. Cross-session continuation required another manual explanation. The system itself slowly became overhead.

So I recently compressed the whole thing into a lighter structure: a four-file project memory layer + a daily log + a session archive. The goal is simple: in the future I should only need to tell Codex “continue this project,” and Codex should reconstruct the rest of the context on its own.

What was wrong with the old setup#

The old setup did not fail because I was not documenting enough. It failed because the documentation was duplicated and scattered.

In practice, that meant:

the project card stored long-lived goals, next steps, waiting items, and project tasks;
the daily log repeated which project I was pushing that day and what remained unfinished;
each new conversation required yet another manual handoff.

This created two real problems. First, the most important long-lived state did not have a single stable entry point. Second, I still had to reorganize context myself every time I resumed work.

For long-horizon research, that workflow was too heavy.

The new structure I use now#

I now split the workflow into three layers:

long-lived project memory
daily execution
cross-session handoff

1. Long-lived project memory: the four-file set#

Each active project now keeps four files:

Prompt.md
Plan.md
Implement.md
Documentation.md

Each file has a narrow role.

`Prompt.md`#

This stores relatively stable information:

project goal
key constraints
non-goals
done definition

In other words, it answers: why does this project exist, and what counts as finished?

`Plan.md`#

This stores stage-level execution structure:

current phase
milestones
current 1–3 next actions
validation rules
stop rules

It answers: how should this project move forward in the current stage?

`Implement.md`#

This stores the operating protocol for Codex itself:

what to read first at the beginning of a session
what to update at the end
what kind of information belongs in which file
what should not be mixed together

It is basically the project’s own handoff contract.

`Documentation.md`#

This is the most important file. It acts as a single-page working memory for the current state of the project.

It stores:

current status
known facts
key judgments
current risks
recent progress
exact next step

If I only ask Codex to read one project file before continuing, this is the one I want it to read first.

2. Daily execution: the daily log#

The daily log still exists, but its role is much smaller now.

It only records:

my top three priorities today
which projects I pushed today
what I actually did today
key judgments, blockers, and reflections from today
what I should do tomorrow
what Codex should pick up next time

So the daily log is now truly about today, not about long-term project memory.

3. Cross-session handoff: the session archive#

Besides the daily log, I keep a separate session archive:

YYYY-MM-DD-会话NN.md

Its only job is to help the next conversation continue smoothly. A session note records:

what the current conversation completed
which files were modified
what key judgments were made
what remains unresolved
where the next session should resume

This is not the main project notebook. It is a lightweight continuation bridge.

How I actually use it#

The working style is now intentionally simple.

When starting work#

I only need to say something like:

Continue YK-RL
Switch to the Chinese platoon review
Continue yesterday's direction exploration

Then Codex reads, in order:

the project’s Documentation.md
the project’s Plan.md
the latest relevant session archive
today’s daily log
Prompt.md if needed

So I no longer prepare a long manual handoff paragraph.

When ending work#

I only need to say:

Let's stop here, leave a handoff
Write a session summary
Record today's state

Then Codex handles the rest:

update the project’s Documentation.md
update Plan.md if needed
update today’s daily log
write a new session archive note

Why this works better for me#

My current work is not a single short task. It is a set of parallel long-horizon efforts: one paper that needs to be wrapped up, one review that still needs scope definition, and one future direction that needs to be compressed into a small number of viable research options.

For this kind of work, what I really need is not more dashboards. I need more stable recoverable context.

This structure works better because:

long-lived information is no longer spread across project cards, daily logs, and verbal explanations;
daily execution is separated from project memory;
session handoff has its own lightweight layer;
I am no longer the one responsible for reconstructing context — Codex is.

At its core, this is not about “writing down more things.” It is about something more important:

separating long-lived memory, daily execution, and cross-session handoff into clean layers.

What I cleaned up#

To make the new workflow real, I also removed several pieces of the old setup:

the old 00-项目总览.md
the old 00-日志总览.md
the old project_card_template.md
the old 写作计划.md files that used to act as part of the main workflow

At the same time, 项目卡.md is no longer treated as a large all-in-one project record. It is now a lightweight entry page.

I only keep supporting notes that still have real value, such as literature classification tables, direction notes, daily logs, and session archives.

Closing#

If I had to summarize the change in one sentence, it would be this:

I no longer treat project management as a system that I must maintain manually; I treat it as a project memory structure that Codex can read, update, and continue.

This workflow is not trying to be sophisticated. It is trying to achieve one practical outcome: the next time I start working, I say one sentence and the system picks up from there.

I will keep running a few more cycles with this setup and see how much further it can be compressed and stabilized in real long-horizon research work.