WHAT A WEEK OF USING GRIMOIRE TAUGHT ME

This week I got to use Grimoire the way I actually intended it to work.

I was able to sit down in ChatGPT and brainstorm an entire arc of work for a project. From that conversation, I could turn the plan into a set of scoped slices and save them into the project's architecture repository.

From there, I could move into implementation.

I opened separate Codex and Claude authoring sessions for each slice. With very little prompting, those sessions were able to follow the Grimoire, recover the architecture and current project context, understand the scope of the slice they were responsible for, and get to work.

When a session finished, the results were written back into the project repositories through the session-close flow. The activity record preserved what happened, CURRENT.md moved the project forward, and the next session could pick up from there without needing me to reconstruct everything manually.

That meant I could work through an arc one bounded session at a time while still keeping the larger architecture intact.

Once that arc was finished, I went back to ChatGPT, reviewed where the project had landed, and planned the next arc.

That was the loop I wanted Grimoire to enable:

brainstorm the architecture → define the work slices → execute them across different AI tools → preserve the results → return to architecture and plan the next arc.

And for the most part, it worked.

The Problems I Found

The interesting problems I found were not failures of that core workflow. They were smaller protocol issues exposed by actually using it.

One session trusted an older work pointer in AGENTS.md instead of the newer CURRENT.md. Another local session had an out-of-date checkout of the architecture repository and therefore thought an already-completed slice still needed validation.

Both problems came down to knowing where the authoritative state lives and making sure the session is reading the current copy of it.

Applying the Lessons

I recorded those findings in my personal Grimoire, fixed the behavior there, and then pushed the lessons back into the main Grimoire repository.

The protocol now has clearer ownership of project state, and the resume flow does more of the work automatically: checking repository freshness, loading the right context, and following the correct source of truth without me having to repeatedly remind the session how to use Grimoire.

The authority rules are intentionally simple:

• architecture/ owns durable intent, constraints, structure, and promoted design decisions.
• activity/CURRENT.md owns current execution state and the single next action.
• dated activity records preserve evidence and history.
• AGENTS.md and FAMILIAR.md explain how the repository should be read and operated.

And when a session is using a local checkout, it now verifies that the checkout is current with its configured upstream before trusting the project state.

Know which artifact owns the truth, then make sure you are reading the current copy of it.

The Result

So the biggest result from this week is that the basic idea held up.

I was able to maintain context between ChatGPT brainstorming sessions, Codex implementation sessions, and Claude implementation sessions while moving through real project work. The architecture and source repositories remained the shared durable context between all of them.

The workflow was not theoretical anymore. I used it to architect an arc, execute its slices, preserve each session's results, finish the arc, and come back to ChatGPT to plan the next one.

The friction I found was mostly around state freshness and protocol enforcement, not around the central idea of routing context through Git.

I've added those findings, fixed them in the main Grimoire repository, and now I get to try the next arc with less manual prompting and a cleaner session startup.

That is exactly the kind of iteration I wanted this project to produce.