How to make Claude Code follow a process

Why does Claude Code skip steps in my process?

Because a process written in a prompt or in CLAUDE.md is context, not a rule. Claude reads it, weighs it against everything else in the conversation, and decides what applies right now.

Anthropic says this plainly in the memory docs: Claude treats CLAUDE.md files "as context, not enforced configuration", and to block an action regardless of what Claude decides you use a PreToolUse hook instead. The same docs warn that longer files reduce adherence, and that when two instructions contradict each other Claude may pick one arbitrarily.

So a ten-step checklist pasted into CLAUDE.md is a suggestion that competes for attention with the code, the task and the chat. Step 7 gets skipped not because the model is careless, but because nothing in the system makes step 7 a condition for step 8.

1. A process in the prompt is guidance. It works most of the time.
2. A process in a hook, a permission rule or a workflow engine is structure. It works every time it is checked.
3. Pick the strength per step: most steps need guidance, a few need a hard stop.

sourcesClaude Code docs: memoryClaude Code docs: hooks

What are the ways to enforce a process in Claude Code?

Claude Code has five native layers, from soft to hard: CLAUDE.md, skills, subagents, permission rules and hooks. Dynamic workflows script several agents in code. An external workflow engine over MCP adds state and gates that outlive the session.

sourcesClaude Code docs: memoryClaude Code docs: skillsClaude Code docs: subagentsClaude Code docs: permissionsClaude Code docs: hooksClaude Code docs: Dynamic workflows

How do I turn my process into a Claude Code skill?

Write the steps once in a SKILL.md file and invoke it by name. Only the skill name and description load at session start; the full steps load when the skill runs, so a long procedure stops costing context on every unrelated task.

1. 1

   Create the skill folder

   Project skills live in .claude/skills/<name>/SKILL.md and are shared through git. Personal skills go in ~/.claude/skills.

   mkdir -p .claude/skills/ship-fix

2. 2

   Write the steps as an ordered list

   Number the steps, name the commands, and end with the place where Claude must stop and ask. Setting disable-model-invocation to true means only you can start it, with /ship-fix.

   ---
   name: ship-fix
   description: Ship a bug fix. Use when the user asks to fix and ship a bug.
   disable-model-invocation: true
   ---
   Follow these steps in order. Do not skip one.
   
   1. Reproduce the bug with a failing test. Show the failure.
   2. Fix the code. Keep the change minimal.
   3. Run the full test suite: npm test
   4. Write a summary of the root cause and the fix.
   5. Stop and ask me before you push.

3. 3

   Run it

   Type /ship-fix in Claude Code, with the bug as the argument. Claude loads the steps and works through them in this session.

   /ship-fix the refund total rounds down on EUR orders

4. 4

   Check what loaded

   Use /context to see what is in the context window. After compaction, Claude Code re-attaches the first 5,000 tokens of each skill you invoked, so keep the important steps near the top.

sourcesClaude Code docs: skills

How do I stop Claude Code at a step it must not skip?

Use a hook or a permission rule for the steps that must never be skipped. A skill tells Claude what to do; a PreToolUse hook runs your own script before the tool call and can refuse it, whatever Claude decided.

The example below refuses git push until a test marker file exists. Exit code 2 blocks the call and sends your stderr message back to Claude. Permission rules sit alongside: deny is checked first, then ask, then allow. One caveat from Anthropic's docs: command patterns match the text, so a deny on "git push" does not catch "git -C . push". Use hooks for checks that need logic.

1. 1

   Write the hook script

   It reads the tool call as JSON on stdin and decides. Make it executable with chmod +x.

   #!/usr/bin/env bash
   # .claude/hooks/require-tests.sh
   # PreToolUse hook: refuse "git push" until the test marker exists.
   cmd=$(jq -r '.tool_input.command // ""')
   if [[ "$cmd" == git\ push* ]] && [[ ! -f .claude/state/tests-passed ]]; then
     echo "Run the test suite and record a pass before pushing." >&2
     exit 2
   fi
   exit 0

2. 2

   Register it in .claude/settings.json

   The matcher picks the tool. Add permission rules in the same file for the simple cases.

   {
     "hooks": {
       "PreToolUse": [
         {
           "matcher": "Bash",
           "hooks": [
             {
               "type": "command",
               "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/require-tests.sh"
             }
           ]
         }
       ]
     },
     "permissions": {
       "allow": ["Bash(npm test *)", "Bash(git commit *)"],
       "deny": ["Bash(git push --force *)"]
     }
   }

3. 3

   Gate the finish too

   A Stop hook can return {"decision": "block", "reason": "Build failed, fix errors before continuing"} to keep Claude working. Check the stop_hook_active field in the input so it cannot loop forever.

sourcesClaude Code docs: hooksClaude Code docs: permissions

What if my process has many steps, branches and sign-offs?

Then a single session is the wrong place to hold it. Skills and hooks live inside one Claude Code session on one machine; a process that spans days, people and several agents needs state that outlives the chat.

Claude Code's Dynamic workflows (a JavaScript script in .claude/workflows that orchestrates subagents) help with fan-out inside one session. Anthropic lists their limit: no mid-run user input, and "for sign-off between stages, run each stage as its own workflow." Sign-off, hand-off to a person and resume tomorrow are exactly what a process engine is for.

sourcesClaude Code docs: Dynamic workflows

How does ConvOps make Claude Code follow a process?

ConvOps holds the process as a graph of workflows and gives Claude Code one step at a time over MCP. Claude asks for the current step, does it, and asks to advance. The engine checks the gate on that step against real state, and an unmet gate leaves the cursor where it is.

The agent never sees the other steps, so there is nothing to skim past. Policies attach rules to the active step. Advancing can carry context, stored as a memory linked to the task, so the next session or the next agent starts where this one stopped.

1. 1

   Connect Claude Code

   One command. OAuth opens in your browser on first use.

   claude mcp add --transport http convops https://mcp.convops.app/

2. 2

   Put the process in a workflow

   Write the steps once in ConvOps, or start from a template. Mark the step that needs a person as requiring approval.

   {
     "id": "approve",
     "gate": {
       "requires_approval": true,
       "wait_for_children": true,
       "prompt": "Ship it?"
     }
   }

3. 3

   Ask Claude to do the task

   Claude creates or picks the task, reads the current step, and works it. When it tries to move past the gate before you said yes, the engine refuses and lists what is missing.

   workflow_advance(task_id="…")
   
   {
     "current_step": { "id": "review" },
     "unmet_conditions": [
       "Requires explicit user approval",
       "1 of 1 child tasks are not completed"
     ]
   }

4. 4

   Approve on the advance

   You review and say go. Approval has to be passed explicitly on the advance call, never inferred from chat text. The audit row keeps the agent label and the signed-in person.

Which approach should I pick?

Use the lightest layer that holds. A common setup uses all three: CLAUDE.md for facts, skills and hooks for one person's repo, and a workflow engine for processes the team shares.

Frequently asked questions