[🤖] I Connected the Flow and Feel of My Work with Codex Skills

✨ GPT-5.6 Sol’s Summary

A record of keeping the flow intact by making Codex Skills reread the current rules and evidence, so the judgment I had just formed while setting up a Linux server could carry straight into the next task and the writing that followed.

Today I laid the operating foundation for a Linux server dedicated to company services. I installed Ubuntu Server on a new SSD, connected it over internal SSH, and designed user boundaries so that the human administrator, AI Cells, and business automation Runtimes could share one server without intruding on one another’s permissions or state.

I documented the server’s specific disk, network, and account structure separately in the post linked above. What I want to write about here is not the installation method, but the experience of finishing that work without losing the flow of judgment behind it.

Once I had recorded how the router, NAS, existing Runtime, and new Linux server fit together in a network Skill, I no longer had to explain the entire equipment list again in the next Codex session. I also separated what was already complete from what existed only as a design. The operational instincts I had developed while working on the server were now in a form the next task could inherit intact.

Nice. Now that I’m used to working with Skills, I can set things like this up in no time. This is great. Whatever the work is, keeping the flow going without losing the feel for it really does seem important.

What felt good was not simply that I had made one Skill quickly.

The operational feel I had just developed on the server carried into the user structure, that structure remained in the network Skill, and then it flowed into the devlog explaining the work. Once that post was written, I immediately thought of making another Skill that could find recent work in conversations and Git history and turn it into a diary entry.

Building a server and making a writing Skill are completely different tasks, yet in my head they belonged to the same flow. I kept thinking about what needed to be left behind so the next task would not have to start from scratch, and I was immediately applying the answer to the structure of the next tool.

The New Skill Reused the Flow I Had Already Built

I had previously created gsheet-hour-blocks to produce hourly work records for my personal scheduler. Rather than summarizing only the current conversation, it also reads Git history from related repositories and compresses what I actually did into sentences for time blocks.

This time, only the output was different.

The foundation was already there: read recent conversations, commands, tool results, and Git evidence from a specified period. Instead of extracting a task list from that evidence, the new Skill needed to find the problems I actually felt and the changes in my judgment, then write them as a standalone diary entry that followed the blog’s current rules.

There was no need to design everything from scratch. The method I had learned before became material for the next one.

I also had the experience of turning my endlessly repeated question—“Did you really do this perfectly?”—into a Skill called audit-and-fix-until-clean. When I notice a recurring demand, I stop writing another long prompt and solidify it into a reusable way of working with a clear stopping condition. After running into the same pattern several times, I could see much faster than before which parts belonged in a Skill and which should remain in the original project.

That feel for the boundary made it quick to shape the overall structure of blog-write-diary.

But Codex went in the wrong direction once.

Copying the Rules Would Split the Context Instead of Carrying It Forward

At first, it tried to move this blog’s category, style, date, and translation rules into the new Skill.

That was not what I wanted.

I don’t mean copy the rules into the Skill. More precisely, I want it to read the rules and context inside the cdb project directly. Moving the rules themselves can come later.

The blog’s rules keep changing. Copying them into the Skill would create the same rules in two places. It might work at first, but eventually the project’s current rules and the old rules remembered by the Skill would diverge. A device meant to carry context forward would end up freezing stale context instead.

So I made sure blog-write-diary did not own the blog’s rules.

What the Skill remembers is only the procedure: in what order to read the current conversation, commands, and Git evidence; how to find the single thread connecting them; and that it must reread cdb’s current AGENTS.md, categories, and neighboring posts before writing the actual post.

Rules that change stay in the original project. Every time the Skill runs, it returns to that source of truth.

That distinction was the heart of it. Instead of making AI remember every piece of context forever, I built a path that lets it reenter the current context accurately when needed.

What Carried Forward Was Not the Information but My Sense of Judgment

AI context is limited. Long conversations get compressed, and when work moves to another session, subtle judgments from the previous one disappear easily. But I cannot preserve every conversation forever and make AI reread all of it every time either.

Preserving all the information was not the important part.

At the start of the next task, I needed to be able to reconstruct why a boundary mattered, what had already been rejected, what I had decided to protect, and which source should be trusted now. With that state restored, AI can continue the judgment that came before instead of merely imitating its conclusion.

The same was true for me.

Today I could immediately see why server accounts and Runtimes had to be separated, and why project rules must not be copied into a Skill. The reasoning behind those judgments was still hot. Once time passes and only a hazy conclusion remains, rereading the same explanation does not bring me back into the work with the same feel nearly as quickly.

I once wrote that human memory is compressed and comes alive again through cues. This time, I had turned that thought into an actual way of working.

Skills, AGENTS.md, and Git history are not warehouses that preserve every moment. They are cues that let the AI in the next session—and my future self—reconstruct the judgment needed to reenter the work. A path that lets me follow the current sources and evidence back to a conclusion was more useful than a single well-preserved conclusion.

While the Feel Is Alive, I Build the Next Part of the Flow

What made this enjoyable was not merely that I had built blog-write-diary quickly.

The feel I gained while setting up the Linux server carried into the user structure and network Skill. That operational judgment carried into the devlog, and the flow of writing that post led into designing a new diary Skill. At no point did I have to return completely to the beginning.

That was what felt so good.

Whether I am developing software or writing, moving into the next task while the judgment built in the previous one is still alive does more than make me faster. I do not have to wander around rediscovering what matters, so the level of the result carries forward too. I can explain why something works, and when a structure is wrong, I can stop sooner.

The structure I created to deal with AI’s short context is now compensating for my short memory as well. But the fact that people and AI both forget is not the whole conclusion of this post.

What I want to keep building is less a memory device than a device for reconnecting the flow.

So that the next time I begin, I do not have to explain everything from scratch and struggle to regain the feel, but can take the very next step from the judgment I have already reached.