AI Plan Mode Is Good. Saved Plans Make It Better.

June 20, 2026 agents planrock tools

Plan mode forces the agent to slow down before coding.

Instead of immediately editing files, the agent has to understand the task, inspect the codebase, break the work into steps, surface risks, and ask for feedback.

That is useful. But plan mode has one limitation: the plan usually lives inside the session.

That is fine for short tasks. But once the work gets longer, the session gets messy. I may switch machines. Another agent may need to continue the work. The original agent session is not always available, and even when it is, the transcript is not always the clearest project artifact.

At that point, a plan inside a chat transcript is not enough. I want the plan to become part of the project.

Saved plans make plan mode better

The next step is simple: save the plan into the repo.

That is why I made Planrock.

Planrock is a small agent skill and CLI that stores plans as Markdown files in a local plans/ folder.

A plan is just a Markdown file with frontmatter and a checklist:

---
title: Improve release workflow
state: open
priority: P1
created_at: 2026-06-20
agent_sessions:
  - codex:session-id
---

## Goal

Improve the release workflow so the agent can run tests, open a PR,
fix review comments, deploy after approval, verify production, and close the plan.

## Tasks

- [ ] Audit current release flow
- [ ] Update scripts
- [ ] Run lint and tests
- [ ] Open PR
- [ ] Address review comments
- [ ] Deploy after approval
- [ ] Verify shipped result

This is intentionally boring.

The point is not to create a complex project management system. The point is to make the plan durable.

A saved plan is readable by humans, readable by agents, tracked by Git, available across sessions, and easy to list from the CLI. It becomes a small local memory layer for agent work.

In practice, it feels like a tiny repo-local GitHub Issues system, but optimized for coding agents.

The agent can query open plans. I can review them. Another session can continue from them. When the work is done, the plan can be marked closed and committed with the implementation.

That is already a big improvement over a plan that only exists in a chat.

Why not just use a spec framework?

There are more formal solutions for this problem.

For example, OpenSpec is a spec-driven development workflow. It is designed to lock down intent before implementation and organize work through structured requirements, design notes, and task files.

That is useful when you want a real spec workflow. But I do not always want to start from a formal spec.

Most of my agent sessions start much more casually:

Maybe the bug is here.
Can you inspect this module?
What if we split the deployment step?
Actually, make a plan from what we discussed.

That workflow does not need a full spec system yet. It just needs a saved plan.

The difference is roughly this:

OpenSpec:
Use a spec workflow to define and govern implementation.

Planrock:
Save whatever useful plan came out of the agent conversation.

OpenSpec is probably better when the work is product-level, team-level, or behavior-driven.

Planrock is better when I want a lightweight memory layer for personal or small-project agent work.

It does not try to enforce a full process. It just makes the agent's plan survive outside the chat.

A quick Planrock demo

Install the Planrock skill:

npx skills add favoyang/planrock -g

Or simply ask your agent to install it for you:

Install the favoyang/planrock skill

After that, you can start with prompts like:

Create a saved plan to implement <feature prompt>.

Make a plan to <feature prompt>, and track it locally.

Summarize what we just discussed in a saved plan.

Even if you are already in plan mode, you can simply say:

Track this in a saved plan.

The skill will save the plan into the plans/ folder with unified frontmatter.

During implementation, the agent can update the checklist, record progress, and mark the plan closed when the work is done.

Use the Planrock CLI

To see the progress of local open and closed plans, you can ask the agent to list them. You can also try the CLI manually.

npm install -g @favoyang/planrock
planrock

Or use npx:

npx @favoyang/planrock

A repo using Planrock may look like this:

my-project/
  AGENTS.md
  plans/
    improve-release-workflow.md
    fix-auth-callback.md

To check the current plan status:

planrock

Example output:

Working dir: /Users/alex/projects/my-project

Planrock Status
Open:   1
Closed: 1

Top Open Plans (top 10)
Priority  Title                      Created     Done/Total  Percent  Agent Sessions
--------  -------------------------  ----------  ----------  -------  --------------
P1        Improve release workflow   2026-06-20  3/7         43%      codex:7f3a9c21

Most Recent Closed Plans (top 10)
Closed      Created     Title
----------  ----------  -------------------------
2026-06-19  2026-06-19  Fix auth callback

To list open plans:

planrock open

To list completed plans:

planrock closed

The CLI is not the most important part. The Markdown files are.

That is why the system works well with agents. There is no hidden database, no remote service, and no heavy workflow to learn. The agent can read and update normal files in the repo.

Conclusion

Plan mode gives structure. Planrock makes that structure durable by turning it into repo-local memory that stays with the project long after the chat ends.