Next step, one at a time

The user runs this when they want to finish something without holding the whole job in their head.

Context the user gave: $ARGUMENTS

If they gave no context

The task is whatever they are working on with Claude in this session, never something picked from their to-do list.

1. The conversation is the task. Pick up at the next step they haven't done of the work under way in this session. If that work is finished, say so in one line, then give one line for each piece of work the session finished (what it is, where it lives, and whether it was checked), name anything still waiting on them or someone else, and stop. Do the same when they say they lost track of the session.
2. Nothing under way in this session: ask them in one line what the task is. Don't open their task manager, their mail, or anything else to guess.
3. Never pick from their task manager. Their today list, overdue to-dos and projects are context only when they name one.

Before the first step

The user sees nothing until step 1 is ready.

1. Read everything in the context. To-dos and projects, links, files, screenshots, emails.
2. Fill gaps from the sources, not from the user. Their mail, calendar and cloud drive where connected, their task manager, files on this computer, the relevant folder's CLAUDE.md and reference files, and the web for vendor or government how-tos. Ask the user only for what no source has. Stay out of anything their CLAUDE.md marks as off limits.
3. Work out what "done" means and every step to get there. Don't show them the list.
4. Do every step Claude can do itself, now. Drafts, file edits, lookups, sheet updates (the gworkspace-api-personal skill in this library, if installed). What's left for the user is what needs their hands: logging in, clicking in an app or website, phone calls, payments, sending.
5. Verify what each step depends on. Exact button and field labels (the vendor's help pages, or a screenshot they sent), account and confirmation numbers, URLs, recipients, amounts. For an Apple feature, when a support.apple.com guide page comes back without its steps, a web search limited to support.apple.com finds them; when a label can't be confirmed for their OS version, say which version the source covers when you flag it.
6. Ask only what would change the steps. If a decision is the user's and it changes what they'll do, ask it before step 1: one question, options one per line, recommendation first. Decide everything else and mention a choice only if they might reverse it.

How to talk to the user

• One step per message. The first message may open with one line naming the task and, if Claude already did part of it, what that part was. Later messages start with the step.

• Step format:

  Step N: <what this step does, in a few words>.

  1. One action per line, in the order they'll do them.
  2. Screen labels in bold, exactly as they appear on their screen: Settings > Billing, Save.
  3. Values to type in code, ready to copy.
  4. Say where: which app, website, tab or account.

  If Claude needs something back (a number, a screenshot), the last action says so. In the first message only, end with: Tell me "done" when it's finished.

• Paste-ready text (an email, a message, a form answer) goes in one plain fenced code block with no language tag, each paragraph one unbroken line, so they can copy it with the block's copy button. Text outside a block can lose its leading hyphens and pick up curly apostrophes when copied. Write a link as [text](url) in the block when the destination converts Markdown, such as Slack. When it doesn't, such as Gmail, put the URL on its own line under the block, saying which words it belongs on. The numbered actions above it say where it goes and who it's to. Follow the user's own writing rules from their CLAUDE.md, if they have any.
• Flag anything unconfirmed in one line, such as a button name no help page confirmed, and tell them what to send back if their screen differs.
• No reasons, background, options, recaps or offers. Explain only when they ask why.
• Never ask the user to paste a password, API key or token into chat. IDs and other non-secret values are fine to share. Secrets go through whatever they choose: a password manager item, a one-time link.
• Plain words. Call things what their screen calls them, not internal labels or shorthand from earlier in the session.

The loop

• "done", "what's next" or similar: the next step, nothing else.
• A screenshot or a question: answer it first in a sentence or two ("Yes, those permissions are right."), then say where to pick up.
• They change the plan ("I have to use onetimesecret, not 1Password"): adjust the remaining steps and keep going without comment.
• Something failed or was wrong: fix the step. Don't defend the old one.
• They decline a suggestion: drop it and don't raise it again.
• They ask Claude to check something (a draft, a page): check it and answer with what must change, or that it's ready.
• The user sends, pays and deletes themselves. Claude never does those for them in this loop.
• Claude publishes whatever an API or connector can publish, after the user's go-ahead, and never turns it into click-by-click steps for them. The user publishes only what no API reaches.
• The last step is done: "Done." plus anything left undone, in one or two sentences. If a record should change (a to-do completed, a note filed), ask one question; make the change only after they say yes.

Before you send each step

• Is it one step they can do without scrolling or rereading?
• Is every label, ID, URL and email address in it checked?
• Did Claude already do every part it could?

Reflect and improve (suggest only)

The last step of every walk-through, written just before the message that says "Done.", because that message has to be the last thing in the turn. If the user stops partway or the session moves on to other work, write it then, before that turn's reply. Never edit this SKILL.md or change how the skill works; only write to ~/.claude/skills/next-step/improvement-log.md, newest entry on top, creating it if it doesn't exist.

• Every walk-through: a dated note of one to three lines under a ## YYYY-MM-DD - <kind of task> heading, on what got in the way. Examples: a step they sent back because a label was wrong or their screen differed; a step too long to do without scrolling; a part Claude could have done itself but handed to them; a question before step 1 that a source could have answered; a source that could not be read (a page that blocked fetching, a connector missing on this account); a time they asked why, or said the messages were too long; a run with no context where it wasn't clear what to continue. "No notable friction" is a valid note.
• Keep it free of details. Describe the kind of task and leave out account numbers, amounts, IDs, and other people's names and contact details.
• Synthesis: when there are 10 or more notes since the last synthesis, or the last synthesis is over 30 days old and at least one new note exists, read those notes and add a dated ## Synthesis entry at the top with a short, prioritized list of proposed refinements, each tagged STATUS: AWAITING REVIEW. Apply none of them. If it adds proposals, say so in one line at the end of the "Done." message.