Memory

Planning work that outlives the session

Draft an approach, argue with it, save it — and pick it up tomorrow or hand it to an agent.

Code
/plan add rate limiting to the API

What happens

It drafts an approach, stress-tests it against itself, and checks it against what your project has already decided. You get something to read — steps, scope, what could go wrong — before a single file changes.

Press y and the plan is saved with one task per step. Those survive the session.

Working the plan

Code
/plans        active plans
/tasks        open tasks on the active plan
/a            send the next piece to a background coder

Or just say "implement the plan" and it works through the steps in the conversation.

Why saving matters

An unsaved plan is a message in a scrollback buffer. A saved plan is available tomorrow, on another machine, to a teammate, and to an agent you delegate it to. csc --continue picks up the local conversation; any new session in the same project can retrieve the saved plan.

Editing a plan

Say what's wrong before you approve it — "step three should come first", "we're not touching the client for this" — and it redrafts. After approval you can still add, reorder, and close tasks.

Todos, for the small things

Code
/todo rename the config flag before release
/todos

A todo is a note to self with no plan attached. Use it for the thing you noticed while doing something else and don't want to lose.

When to skip planning

A one-file change. Planning it costs more than doing it. /plan earns its keep when the work spans files, or when getting the approach wrong would be expensive.

If it doesn't work

The plan is too vague to act on. Give the goal a finish line — the same rule as Asking for what you want — and redraft.

I approved it and lost it. /plans lists active plans across sessions.

The tasks don't match what I want. Say so before approving. After approval, add and close tasks directly.

Next