Mine keeps growing every time I solve a new problem.
At this point I’m not sure which instructions are still useful and which ones are just adding noise.
Do you split yours into separate files or skills?
I'm going on a trip this weekend and want to leave my coding agent running while I'm away.
Is there a tool that lets me control Codex from my phone ?? (instructions, approve, commit, etc)
Has anyone here figured out a good way to do this?
I used to give Claude Code a feature request and let it do everything in one pass.
Read the repo, decide on the approach, edit twelve files, install a package, add a migration, and then tell me what it changed.
The result was usually not completely wrong. That was the problem.
It was close enough to take a while to review, but far enough from the original request that I would end up undoing half of it.
So I split the workflow into two separate phases:
Phase 1: plan only.
Phase 2: implement the approved plan.
The first prompt is now:
Plain Text
Do not edit the code yet.
Explore the repository and write PLAN.md with:
the goal
the files you expect to change
the proposed implementation steps
what will not change
new dependencies, if any
database or API changes, if any
tests that should be added or updated
anything you are uncertain about
Do not create files or modify existing files besides PLAN.md. Stop when the plan is complete.
The useful part is not the PLAN.md file itself. It is the point where I can catch a wrong assumption before it turns into a large diff.
For example, Claude might assume that a feature belongs in a new service when the repository already has a pattern for it. Or it might plan to add a dependency for something the project already supports. Or it might interpret “add notifications” as email, when the existing product only has in-app notifications.
Those are cheap mistakes in a plan. They are annoying mistakes after six files have been changed.
Once the plan looks right, I use a second prompt:
Implement PLAN.md one step at a time.
After each step:
Show the files changed.
Run the smallest relevant test or check.
Show the result.
Stop if the scope changes or a new dependency is needed.
Do not continue past an uncertain decision without asking.
I also keep this in CLAUDE.md:
For multi-file work, separate planning from implementation. Do not install dependencies, change schemas, or modify external integrations without calling them out first. If the requested change expands in scope, stop and ask before continuing.
The workflow is simple enough that I do not use it for every typo or one-line fix. It is most useful when the request touches multiple components, data flow, authentication, billing, external APIs, or anything I would not want to review as one giant surprise.
The part I like most is the “what will not change” section. Without it, the agent tends to treat unrelated cleanup as part of the feature. Sometimes the cleanup is good. It is still a separate decision.
A plan does not make Claude correct. It just moves some mistakes to the cheapest part of the process: before the code changes.
How are you handling larger Claude Code tasks? Do you plan first, or do you prefer to let it explore and implement in the same pass?
Don't add everything to CLAUDE.md. It can get messy & even difficult to manage. Do maintain separate files for different kinds of context.
Here's my split:
WORKSPACE.md current task, open files, next checkpoint
LESSONS.md patterns that have actually repeated
DECISIONS.md choices worth keeping the reasoning for
PREFERENCES.md style/workflow habits, not engineering rules
WORKSPACE.md is disposable archive it when the task's done instead of letting it become permanent law.
LESSONS.md only gets an entry when something's likely to recur:
## Lesson: validate before writing
When an endpoint accepts user input, validate the request body
before any database operation.
Why: partial records got created when validation failed
halfway through the handler.
Evidence: tests/auth/test_invalid_payload.py
DECISIONS.md is for stuff that'd otherwise get re-litigated:
## Use a queue for email delivery
Decision: send transactional email via queue, not inline in
the request handler.
Reason: provider occasionally takes several seconds → request
timeouts.
Tradeoff: UI shows "queued" not "sent."
Status: active
agent now reads an index first instead of loading every file every time:
# Context index
Always read:
- WORKSPACE.md
- PERMISSIONS.md
Read when relevant:
- LESSONS.md → bug fixes, recurring failures
- DECISIONS.md → architecture changes
- PREFERENCES.md → style/output formatting
previouly, every task inherited every historical exception; the agent would see an old workaround and treat it as a current requirement.
split your agent's memory file by type instead of dumping everything into one place.