DEV Community: Entire

Never forget to enter the Stern Grove lottery again!

Lizzie Siegle — Fri, 26 Jun 2026 17:18:04 +0000

It's summer in San Francisco, which means that every week I forget to enter the lottery for the free Stern Grove Music Festival.

Solution? I did what any reasonable developer would do instead of just setting a calendar reminder: I built a Python script that runs weekly via GitHub Actions, scrapes the festival website with Playwright, and auto-enters the lottery for me.

The fun part is how I built it. I described what I wanted to a coding agent (I've done a lot of browser automation to automate tennis court bookings, make data visualizations, etc), and Entire recorded every prompt, tool call, and output along the way, so I have a complete, auditable record of how the whole thing came together. If you want to retrace the entire build yourself, here's the live session. Let me walk you through it:

It started with one message

The entire (lol) project began with a single message to my coding agent (I used Claude Code, but any agent works!) I gave it the rules of the game:

The Stern Grove lottery opens six weeks before each show at 10:00 AM and stays open for one full week to enter…

I also handed it the exact HTML for the entry button. Stern Grove runs its ticketing through Tixologi, so the agent needed to know what it was dealing with.

Then I told it about the secrets my GitHub Action would have access to:

First name
City
Email
A Resend API key (for notifications)
The "from" email address
Zip code All of these live as encrypted secrets in GitHub Actions--never committed to the repo--and I made sure the agent understood that constraint up front.

The architecture it proposed

Before writing a line of implementation, the agent explored the spec, asked one clarifying question, and proposed a clean design:

lottery.py — the entry point, triggered by a GitHub Actions cron schedule
browser.py — all the Playwright logic: web scraping and browser automation
state.py — loads and saves entered_lotteries.json so we never double-enter
notify.py — success and failure emails via Resend State persistence was the clever bit. Instead of standing up a database for a once-a-week job, the entered lotteries are tracked in a JSON file that gets committed back to the repo after each run:

{
  "entered": [
    { "event_id": "abc123", "show": "Show Name", "entered_at": "2025-06-21T10:02:00Z" }
  ]
}

The cron schedule lives in the workflow file:

# .github/workflows/lottery.yml
on:
  schedule:
    - cron: "0 17 * * 1"   # weekly check
  workflow_dispatch:

Inspecting before automating

Here's a step worth highlighting. Before touching any browser logic, the agent did a live inspection of the actual Stern Grove page — specifically window.tixologiWidget.concerts — to learn the real data shape rather than guessing.

Tixologi is a ticket and event management platform. That inspection documented the precise field names, the ISO 8601 date format, and the event ID structure. One console log it captured saved a lot of debugging later:

// What the page actually exposes
window.tixologyWidget.concerts
// → [{ eventId, name, startDate: "2025-07-13T19:00:00Z", ... }]

Grounding the implementation in real, observed data instead of assumptions is a major differentiator between code that works on the first real run and code that fails silently in production.

Pushing state back to the repo

state.py doesn't just read the JSON — after a successful entry it commits and pushes the update using a GitHub Personal Access Token (PAT), so the next run knows what's already been done:

def commit_state(token: str) -> None:
    subprocess.run(["git", "add", "entered_lotteries.json"], check=True)
    subprocess.run(["git", "commit", "-m", "Update entered lotteries"], check=True)
    subprocess.run(["git", "push"], check=True)

The review loop caught a real bug

When the agent added notify.py, a reviewer sub-agent immediately flagged two issues in the diff:

It was using print() statements instead of the logging module.
It had duplicated the Resend API key (for email) initialization. The agent fixed both before moving on to the next task. That's the task → review loop doing exactly what it should — catching the kind of sloppiness that usually only surfaces weeks later.

import logging

logger = logging.getLogger(__name__)
resend.api_key = os.environ["RESEND_API_KEY"]  # initialized once

def notify_success(show: str) -> None:
    logger.info("Entered lottery for %s", show)
    resend.Emails.send({ ... })

How to retrace every prompt, tool call, and output

This is the part I do genuinely find handy: I didn't have to remember how the automation got built, because Entire captured all of it. A session in Entire is the complete record of an AI coding interaction, ie every prompt, response, tool call, and file change. You can browse mine at the session link above.

Here's how to navigate it:

Find the session. Sessions live in the Sessions tab on a checkpoint detail page. Each row shows the agent that ran (Claude Code, in my case), a step count, the opening prompt, and a timestamp. Click one to open its timeline.
Read the timeline. The session timeline shows the conversation in order — my prompts, the agent's responses, expandable tool calls, and runtime tags. A metadata panel summarizes the model, duration, and token usage for the run.
Expand any tool call. Tool calls render as inline rows you can expand to see the exact arguments and results. For file edits, the expansion shows the diff right there.
Filter the noise. A filters rail on the right lets you toggle what's visible — prompts, responses, intermediate steps, checkpoints, and tool calls (further broken down into file edits, bash, read, and other). This is how I unchecked things to get a cleaner view when I just wanted something more high-level.
Drill into sub-agents. When the agent spun up that reviewer sub-agent via Claude Code's Task tool, Entire captured it as its own session with its own transcript and tool calls, rolled up into the parent checkpoint's totals. That's exactly where you can see the review loop that flagged the print()/logging issue.
Jump to the code. Every session links back to its Git commits through an Entire-Checkpoint trailer, so you can open the matching checkpoint or the underlying commit on GitHub. The metadata itself lives on a distinct separate entire/checkpoints/v1 branch, which keeps your main history clean. So the screencast you're watching isn't the only record-- the full reasoning behind every line is sitting in that session, ready to rewind through.

It didn't work at first!

I'll be honest: the first real run failed. CI rarely cooperates on the first try, and this was no exception. Two environment issues bit me:

1. Ubuntu version drift. I had to pin the runner to Ubuntu 22.04 for Playwright compatibility. ubuntu-latest had quietly become Ubuntu 24.04 in 2025, and the libasound2 package was renamed in the process.

2. Chromium dependencies. I ended up installing the Chromium deps manually with the correct Ubuntu 24.04 package names instead of relying on Playwright's bundled installer.

The fix went from this:

# before
- run: playwright install --with-deps chromium

to explicit apt installs plus a leaner Playwright step:

# after
- run: |
    sudo apt-get update
    sudo apt-get install -y libasound2t64 libnss3 libnspr4 # ...correct 24.04 names
- run: playwright install chromium

Success!

Finally, it ran cleanly. I got the confirmation email straight from Stern Grove and Resend.

The stack came together nicely:

Playwright for the browser automation
GitHub Actions for the weekly cron schedule and secret management
Resend for success/failure notifications
A coding agent (Claude Code) to build it, with a review loop that caught real bugs
Entire capturing every prompt, tool call, and output, linked to the commits I can't wait to see what you build with the same pieces, and now you (and I) won't forget to enter the Stern Grove lottery this summer.

Human Attention is a Scarce Resource

Rizèl Scarlett — Mon, 22 Jun 2026 12:20:08 +0000

I recently chatted with a Distinguished Engineer about how he uses agents in his engineering workflow and how he builds new team processes around AI-generated work.

// Detect dark theme var iframe = document.getElementById('tweet-2068069283184144450-524'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2068069283184144450&theme=dark" }

During the conversation, David Fowler made a really poignant take: when producing code becomes trivial, human attention becomes scarce resource. 🤯

You can listen to our full conversation on Spotify. (It's a recording of a Twitter Space I did with him. People have said they really enjoyed the spaces I run, so I saved them as lightly edited podcast episodes).

See below for my own thoughts on code review in the world of agentic coding:

My own thoughts

For decades, software engineering has relied on a foundational necessity: a reliable paper trail. As version control matured from changelogs to CVS to modern Git diffs, we built our craft around durable artifacts that preserve intent, track progress, and safeguard quality.

Historically, this system worked because software development operated at human speed. An engineer reasoned through a problem, committed code, and opened a pull request. Colleagues reviewed that code, engaging in a back-and-forth dialogue to unpack the underlying logic. We deliberately used this collaborative friction to maintain code quality.

But today, a new class of autonomous collaborators has disrupted the traditional engineering workflow.

Coding agents have drastically compressed the implementation window from typing code line-by-line to writing a single prompt that generates a full feature. The most forward facing teams are already moving past single-agent execution, orchestrating parallel sessions where a main agent manages subagents to complete larger bodies of work on demand. (When I worked at Block, this became the way many teams I encountered worked).

This sudden leap in speed is intoxicating, but it threatens to outrun our ability to keep software trustworthy. In practice, an engineer uses an agent to generate hundreds of lines, but the engineer only skims the results. Reviewers facing a growing backlog do the same. If the Git diff looks right, the team ships. Then a production outage occurs. In the past, you could bring the authoring engineer into the incident room to trace their logic and patch the system. But when the decision was made by one of a dozen subagents running in parallel, there is no one to bring in, and the commit history shows only the result, not the reasoning.

This is the central problem I keep seeing in AI-native development: we can now produce code faster than we can understand it. And yet, for an industry obsessed with artifacts, meticulously tracking commits, pull requests, and logs, we often throw away the one record that explains all of them: the agent session itself.

The company I work at, Entire, has been aiming to maintain velocity without sacrificing engineering integrity by preserving agent sessions alongside the tools developers already use. The full chain of AI-assisted work, including prompts, responses, tool calls, subagent activity, checkpoints, and the final commit, can all become part of the engineering context. The mechanics do not have to be heavy. We do this using lightweight hooks around the agent and Git workflow.

But the purpose of capturing session history is not for users to simply reread a diary of logs and transcripts. (A lot of people tell me, "So what, I don't want to read the logs!") Instead, session history can become an active surface for understanding, unlocking capabilities that standard Git diffs simply cannot support.

When an engineer or agent needs to understand a complex block of autonomous code, the investigation should not stop at a timestamp, a commit hash, or a best guess. I want to be able to ask why this implementation exists, what prompt produced it, which agent or subagent touched it, and what validation or review context shaped the final result.

If we want to build at this new speed without losing our grip on the codebase, a static diff of the final code is no longer enough. When the system breaks at 2:00 AM, we cannot rely only on tools built for a human pace to audit agent-to-human collaboration. To keep our systems reliable, we have to preserve more of the actual narrative of how the software came to be.

Because in an AI-native world, the session is the story.

Check us out on entire.io !

And check out this episode of a crazy time I was on an AI coding game show for CodeTV . I look back at this episode many times, and just think "Ugh, we should've used Entire. It would've made handing off work between my team so much easier."

How I Added Goose as an External Agent to Entire

Rizèl Scarlett — Thu, 11 Jun 2026 19:13:21 +0000

I just opened a PR to add support for Goose to Entire. Goose is an open source coding agent under the Agentic AI Foundation, the first ever MCP client, and a reference implementation for the Model Context Protocol. I am super excited about this because it is exactly where my two worlds collide. I previously worked on the team building out Goose. Although I left the team to join Entire, I still maintain the Goose documentation and stay semi-active in the project.

This post walks through how I built the integration. It also doubles as a guide for adding support for your own favorite agent to Entire.

What is Entire?

The traditional software development lifecycle was not built for AI agents, so Entire is building the one that is. We identified major friction points that make it hard for humans and agents to collaborate. For example, agents often put up massive PRs that human developers simply do not want to review. Additionally, you completely lose the reasoning behind AI-generated code days after it gets merged because no human actually wrote it.

We have much more coming down the road, but we started by launching a CLI-first tool that records your agent sessions. It logs the prompts, the agent responses, tool calls, and everything in between.

That way, when you want to find out why a feature was implemented a certain way, you can go straight to the transcript and read through it .Personally, I prefer to either ask my agent or run a command like entire checkpoint explain to get a summarized rundown of the exact conversation behind a line of code. All sessions get version controlled via git and live on a dedicated metadata branch within the same repo.

Why add your own agent?

Entire ships with built-in support for leading coding agents like Claude Code, Gemini CLI, Codex, Cursor, and Copilot CLI. But the agent ecosystem moves incredibly fast, and no single team can support every new tool that drops.

So, we built the external agent protocol that allows you self-serve add support for any agent you prefer to Entire. It gives you a completely self-serve way to add support for any agent you prefer. The user experience is identical to using a built-in agent. All the exact same commands and functionality just work. If Entire doesn't support your favorite agent yet, you don't have to wait on us. You can build the integration yourself directly in the entireio/external-agents repo.

Why Goose?

As a maintainer and former full-time developer on Goose, I've been looking for the perfect excuse to wire it up to Entire. The main technical blocker was that Goose didn’t support hooks. Hooks inform Entire when a session starts, when a user submits a prompt, and when the agent finishes a turn. This allows Entire to know when to start and stop recording the session activity.

Recently Goose implemented support for hooks, following the Open Plugins hooks spec, so now I could fulfill my dream.

What your agent needs

To wire your agent up to Entire, it needs to have the following:

A hooks or lifecycle mechanism: You need a reliable way to run an external command when a session starts, a prompt is submitted, or a turn ends. Without this, Entire cannot observe the session.
Readable session data: You need access to transcripts or an exportable session store containing the actual conversation. We need real assistant responses and precise tool calls, not generic placeholder text like "Working...".
Stable session identity: A consistent session ID that you can extract from hook payloads, ideally paired with a resume command (like goose session --resume --session-id <id>).
A non-interactive CLI mode: Running commands cleanly (for example, goose run -t "prompt") makes writing automated lifecycle tests dramatically easier.

What you need

You also need the following items on your device:

Your target agent’s CLI install and authenticated
Entire CLI installed
Go toolchain because external agents for Entire are written in Go.
Open an issue first to get alignment with the team at Entire requesting that you want to add this agent. Introducing a new agent means a long-term support commitment for us!
Optional: An agent that you would use to implement this integration. I used Claude Code with Fable 5. This way, I didn’t have to manually write all the code. Claude Code just followed the pattern to integrate Goose with Entire.

The step-by-step workflow

1. Run the Agent skill

The external-agents repo includes a built-in developer skill that automates the heavy lifting: entire-external-agent. Clone the repository, open it up in your favorite AI development tool, and run:

/entire-external-agent

2. The three development phases

Phase 1: Research - The skill analyzes the protocol spec, probes your agent's binary commands, and, crucially, writes a verification script to capture real hook payloads.

For Goose, this script wired a capture plugin into a temporary workspace, executed a real goose run prompt, and dumped the exact stdin payloads to disk. Documentation can lie, but captured payloads never do. This phase also ensures the session data is clean and stores everything in an AGENT.md summary file.

This phase revealed that Goose sessions live in a global SQLite database rather than isolated files, meaning our binary had to materialize transcripts on the fly using goose session export --format json.

Phase 2: Write tests - The skill scaffolds a fresh Go binary that stubs out the required protocol subcommands with valid JSON shapes. It registers your agent in our end-to-end testing harness. At this point, the shared compliance suite (entireio/external-agents-tests) is supposed to fail. Those specific failures become your exact development roadmap.

Phase 3 - Implement - Now that we (you and the agent implementing the integration) have specific test failures, your agent can use a test-driven development approach to identify the code needed for this to work. It can take those failures and write the code to fix them step by step. For Goose, the failing tests pulled the agent through hook installation, session read and write round trips, and transcript validation. Finally, the agent writes unit tests using the actual data it recorded back in Phase 1 to prove its translation code works perfectly.

When Entire first discovers your integration, it does a quick programmatic handshake to ask, "What features do you (the target external agent) actually support?" Your external agent binary (mine was Goose in this case) answers by declaring its capabitilies. This list tells Entire exactly what tasks it is allowed to hand off to your agent.

Here are the specific capabilities Goose declared:

hooks: Tells Entire that the binary can use Goose's native plugin system to listen for session events.
transcript_analyzer: Tells Entire that the binary can read the raw JSON data to find the user's prompts, the tool calls, and the files that were changed.
transcript_preparer: Tells Entire that the binary knows how to pull the conversation history directly out of the local SQLite database.
token_calculator: Tells Entire that the binary can track the total AI tokens used during the session.
compact_transcript: Tells Entire that the binary can clean up the raw conversation formatting so it looks readable when you run entire checkpoint explain.

The test harness (in my case Claude Code) automatically runs your new binary (Goose now integrated with Entire) through protocol compliance checks, live LLM prompt scenarios, and session persistence validation to ensure everything works perfectly.

4. Open your PR

Before putting up a pull request, remember to open an issue first to get alignment with the maintainers. Introducing a new agent means a long-term support commitment for the repository. Once aligned, push your branch and open the PR. Our CI pipeline will automatically compile your binary, run the compliance suite, and verify your unit tests.

Check for additional bugs

After the agent skill finished running, I tested the integration myself.

I ran the following command in a repo I didn’t care about:

entire enable --agent goose

Then, I prompted goose to make some file changes, commit, and push. I found one bug where it wasn’t generating the full session transcript, and it only generated the first user prompt. I had Claude Code survey past agent integrations to look for patterns and identify what was missing. I added those fixes to my PR, and then I was done!

It felt lightweight because Claude Code did all the heavy lifting.

Now, I have to wait and see if my teammates approve my PR.

Resources

There’s some more resources from us about agent hooks and adding external agents:

Hang out with us!

You can find the Entire crew here:

And we’ll be at We Are Developers Berlin this July 2026. See you soon!

The Ralph Loop Is Not Enough!

Lizzie Siegle — Thu, 11 Jun 2026 00:48:08 +0000

Check out the video here: Watch on LinkedIn

"I don't prompt Claude anymore. My job is to write loops."

— Boris Cherny, Claude Code creator

Though I see where he's coming from, I'd put it differently.

A developer's job isn't to write loops. It's to design state machines.

Every major agent framework — Claude Code, Codex, Cursor, LangGraph — does the same thing under the hood. A while loop calls an LLM, checks if it wants to use a tool, runs the tool, repeats until done. The loop isn't just a solved problem. It's a boring problem.

The hard part is everything around it.

A loop has no idea what state the work is in. It just keeps going until something breaks or you run out of tokens. That's the Ralph Loop — named after the Simpsons kid who put a crayon in his nose. Agent, infinite loop, go. The Ralph Loop works, is famous, and has zero memory of where it is in the job. Like Ralph, it keeps going without knowing why.

The Fix: A Finite State Machine

Think about the NBA Finals. The Spurs and the Knicks aren't improvising — every possession has a state. Fast break. Inbound play. Half court set. Each one has specific reads and triggers for what happens next. Point guard De'Aaron Fox isn't making it up as he goes. The system tells him what situation he's in, and the situation tells him what to do.

Your agent works the same way. You define the stages — planning, implementing, reviewing, error handling — and you define what triggers each transition. The agent doesn't orchestrate. It executes. One focused job per state.

Why This Matters in Production

When agents break, it's almost always one of three things:

Infinite loops — one system repeated the same answer 58 times before anyone noticed.
Context overflow — the history gets so long the model starts quietly forgetting things.
Goal drift — 70 turns in, "don't touch auth" has completely evaporated.

State machines fix all three. The loop runs until the list is empty, not until you run out of tokens. The goal lives in the transition logic, not in the context getting squeezed. And failures don't spiral — they transition to an error state with explicit rules for what's next.

Observability

State machines also give you observability. You can see the exact sequence of states the agent passed through before it broke.

That's what Entire is built for — full transcript history across your agent sessions, so you can see not just what your agents did, but what state they were in when they did it.

A system you can't inspect isn't a system. It's a loop with better vibes.

How to Make Coding Agents Remember Past Solutions

Rizèl Scarlett — Wed, 10 Jun 2026 21:40:59 +0000

Some engineering problems are only painful because they happen so rarely. Even with a coding agent, the frustration still feels the same. I’ll wrestle with a tool that isn't my daily driver, hit a wall of errors, finally find a resolution, and then I neglect to note the solution because the problem is "fixed."

This happened to me recently with a custom, internal GitHub Actions workflow I use for a post-release DevRel task. To make it work, I need to pass a specific authentication token to run Entire in a headless mode.

A couple of months ago, I sat down with my AI agent to configure this for the first time. Because Entire is new and our setup is completely undocumented, it took a grueling trial-and-error process to figure out how to generate the token via a local device-flow login.

Eventually, we found the answer. I pasted the token into my GitHub secrets, the workflow turned green, and I went about my day without writing anything down. I rarely take notes now that I use coding agents, but it’s not a sustainable practice. I need something to take note of the resolution (even if it’s my agent).

Today, when the token expired, I was back at square one.

Why I Didn’t Make a Skill

Normally, my instinct is to automate repetitive tasks by building a reusable workflow, like an Agent skill or a goose recipe. But a dedicated skill didn't make sense here:

Low Frequency: This happens once every few months. Writing and maintaining code for a skill I barely use is textbook over-engineering.
Security & Context: Generating an auth token involves sensitive device flows. I didn’t want a generic token-generation script floating around in my global automation suite.

I wished my agent had a memory, so I could ask “How did we get that GENERIC_ENTIRE_TOKEN last time?" and have it recall the context.

Instead, I spent an hour re-debugging a problem I had already solved. It was just my agent and me making guesses.

To break the loop before the next expiration, I decided to use Entire. (At the moment, I was literally working in Entire’s repos. I work for Entire, and I’m like okay this is the perfect use case).

What is Entire?

Entire is a tool for preserving the context behind software work.

When you work with coding agents, a lot of important information lives outside the final diff: the prompt you gave, the dead ends the agent tried, the commands it ran, the reason a change was made, and the little debugging discoveries that never make it into code comments.

Entire captures that session history and connects it to your git history. So instead of only seeing a generic commit message like:

docs: note dispatch auth refresh process

You can also recover the agent session that led to that commit and find the answer to questions like:

what problem you and the agent solved,
what files you and the agent touched inspected,
what scenarios you and the agent ruled out,
what was the final fix

Using my session history as an artifact

Unfortunately, my agent could remember the solution from two months ago because Entire connects agent sessions to commits.

When I fixed the problem the first time, I hadn't changed any code. I just asked my agent a question and it responded with an answer. This meant I didn’ commit. Because there was no commit, there was no permanent record or session transcript for my agent to review.

So today, after solving the problem a second time, I decided to leave a breadcrumb.

I created a small markdown file in the repo. I didn't want to document the exact terminal commands step-by-step, nor did I want to risk exposing a security vulnerability by pasting sensitive outputs or token patterns into a file. I needed to document the process, not leak the credential.

I checked in a minimalist note that looked like this:

# Workflow Token Refresh

If this workflow fails because its token is missing, blank, or rejected, refresh the the token using the flow captured in the session history for this commit.

Here’s how my agent responded

Now, I wanted to test if this theory would actually work in the future. I asked my agent the following question:

how do i get the GENERIC_ENTIRE_TOKEN?
in my github action workflow it says that token is expired

This triggered my agent to run a skill called using-entire. This skill is an orchestrator built for codebase exploration and tracking down "why did we do this?" questions. Its core instruction is simple: read the repository's recorded session history before guessing from raw code.

Here is the exact step-by-step trace of what the agent did autonomously behind the scenes to find the answer:

First, the agent ran a quick status check to see if Entire was active in the local project workspace.

entire status

The agent scanned the codebase for the search keywords from my prompt and successfully located the markdown file I checked in earlier.

docs/runbooks/dispatch-workflow-auth-refresh.md

Once it found the file, my agent checked the git commit history of that file to find the associated Entire Checkpoint.

git log --format='%H %b' -5 -- docs/runbooks/dispatch-workflow-auth-refresh.md | grep -B1 'Entire-Checkpoint:'

This command allows the agent to extract the unique session identifier tied directly to the commit:

Entire-Checkpoint: f3aaa4d4eafd

This checkpoint hash acts as a permanent anchor, linking the codebase straight back to the exact historical session transcript where we originally solved the problem.

With the checkpoint ID secured, the agent called Entire's explanation tools to pull the history.

entire explain --checkpoint f3aaa4d4eafd --transcript

Once the transcript streamed in, the agent scanned the text for relevant authentication phrases like oauth/device/code, and oauth/token.
Because the agent successfully dug up that historical context, it handed me the exact commands I should run to retrieve the token and add it to my GitHub Actions secrets.

By committing a file to the repo, I forced Entire to generate a permanent session history for that specific commit.

A new approach to institutional knowledge

The first time I used an agent memory tool in mid-2025, it was essentially a manual knowledge graph. It remembered what I explicitly told it to remember, and retrieved it on command.

But I don’t want to manually prompt an agent to remember a scenario. I often lack the hindsight to know what information I will need down the road. This is why Entire’s background recording is so valuable. By automatically saving session transcripts, it transforms raw developer activity into a retrievable artifact that your agent can tap into at any time.

Just a few years ago, every company valued that one engineer who knew everything, holding the context that code alone couldn't capture: the background of architectural decisions, stakeholder trade-offs, and historical workarounds.

We used to have to track that person down for answers. Now, we can query agents instead. But to do that effectively, we must equip them with the right context regarding troubleshooting steps and past failures.

Capturing our agent sessions and version controlling them ensures this rich decision history becomes a live, permanent part of the project repository.

The #1 Developer Skill in the Agentic Era

Rizèl Scarlett — Tue, 02 Jun 2026 23:12:42 +0000

At first, many dismissed AI as a temporary bubble, but now that engineering organizations are adopting agentic workflows at scale, it is much harder to negate this new reality. Naturally, this shift has triggered a wave of industry anxiety. Engineers are looking at the landscape and asking a frantic question: What skills do I need to keep my job?

For decades, developers prided themselves on memorizing syntax, writing algorithms from scratch, and passing LeetCode interviews by repeating patterns. The pivots we made in the past were typically centered around the framework of the week (especially in the JavaScript world). Switching frameworks only required relying on the strong foundational software engineering skills picked up at school, in a coding bootcamp, or even from a YouTube video. But now that AI agents can produce code in seconds, developer egos are crumbling.

In pursuit of relevance, developers have to sift through the noise of industry influencers pushing various strategies: Agent Skills, MCP, Gas Town, or building custom agents from scratch. Yet every one of these strategies boils down to a single foundation. That same foundation remains the number one skill for developers today, just as it was before the AI boom: communication.

The Value of Communication in Software Engineering

Code alone does not make a great developer. When coupled with strong communication skills, it becomes a distinct competitive advantage. However, we often overlook these skills because our industry excuses poor communication, hiding behind the stereotype that software engineering is an isolated job for people who just want to avoid human interaction.

Early in my career as a junior software engineer, I struggled. It was not due to technical aptitude; instead, I simply struggled to verbalize my thoughts well. For example, when I was stuck on a problem, I didn’t understand how to ask for help. I would write essay-length questions on Slack, burying my actual problem in a mountain of unnecessary context, or I wouldnt provide enough information at all. Either way, my teammates werent motivated to help me because they didn’t understand what I was trying to say.

I finally made progress in my career when I learned how to communicate with clarity. That realization eventually propelled me out of junior loops and into senior leadership roles in developer advocacy, where communication is the core focus.

This requirement is evident in the way our industry identifies talent. In technical interviews, the engineers who get hired are the ones who vocalize their reasoning, explain their trade-offs, and talk through their strategy as they adapt to new constraints. The candidates who pass are rarely the ones who silently type out a perfect linked list.

The Need for Communication in the Agentic Era

// Detect dark theme var iframe = document.getElementById('tweet-2060553984947950017-360'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2060553984947950017&theme=dark" }

Coding agents have increased the need for clear communication. To have a successful session with an agent, you must be able to clearly express your intent. I find that when engineers claim coding agents are hard to use, unreliable, or hallucinate too much, or when they rely too heavily on overly complex workflows to guide an agent through a codebase, their communication skills often need improvement.

Methods like context engineering, planning, and leveraging Skills are simply different user experiences designed to help engineers better communicate with their agents. For example, while you can create a plan with an agent before starting work, using a command like /plan ensures you provide the right details upfront and saves an artifact of that plan in a markdown file.

Orchestration Makes Communication Less Visible

As agent harnesses and models improve, and as executive leaders demand more output, engineers are getting creative to work faster. One common solution is orchestration. In practice, this means you act as a manager of multiple agents working simultaneously, even while you sleep, and you simply review the output at the end.

AI engineering leaders are starting to point out the trade-offs of this approach. @addyosmani wrote an article about it titled The Orchestration Tax.

// Detect dark theme var iframe = document.getElementById('tweet-2059844244907696186-696'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2059844244907696186&theme=dark" }

While your agents might produce a massive amount of work, you now have to review a mountain of output. My main issue with this setup is that the underlying reasoning behind the output often gets lost.

Treat Agent Sessions as Engineering Artifacts

// Detect dark theme var iframe = document.getElementById('tweet-2061159078479663601-611'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2061159078479663601&theme=dark" }

To solve this, we have to start treating agent sessions as durable engineering artifacts. Just like we use version control for our lines of code, we need an audit trail for our agent interactions. You should be able to go back and view the transcripts, the prompts, the tool calls, and the trade-offs an agent made, giving you the context you need to answer for your architectural decisions.

This is one of the many tools my team is building at Entire. We wanted to create that missing track record for agentic workflows. Now, if I open a commit from last week and see a vague message like fixed, I dont have to wonder what happened. I can run a simple command like:

entire checkpoint explain

Entire then surfaces what was asked, what files changed, what the agent reported back, and which commit it belonged to. It is incredibly useful because I can even ask my agent to look at those tracked sessions to help me better understand and expand on the context. This allows me to keep honing my communication skills and progressing as an engineer.

A Real Example

Ill be vulnerable. Yesterday, I published a blog post on our company website. While the tests for the blog post passed in staging, when I merged it to production, it failed to deploy because of a failing Cloudflare test. I worked with my coding agent to diagnose the problem, and then I learned I had to revert a PR from the Head of Design Engineering where he had bumped our Node version up. Someone approved my PR to revert his code, and I merged it. I did this without him knowing because we are in different time zones. However, I anticipated that the next morning, he would want to know why I reverted his code, and I needed to be able to explain myself.

The problem was that I do not have direct access to Cloudflare since I am not on the core engineering team. I didnt fully understand why he made his original PR, or exactly how my deployment broke it. So, I spent a lot of time asking my agent what happened, why it happened, and how I could fix it. I knew that by the next morning, I would probably forget some of the major details, especially since a lot of the troubleshooting happened at 10 p.m.

But I used Entire to help remind me. First, I ran a simple terminal command:

bashentire checkpoint list

This command surfaces a clean snapshot of my history, giving me a list of various checkpoints and commits from my session with the agent.

Normally, I would choose a specific checkpoint from that list and run entire checkpoint explain to get an explanation for each individual moment. But because there were so many checkpoints, I wanted to fast-track the process instead of digging through them one by one.

Fortunately, I have agent skills installed that teach my agent how to interact with Entire commands and execute custom workflows. I handed the agent that same screenshot of my checkpoint list and gave it a simple prompt: Can I get an explanation of each of these checkpoints?

My agent responded by explaining the decisions from beginning to end, covering my initial workaround attempts, how I got confused with the version numbers, and how we finally identified a fix, so the next day I would be able to respond to my coworker.

How to Keep Improving Your Communication Skills

Use agents daily: This one is simple. The more you use agents, the more you will understand how to use them and how to communicate with them. Over time, you will build your own personal workflows that ensure you get the best outcome. It can be a bit of a learning curve at first, but after constant use, you will get a hang of it.
Watch others work: Through reading blog posts, watching livestreams, or even reading my teammates past agent history, I learn a lot about how they operate agents, and I can adapt different parts to my own workflow.
Own the outcome: Never ship code you cannot explain to a human peer. If your agent makes a sweeping change across ten files, trace its steps, audit its intent, and ensure you completely understand the reasoning behind those lines before hitting approve.
Track your agent sessions: Let Entire track your sessions behind the scenes. When you find yourself in a moment where you need durable artifacts because someone is asking what happened and why, you will be fully prepared to communicate it.

It’s a strange world. The best engineers are no longer defined by how well they memorize syntax. At first, the developers who stand out will be the ones who work the fastest, spinning up multiple subagents and impressing everyone with their raw speed.

But very soon, the most valuable engineers will be the ones who can bring clarity back to the humans on their team. When a system inevitably breaks down, they will be the ones who can look back at their sessions, trace exactly what the agents did, and explain the choices to their team.

Code is cheap, but clarity is getting more expensive.

You can get that clarity today with Entire.

Resources:

Website: entire.io
Documentation: docs.entire.io
Discord community: https://discord.gg/jyAENMgmb3

Put your Coding Agents in Drive w/ Superpowers (aka How Superpowers is the Automatic Transmission of Agentic Coding)

Lizzie Siegle — Fri, 29 May 2026 00:37:53 +0000

Watch the video on LinkedIn here!

The most downloaded and widely used methodology in the Claude Code ecosystem is Superpowers, with over 208k stars⭐️ and 18.5k forks🍴 on GitHub (and counting!)

Going from raw Claude Code to using Superpowers is as revolutionary as going from a manual transmission to an automatic. Here's why this analogy holds:

Planning Mode vs. Coding Mode

When we build with Claude (or Codex, or Gemini...), we're usually in one of two states:

planning mode
coding mode

Like shifting gears in a car🚘, moving between these modes effectively is what makes it all work. Skip the shift, and you're just revving your engine (aka burning context and going nowhere.)

Superpowers lets Claude automatically detect and shift between these modes. It picks up on ambiguity in your prompt and ensures it fully understands the task before entering coding mode. No manual shifting required!

Slower, but for Good Reason

Superpowers can feel slower and less satisfying than raw Claude Code, like how driving an automatic can feel less engaging than a manual. But both serve the same critical purpose: they stop you from blowing up your engine!

That said, there's still a time and place for raw Claude. Sometimes you want direct, fast, unmediated output. But that minor gain in speed often isn't worth the added complexity, the ambiguity risk, and the tradeoffs that come with it.

The Layer Underneath

Entire is building the foundation beneath all of this — capturing every session and decision, and linking it to the commit it produced. It's the full record of how the code was written, not just the code itself.

So the question is this: how will you put your agent in drive🚘?

Banning Agent PRs Won't Save Open Source

Rizèl Scarlett — Sat, 23 May 2026 19:52:52 +0000

It's an unspoken rule that large pull requests are poor etiquette. Traditionally, Agile teams break features into manageable slices to make it easier for developers to tackle the logic and for peers to actually review. That is until the adoption of agents. Now developers are shipping end-to-end features in a fraction of the time, but the result is often an unmanageable wall of code that is discouraging to even open. These "Agent-PRs" almost guarantee a reviewer's eyes will glaze over, leading to a quick "LGTM" that misses subtle logical flaws. This tension has become so high that some open source maintainers have moved to outright banning agent-authored contributions.

Before the invention of pull requests, contributors would email maintainers their code changes or ask maintainers to pull updates from the contributor's repository. In 2008, GitHub introduced pull requests, giving teams a structured way to propose, discuss, and review changes before merging them. For almost two decades, the pull request provided the perfect workflow. But now the very structure that enabled collaboration is cracking under the weight of AI-generated velocity.

Prominent open source developers, such as Rémi Verschelde and Jeff Geerling, have taken to social media to express their concerns.

But their sentiment isn’t isolated. Many developers feel this way, and faced with deluge, many have decided to take drastic measures to protect their codebase and sanity by banning AI-assisted contributions completely.

// Detect dark theme var iframe = document.getElementById('tweet-2044406553508274554-404'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2044406553508274554&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-2011911073834672138-337'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2011911073834672138&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-2014433315261124760-42'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2014433315261124760&theme=dark" }

However, as more developers are encouraged to use AI throughout the software development life cycle, running away from AI-assisted pull requests only hurts open source by closing the door to potentially valuable contributors. Angie Jones, my former manager, argues that closing the door isn't the solution. Instead, she advocates for better guidelines for both agents and humans.

She's right. Closing the door isn't the answer, and clearer guidelines are a step forward.

But even with better guidelines, the review process remains fundamentally unchanged. Maintainers are still staring down massive PRs, trying to make sense of what an agent produced.

To remedy this problem, GitHub recently released a feature giving maintainers the power to set contribution limits, starting with a PR cap for outside contributors and an allowlist for trusted ones.

// Detect dark theme var iframe = document.getElementById('tweet-2057864556488306833-376'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2057864556488306833&theme=dark" }

Many maintainers are excited about this release, but a PR cap is a short-term band-aid. I think it’s a good move, but our industry needs a complete overhaul of how we handle code reviews.

As a maintainer of goose, an open source AI agent, I have spent 2025 and 2026 sifting through pull requests. I do not want to limit who can contribute. I want everyone to be able to contribute. The goal is to understand the context of a PR at a fast pace, even if an external contributor uses an agent to build it. Open source needs infrastructure built to support both human-authored and agent-authored work.

I joined Entire because our convictions aligned: we need to fix the structural breakdown in open source. Right now, we have built a CLI that provides a system of record that captures the context behind agent-assisted code changes. The record gets stored as a This serves as the baseline for a new era of developer tooling that can help our industry move towards:

Shifting from code review to intent review: This means instead of parsing 500 lines of syntax, reviewers will start with intent by examining the prompt, the session transcript, and the reasoning behind key decisions. This allows reviewers to focus on the problem being solved and whether the right calls were made along the way.
The ability to search for the why: Developers and maintainers can ask why a change was made a certain way and receive an answer derived directly from the agent session context.
Infrastructure for the AI-native velocity: The open source community needs a foundation that can support the massive volume of human and agent contributions without falling under the weight of the traffic or causing platform outages.

To explore the full scope of what we are building, you can read about our vision and learn more about where we are headed.

Open source is where innovation happens. It is how large companies thrive, relying on thousands of open source dependencies. Yet if we shut down external contributions out of fear or fatigue, the community disappears, leaving the ecosystem at risk of stagnation. Developers are genuinely excited to contribute because agents have given them the confidence to do so. We need to embrace that momentum by building an infrastructure designed for the AI-native software development lifecycle.

Your Agent Sessions Belong in Your Codebase: Nullius in Verba

Rizèl Scarlett — Tue, 19 May 2026 08:56:46 +0000

Your coding agent sessions belong in your codebase. Before I joined Entire, the company building the infrastructure to bring your agent sessions into your code, I was already exploring this exact idea on my own.

In January 2026, I participated in Genuary, a month-long creative coding challenge where artists, designers, and programmers make and share generative art based on a daily prompt. I used my coding agent, goose, to generate the creative code. For me, this was less of an exercise in creative coding and more of a self-taught lesson in orchestrating agents, since doing complex things with agents was on the rise.

One of the things I built into my process was a repeating workflow where, after every session, my agent automatically committed the session transcript into the same repository that held the creative output. It wasn't elegant, because it was literally a huge transcript with every tool call mixed in and almost no structure to make it readable. I did it because some of the creations were so astonishingly beautiful that I wanted my agent and myself to be able to look back later and have enough context to reuse those same patterns for future challenges.

Three months later, in March, I was working at a company that had built a far more elegant solution to the same problem. Instead of haphazardly dumping whole session transcripts, Entire saves each session as a series of navigable checkpoints. Each checkpoint is a snapshot of a meaningful moment in the session, capturing what the agent did, what changed in your code, and the reasoning that produced the change. Now after using Entire for a few months, I’m realizing that what I had treated as a nice-to-have for myself, I now see as a real necessity for engineers.

I had this epiphany while doing what my job actually entails, which is advocating for developers. I started noticing a pattern across the developers and community members I talked to. While many of them wanted to track their agent sessions, they did not want those sessions to live in the same codebase. Some people felt their sessions were too embarrassing, full of mistakes or moments where they had been harsh with their agent, because all of us have lost patience with a coding agent that just refuses to understand us. Others felt the sessions were too private. Because Entire already supports storing sessions in a separate repository and redacting secrets by default, I assumed we should be louder about that functionality.

Surprisingly, one of my teammates disagreed with me. His philosophy was that agent sessions belong alongside your code by default, and that the discomfort developers would eventually go away. Because I am trained to empathize with developers, I initially felt this stance was dogmatic, and I struggled to see eye to eye. Over the past few weeks, though, the idea kept ringing through my mind, I see his perspective.

Software engineering has never been about flawless first drafts. Our industry thrives precisely because we maintain a transparent, versioned track record of our technical evolution, and when engineers treat interactions with coding agents as ephemeral scratchpads, we end up ignoring a foundational principle of how software actually gets built. Every architectural and logical decision deserves a clear and traceable provenance, and right now that provenance is silently disappearing into chat windows.

I did some historical research on how deeply embedded proof of work is in our industry, and I learned a lot about what happens when we abandon that proof of work. Here’s what I learned.

Proof of Work in Mathematics

This foundation goes as far back as mathematics, the predecessor of computer science and software engineering. In the 1600s, mathematicians operated inside a genuinely toxic environment, settling disputes through public academic duels with brutal stakes. Winners kept their university chairs, while losers were publicly humiliated and often lost their livelihoods entirely.

Because the consequences of losing were so severe, practitioners routinely hid their formulas and hoarded their methodologies. That culture of intense secrecy produced constant intellectual property disputes, redundant reverse-engineering, and a fragmented ecosystem that ended up stalling the progress of the entire discipline.

The turning point came in the 1660s, when the Royal Society of London adopted a new motto, Nullius in verba, which translates to "take nobody's word for it." From that point on, mathematicians had to publish their complete, step-by-step processes in academic journals rather than only presenting final conclusions. In exchange for that transparency, they received institutional validation and undisputed peer credit, and the field finally had a shared ledger of truth.

Proof of Work in Software

Three hundred years later, software engineering experienced a similar reckoning. In the 1960s, code was a tangible, physical artifact. Developers punched holes into cardboard cards, organized them into precise decks, and fed those decks into a mainframe. Version control was physical too, because changing a routine meant pulling a specific card out of the deck and slotting a new one into its place.

Then, code moved to magnetic tape and hard disks and became digitally invisible. Multiple developers modified the same file and accidentally overwrote each other's changes without any shared source of truth. The industry's response was a slow march back toward visibility, moving from local file-locking systems like SCCS and RCS to centralized trackers like CVS and Subversion, and eventually to Git. Git decoupled development pipelines entirely through a distributed, non-linear architecture, but it was hard to use on its own, and it did not pick up real traction until GitHub layered a collaborative interface on top of it. That interface turned version history into a shared social ledger and defined the modern development workflow.

The pattern is the same one the Royal Society set in motion three centuries earlier. Every time our industry has taken a leap forward, that leap has come from making invisible work visible.

Invisible Agent Work

Agentic workflows are becoming the primary engine of software production, but they're abstracting away our work at the same time.

By committing only the final file output of an agent session, we aren't hiding our work the way 17th-century mathematicians did. But the effect is the same: we are back to delivering an end product while erasing the lineage of how it was reasoned into existence.

The prompts you write, the specific files your agent reads, and the back-and-forth debugging it takes to get things right are not just logs. They are first-class development artifacts. When we strip them away from a pull request, the rest of our tooling, our reviewers, and our future selves are all left to take the resulting code at face value.

That is exactly the position the Royal Society found unworkable in the seventeenth century, and there is no good reason to expect it will work for us either.

Nullius in Verba

Including your unedited session next to your code feels vulnerable, but so does pushing your first commit to a public repo or opening your first pull request in an open source project.

That discomfort is not a flaw in the workflow, it is the price of admission for a trustworthy, auditable record of how software actually gets built. Nullius in verba is still the right principle 300+ years later: take nobody's word for it, not even your agent's. Let the work speak in the place where the work actually lives. That is the direction we are building toward at Entire: making the context behind agent-authored work as visible as the code itself.

Did you like this blog post?

Try out Entire: entire.io
Join our Discord: https://discord.gg/WUzRcQ5PX4
Read our docs: docs.entire.io

If you have additional thoughts, feel free to leave a comment!

How to Keep Entire Checkpoints Separate from Your Code

Rizèl Scarlett — Fri, 08 May 2026 08:02:39 +0000

Storing a record of your agent sessions solves the biggest friction point for developers: limited context. On the surface, this may look like a dormant log, but Entire transforms those records into procedural memory. By default, the Entire CLI stores your agent history right alongside your code. More specifically, it stores your checkpoints, snapshots of your prompts, agent transcripts, and the state of your work at each step, on a dedicated branch in the same repository called entire/checkpoints/v1.

But as valuable as that memory is, it raises a valid question: What if I don’t want anyone else to see the conversations I have with my agent?

We’ve heard a few consistent reasons why developers want to keep their agent history private:

The conversations are, frankly, a little embarrassing. (I’ve yelled at my agents before. I am not proud of it, but when tokens are few, so is my patience).
It can start to feel like surveillance from their employer.
It's a privacy concern. Those conversations might include context their company doesn't want to share publicly or with external collaborators.
They want to keep your main repo lean and focused on source code.

If any of those reasons resonate, you have two main paths to a more private workflow.

Push checkpoints to a separate private repo

This is the sweet spot if you’re working on a public or shared project but still want a history that you (and maybe your trusted teammates) can access.

1. Create a private repo for your checkpoints

On GitHub, create an empty private repo with any name you want. In this example, we’ll use myorg/checkpoints-private. This is where all your agent sessions will live. You don't need to add a README or initialize it. Entire will push the first checkpoint branch on its own.

2. Point Entire at the new repo.

From inside your project, run:

entire configure --checkpoint-remote github:myorg/checkpoints-private

The format is provider:owner/repo. Today, github is the supported provider. This writes the setting to .entire/settings.json under strategy_options.checkpoint_remote:

{
  "strategy_options": {
    "checkpoint_remote": {
      "provider": "github",
      "repo": "myorg/checkpoints-private"
    }
  }
}

Now, your code will be stored in your main repo, and your agent sessions will go to your new private repo. You can read more about this in the Checkpoint Remote docs.

Keep your agent sessions local

If you want the highest level of privacy, you can keep your agent sessions local and opt out of pushing them to remote using the following command:

entire configure --skip-push-sessions

This modifies .entire/settings.json with the following values:

{
  "strategy_options": {
    "push_sessions": false
  }
}

This setting still allows you to store your sessions locally. For example, you can still rewind, look back at what happened, and use all the local features. However, because the checkpoints never get pushed to GitHub or any remote provider, you cannot retrieve them if you switch devices. Also, your teammates won’t have access to your checkpoints.

What if I accidentally paste a secret?

We know that mistakes happen, so we have guardrails in place. Whether you store your history alongside your code, in a private repo, or on your local machine, Entire runs every session through a redaction pipeline before it hits git.

We use Betterleaks to automatically scrub:

Cloud credentials (AWS, GCP, Azure)
Source control tokens (GitHub, GitLab, Bitbucket)
Service keys (Stripe, Slack, Discord, Twilio)
Private keys (RSA, SSH, PGP)
Database connection strings with embedded passwords
Bearer tokens, JWTs, and high-entropy strings that look secret-shaped even if they don't match a known pattern

TLDR; Which one should you pick?

The Goal	The Command	Where data lives
Full Visibility	Default	Same repo as your code
Private Collaboration	`--checkpoint-remote`	A separate private repo
Total Isolation	`--skip-push-sessions`	Your local machine only

Note: Redaction runs across all three. Whether your checkpoints live in your code repo, a private repo, or only on your laptop, secrets get scrubbed before they're written.

Conclusion

We recognize that your agent workflow is going to look different based on who you are, the codebase you're in, and your team's unique security needs. Entire is built to adapt to those needs.

Ready to dive deeper into configuring your setup? Check out our documentation on checkpoint remote and Security & Privacy docs.

In the comments section, let me know: Do you even care if people see your agent history, or would you rather keep those transcripts private?

Turning Agent History into Procedural Memory

Rizèl Scarlett — Sun, 03 May 2026 23:40:08 +0000

For about a year, my primary coding agent was goose. Since I worked at Block and served as a Developer Advocate for the project, I was deeply embedded in its ecosystem. I contributed code and provided product feedback that shaped how it functioned.

Then, I moved to a company called Entire that provides the infrastructure for the agentic software development lifecycle. To do my job well, I have to dogfood our product across the agentic ecosystem. This means I am constantly switching between Claude Code, Codex, and other agents that support hooks to contribute to docs, investigate and resolve bugs, understand new features, and produce content.

Switching between AI agents made me realize every agent has tradeoffs. Some are faster or more polished, but I find myself deeply missing a specific goose feature called recipes.

The Problem with Operational Glue

Recipes are reusable, shareable workflows. At the core, they are YAML files that describe a process you want goose to run again. You can write the YAML files manually, but I always preferred the magic of clicking a button to package a successful session into a recipe.

My work in Developer Relations is creative, but it’s built on repeatable systems. For example, writing a blog post, building a code demo, creating a video are creative. The publishing process is not. Publishing a blog post involves a series of tiny, forgettable steps: checking the folder structure, adding the correct front matter, wiring up the metadata, dropping the image in the right asset folder, opening the PR. Each of these steps take a few minutes, but those minutes add up and become hours of operational glue. At Block, I automated as much of that as possible. I had goose generating release notes in CI/CD and creating documentation tickets in Asana. Some of these ran on a schedule, others I triggered manually. The point was always the same: if I found myself explaining a process to an agent more than once, it was an operational smell that needed to become a reusable asset.

While my use cases focus on content and community, this pattern is universal. In many fields, employees find themselves frequently explaining the same sequence to an agent, so why not automate this into repeatable workflows?

For engineers, those repeated conversations may look like:

Upgrading a dependency safely
Bootstrapping a new microservice
Triaging a production error
Writing a design doc or RFC
Preparing a release PR

The inputs and thinking may vary, but the process: conventions, the file paths, the validation steps, the commands you run, the people you always notify stay the same. And this level of automation is necessary today where employers are demanding more output.

The System of Record

I'm constantly jumping between different agents. Each one has its own process for automating workflows, but none of the automation tools hit the mark for me like goose did. While I don’t have access to my treasured repeatable workflows anymore, I do have access to the unique and valuable agent session data that Entire collects. Entire is a CLI-first system of record for agent-assisted development. It captures the context behind your work: the sessions, prompts, responses, tool calls, file changes, and Checkpoints. A Checkpoint is a specific moment where work is tied back to git. It connects the "why" of the agent session to the "what" of the final commit.

I realized this data isn't just for review, audit, or to sit quietly in the background. It's a source of truth that can be used for building better workflows. I thought, “What if I could use my Entire session history to recreate that ‘package up a session’ magic, but in a way that works across any agent, and works retrospectively?”

The most popular way people are currently building reusable workflows is with Skills, so I built an orchestrator skill called Session-to-Skill. It creates Skills for me based on repeated behavior.

The Before and After

Before I used to say:

“Look at past blog posts in this repo, check the folder structure, and the front matter.”
“I want to add a new blog post. Here’s the content: [insert content copied from google doc here] ”
“Create a new PR. Make sure we’ve pulled the latest from main and branch off main before you create this PR.”
“Why did you make the word Checkpoints lowercase when I purposely had them capitalized? Please restore that.”
“Does the OG image work? What’s the path for me to check that again?”

Now, I can say:

“Create a blog post from this content [insert content copied from google doc here].”

This is possible because I prompted my agent to use the Session-to-Skill Skill: "Look at my past sessions where I set up blog posts. Find the repeated steps and conventions, then draft a Skill from that data, so I can create blog posts quickly in the future." My agent created a Skill called Create-blog, which included requirements to properly format the blog, open a PR, and return the path to confirm the OG image rendered.

Well, that’s kind of dumb..

Some may have pushback on this idea of me building an orchestrator Skill because at any moment in a session you can prompt any agent to turn it into a Skill.

The reality is I don’t have perfect foresight. Most reusable workflows are recognized later. After the third time I publish a blog post, I realize I have been doing the same thing over and over again. By then, the valuable evidence is spread across past sessions.

There is also the issue of quality. Asking an agent to summarize a transcript often leads to overfitting and noise. The resulting Skill might include accidental details, temporary file paths, or one-off preferences that happened to be present in that single session.

Instead my Skill is extracting the answers to the following questions:

What was the reusable behavior?
What should a future agent know before attempting this again?

I don't have to remember the session ID from six weeks ago. I just know the work happened. The Skill uses Entire to search my session metadata, checkpoints, and explanations of prior work to find the durable pattern.

Procedural Memory as Infrastructure

My approach creates procedural memory for agents. Procedural memory is the answer to the question, "How do I do this kind of work well, here, in this repo, with this team?"

Daily engineering work is not net-new. You may receive a new ticket, but somebody has solved this problem before.

By using Entire's data to generate Skills, I get a layer of determinism and portability. The agent starts with a template based on real work rather than a generic prompt. It encodes patterns that have already succeeded. And because Skills are portable files, I can take my blog-publishing Skill from Claude Code to Codex without re-explaining my workflow and share it with teammates.

With all this said, I want to urge readers to stop treating our agent sessions as disposable and start turning our history into our infrastructure.

Check out Entire at entire.io

I Don’t Make Slides Anymore. My Agent and Entire Do It for Me.

Rizèl Scarlett — Sat, 25 Apr 2026 17:00:18 +0000

Signing up to speak at conferences is fun until the conference date starts approaching and you realize you still have to write and practice your talk. For me, writing the talk isn't the hard part. I have a process of talking to myself on a peaceful walk (or even in the shower), recording my voice, and then inserting the demos afterward. The part I often procrastinate is making the slides. Creating slides used to be fun, but as I’ve grown my career and my family, it's no longer a good use of my time.

I've looked for a way to automate slide generation, but most options have been fragile. They generally struggle with formatting and taste. However, a few months ago, some of my teammates at Block discovered the frontend slides skill and introduced me to it. This skill enables agents to build out HTML presentation decks that can be exported as PDFs or PowerPoint presentations.

Agent Skills

If you're not familiar, agent skills are markdown files that provide instructions for the agent to understand how to use a tool (i.e., a CLI or an MCP server). This way, your agent immediately knows what commands to run and how to navigate the tooling when you make a request.

How I Use the Frontend Slides Skill

As I mentioned, I already have my talk transcribed, which gives me a talk track to follow. I typically give the transcript to an agent and ask if there are any parts that don't make sense or any gaps for the audience.

Once the talk track is polished, I give the copy to my agent and prompt it to use the frontend slides skill to build a deck based on the track. I prefer to use Claude Code for this task, as it seems to work really well with the frontend slides skill, but any agent that supports skills should work. The agent then produces a beautiful slide deck for me. It really doesn't look bad or overly generic at all. It has various themes to choose from, and since it's generated with HTML, CSS, and JavaScript, I can prompt my agent to edit parts like making the font bigger, changing colors, and so on.

Here's an example:

// Detect dark theme var iframe = document.getElementById('tweet-2024060044153692197-26'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2024060044153692197&theme=dark" }

My favorite thing to add is a presenter view. It doesn't generate that view by default, but I do like to take a peek at my notes as I speak. So I usually tell my agent to implement that view if I press a key like the letter "P," and I make sure it syncs with what everyone else can see. Then, I upload my deck to GitHub Pages. Goodbye, Canva, PowerPoint, and Google Slides.

How Entire Enhanced My Workflow

Let me rewind for a second and introduce you to Entire. Entire is the company I work for. We're building the next developer platform for the AI-native software development lifecycle. The team recognized that agents have changed our workflows, so the infrastructure we use should change too.

Our first tool is a CLI that captures prompts, agent responses, tool calls, and other session data from the work you do with an agent. That gives you a way to inspect what happened, rewind work from a past session, and stay accountable. For example, if a production outage ever happens, instead of saying, "Oh, the root cause is that my agent did it," you can actually track the decisions made between the agent and the person prompting it. I described this to someone at a conference the other day, and they boiled it down to version control for agentic work, which is honestly exactly what it feels like.

Now, it took me a while to see how Entire could make my workflow even better, but the founders opened my eyes. I can use Entire while I'm building out a demo and then use that captured work to help build the slide deck later. Entire has a command called entire dispatch. It generates a markdown summary of the work Entire captured between you and your agent in a repository.

For example, after experimenting with OCR in a repo, Entire generated this dispatch summary for me:

# Dispatch: blackgirlbytes/pretext-handwriting-demo

Shipped a full handwriting recognition demo built on Pretext, moving from  
initial scaffolding to a polished scrapbook composition surface within a  
single day.

## blackgirlbytes/pretext-handwriting-demo

### Handwriting Recognition

• Built draw-mode handwriting recognition as the core interaction surface.  
• Added image upload as a second recognition path alongside the drawing  
canvas.  
• Implemented auto-recognition after drawing completes, removing the manual  
trigger step.  
• Added camera mode to round out the three input methods.  
• Removed the explicit draw button to streamline the input UX.

### Scrapbook Composition Surface

• Introduced a scrapbook composition surface for arranging recognized text  
and shapes.  
• Integrated Pretext to handle obstacle-aware text flow around placed shapes.  
• Added animated motion layer to the scrapbook background.  
• Added resize handles to scrapbook shapes for direct manipulation.  
• Matched scrapbook background typography to the handwriter component for  
visual consistency.  
• Moved scrapbook controls into the composition header to consolidate the  
toolbar.  
• Fixed scrapbook layout and output tab rendering, then simplified and  
tightened tab spacing across multiple passes.  
• Corrected background line wrapping and ensured background renders before  
shapes are placed.

### API Key & Session Management

• Added session-based OpenAI key setup to avoid requiring environment-level  
configuration.  
• Hardened API key gate interactions to handle edge cases more reliably.  
• Added environment key setup path as an alternative to session entry.

### Documentation

• Added project agent working rules and intent guidance early in the commit  
sequence.  
• Documented project setup and architecture in the README.  
• Refined and clarified the README project description across two follow-up  
commits.

All core features landed on main on April 1, 2026; the repo is in a  
reviewable state.

That's helpful for me because building a demo usually takes a few days. I'll leave it, come back to it later, and then have to remember what I actually did, what mattered most, and which technical details are worth calling out. Instead of trying to reconstruct all of that from memory, I can use the dispatch summary, give it back to the agent, and ask it to make a strong slide that captures the main technical highlights of the demo. That saves me from having to recall every step I took days or even weeks later.

Beyond DevRel

My particular use case works best for folks in Developer Relations or folks who do DevRel-related work like conference speaking, but this can actually work well for various roles. Here are a few:

Developers demoing completed features to their team. My husband is a developer, and he's expressed that building the slide deck is time-consuming just to show off a feature he built to his team.
Hackathon participants demoing their project to judges. Presentation decks often get neglected because everyone is focused on building the actual project during a small window of time.
Solutions engineers or sales engineers preparing customer demos. A lot of time goes into building out the demo environment itself, so having help turning that work into a clear deck can save a lot of time.
Workshop instructors or developer educators teaching technical material. It can be useful to turn the work captured while building the demo or sample app into slides that explain the flow, architecture, or key takeaways.
Engineering managers or tech leads giving project updates. Sometimes the hard part is not the work itself, but summarizing what happened clearly enough for leadership or cross-functional teams.
Founders or indie hackers pitching what they built. When you are moving quickly, the last thing you want is to spend hours making slides after already doing the hard part of building the product.

I don’t believe in automating things that deserve a human touch, but I do believe in automating things so I can spend more time with humans. The slides skill has been great for me, but adding Entire to this workflow has made it even easier for me to do that.

Much of my previous work with GitHub and Block (goose) was focused on using agents to build faster. Recently joining the team at Entire has pushed me to think more about the next layer: making agentic work durable and accountable.

Building fast with agents is fun, but in practice, I also need to be able to understand what happened, pick work back up later, explain it to other people, and turn it into something useful beyond the moment it was created. I’ll be sharing more of my agent-native workflows as I continue experimenting.

If you want to learn more about Entire, check out our:

And follow me!