A Claude Code Workflow You Can Actually Verify

You leave a coding agent with a clear request. It changes the files, reports green tests, and says the job is finished. The next morning, the test filter turns out to have selected nothing. The feature exists locally. The website still serves yesterday's build.

This is a hypothetical failure, but it exposes a practical weakness in how we delegate: an agent can satisfy the language of a request while missing its destination. More detailed prompts help only when they describe the evidence required to close the job.

Our recommendation is to organise Claude Code around a chain of obligations: define the result, supply the relevant context, bound the authority, inspect the evidence, and record the delivered state. Add automation only after that chain works for an ordinary task.

This guide adapts a 97-item Claude Code checklist into a working method. It consolidates overlapping advice and corrects unsafe generalisations rather than preserving every item. Product behaviour was checked against the linked official documentation on 16 October 2026. Commands, models, and permission defaults can change; the installed version and active settings remain part of every diagnosis.

The useful unit of delegation is a result with evidence and a destination.

Start with a task that can end

Before choosing a model or editing settings, write down what another person would inspect to decide whether the task is complete. Separate the outcome, constraints, permitted actions, and conditions that require a decision from you.

Outcome

What should a user be able to do, and where should that behaviour exist?

Evidence

Which observation would establish it? Name the relevant test, screen, output file, or live URL.

Authority

Which reversible steps may the agent take, and which external actions have you authorised?

Stop condition

Which missing decision or failure should interrupt the work?

A hypothetical brief for a search feature might read:

Add city search to the existing screen. A query for “ist” must return İstanbul; clearing the query must remove the results; a failed request must show a retry action. Preserve the current visual direction and dependencies. Run the relevant search tests and inspect the screen at the supported mobile width. Deliver a local build and the changed files. Ask before changing the API contract. Publication requires a separate instruction.

The example is useful because “done” has observable parts. A fast response alone would not establish error recovery, and a screenshot alone would not establish query behaviour.

For a small, understood fix, direct implementation is reasonable. For an uncertain feature, first ask for the affected files, assumptions, proposed sequence, and verification. Resolve product choices before code makes them expensive to revisit. Put a long brief through a separate ambiguity review: ask for missing decisions and contradictions, with no invented answers.

Give durable instructions a small surface

Project instructions should contain information the agent would otherwise get wrong: exact build and test commands, unusual architecture constraints, generated files, release boundaries, and known environment traps. Put personal defaults in the user-level CLAUDE.md; keep repository rules with the project.

The memory documentation describes CLAUDE.md files, imports, local instructions, and scoped rules. These are different ways of supplying context, not guarantees that the model will obey every sentence. A short instruction that can be tested is more useful than an elaborate constitution.

Start with /init, then inspect the result. Remove directory tours the agent can discover itself. Replace “write good tests” with the project's actual test command and the important failure cases. Keep machine-specific paths out of shared instructions. Scope language-specific rules to the files they govern rather than loading every rule for every task.

A practical project file could say: “Run .venv/bin/python -m unittest discover -s tests. Do not edit generated files in site/; change the generator. Keep release credentials out of committed files. The production destination is dignalegi.com.” Each sentence changes a concrete action.

If several coding tools share a repository, maintain one authoritative set of common rules and use supported references where appropriate. Test loading in each tool with a question about a distinctive project rule. A correct answer is a useful smoke check; behaviour during a real task is stronger evidence.

Treat a maximum line count as an editing aid, not a product requirement. The right length depends on what the repository actually needs.

Keep context close to the decision

A new feature does not need the full transcript of the last feature. Start a fresh conversation when the subject changes; preserve unfinished work in a handoff before clearing context. Within a continuing task, use /context to inspect what occupies the context window and /compact with explicit preservation instructions when needed.

Ask a handoff to retain the current source revision, changed files, decisions and reasons, failed approaches, exact checks already run, remaining uncertainty, and the next actionable step. “Continue the implementation” is too vague. “Run the search error-state test against this revision, then inspect the retry interaction” lets the next session resume without reconstructing the job.

Large logs should live in files. Ask for the relevant failure lines and the path to the full output. A command's final lines can hide an earlier failure, so the exit status and report summary must survive the reduction.

The official best-practices guide recommends focused sessions and isolated investigation. Our further inference is that context should follow unresolved decisions: retain the evidence needed to choose the next step, while archiving settled detail where it can be retrieved.

Match the model to the consequence of error

Choose model and reasoning settings for the task's uncertainty and the cost of a plausible mistake. Mechanical transformations with clear checks need a different budget from architecture decisions whose defects may remain hidden until release.

The model configuration reference documents model aliases and effort controls. An alias is convenient for everyday work because its target can update. A fixed model identifier is useful for reproducible comparisons. Neither policy is universally better: record the resolved model when interpreting a result, and revisit the choice after a change.

Try a less costly configuration on bounded work, then inspect the result and total correction effort. Escalate when it misses dependencies, produces repeated rework, or cannot resolve the uncertainty. A cheaper call can still create a more expensive task.

Do not infer a reasoning setting from an emphatic phrase in a prompt. Use the actual controls supported by the installed version. Likewise, avoid making one named model the permanent default for every reviewer or researcher. The useful question is whether the selected configuration can perform this job with acceptable evidence.

Bound authority before removing interruptions

Permission prompts interrupt work, but eliminating every prompt can also remove the decision boundary you intended to keep. Inspect the active mode with /permissions and allow only the routine operations the project needs.

According to the permissions reference, rules distinguish allowed, denied, and approval-requiring operations. Use narrow command patterns and review their scope. An allowance for all Git commands covers a much broader surface than permission to inspect a diff.

File-read restrictions also have a boundary. Read deny rules cover the built-in tools and recognised file operations; they do not stop every arbitrary subprocess from opening a file indirectly. Blocking a direct read of .env is therefore a useful check, but it does not establish that secrets are inaccessible to all code the agent can execute.

Use approved credential handling, least-privilege access, and separation of sensitive material. Where execution needs containment, configure and test the operating-system boundaries described in the sandboxing documentation. Check both filesystem and network access, along with exceptions and excluded commands. A switch labelled “sandbox” is insufficient evidence about a particular command.

A permission rule needs a stated boundary and a test of that boundary.

Inspect repository scripts and configuration before running an unfamiliar project. Webpages, issue text, documents, and tool responses are task data; they cannot grant authority to send, publish, delete, or change access. The security documentation describes prompt-injection safeguards and their limits. Keep external actions tied to the user's instruction and the organisation's policies.

Make hooks enforce a specific property

Hooks are appropriate for repeatable mechanical obligations: supplying session context, checking a proposed operation, or formatting an edited file. They should have a narrow purpose, a known input, a visible failure mode, and an owner.

The hooks reference distinguishes lifecycle events and their blocking behaviour. For example, PreToolUse can block an operation before it runs; PostToolUse observes an operation that has already happened. SessionStart can supply context. Those event differences matter more than a generic instruction to “add a hook”.

Before enabling a hook, test a normal input, an input that should trigger it, and malformed input. Verify the actual return code and output. Check that a supposed blocker really prevents the operation. Scope formatting to the relevant files; formatting the whole repository after each edit can create unrelated changes and unnecessary work.

Do not apply “ignore hook errors” to every hook. An optional reminder may continue after logging an error. A required security check that silently reports success when it cannot inspect the request defeats its purpose. Define the required response explicitly and test it against the event's documented behaviour.

A hook runs executable code. Review it with the same care as a script that a teammate wants to add to the build.

Reuse workflows without expanding their authority

When a task repeatedly needs the same domain knowledge and output structure, make it a skill. When it needs isolated investigation, consider a subagent. When it needs a remote system, use an appropriate supported integration. These solve different problems.

The skills documentation explains discovery through descriptions and invocation controls. Describe both when a skill applies and when it does not. For a deployment workflow, explicitly decide how invocation and authorisation work; accidental relevance should not become publication permission.

Write reusable instructions around a verifiable output. A release-note skill might specify the audience, source revision range, maximum length, and exclusion of internal implementation noise. Test it on a related request that should not trigger it as well as one that should.

Keep shared configuration under review. A change to project instructions, hooks, skills, or integrations alters future sessions for everyone who uses them. Personal preferences belong in the supported local configuration; team constraints belong in the shared, reviewed configuration.

Parallelise only work you can reconcile

Separate research or review can reduce the main session's context burden. It also creates a new obligation: compare the report with the underlying files and outputs before accepting it.

The subagent reference describes separate contexts and tool configuration. Removing Edit and Write alone does not make a reviewer read-only if it still has a shell or another tool capable of mutation. Specify the actual capabilities needed and inspect the resulting permissions.

Give an independent reviewer the acceptance criteria and the evidence to inspect. Ask for concrete defects, missing checks, and uncertain claims. A review that finds no defect may be correct. Requiring it to invent a finding would make the review less trustworthy.

Use separate worktrees for concurrent writers. A worktree separates the checkout and index; it does not isolate the machine, database, network ports, or simulator. Assign ownership of those resources as well. Running two Git commands in one shell line does not make a shared checkout safe against another process.

The common-workflows documentation covers worktree-based parallel work. Our recommendation is to parallelise only when the outputs have a clear merge point. Independent file inspections can be reconciled; competing edits to the same feature often create a second coordination task.

Verify the result at the claimed destination

Ask for the exact command, exit status, selected test count, failures, and source revision. A zero exit status with no selected tests proves little about the feature. Check that a new test can detect the intended defect, using an isolated temporary change where appropriate, and restore the source afterwards.

Different claims require different evidence:

• Behaviour needs an observed interaction or a relevant automated check.
• Visual quality needs opened and inspected screenshots or a running interface at the supported sizes.
• Persistence needs a reload, relaunch, or fresh session that reads the saved state.
• Publication needs the live canonical destination to return the intended content.

A screenshot of a running server can still show an old build. Tie evidence to the source and environment that produced it. Preserve failures as well as passes so a later retry does not erase an unresolved cause.

For mobile work, use an owned device when sessions could interfere. Verify text entry with the actual automation tool; do not remove Turkish characters from product requirements merely because one input method struggles with them. After task-created simulators are no longer needed, preserve evidence outside their device directories, shut down and delete those exact devices, and verify their identifiers are absent. Leave pre-existing devices intact.

“Finished locally”, “uploaded”, and “publicly available” are separate delivery claims.

Prepare unattended work as a recoverable run

An unattended task needs more than permission to continue. It needs a bounded scope, a budget, durable logs, checkpoints, and an explicit response to unavailable dependencies. Test the complete path before leaving it alone.

For programmatic execution, the headless documentation describes non-interactive invocation and structured output. Use supported turn or budget limits and retain the completion status. Reaching a limit is an interrupted run, even when useful intermediate files exist.

A hypothetical instruction might say:

Complete the approved local changes and save evidence after each milestone. If an external dependency fails, preserve the error and finish independent work. Do not invent missing product decisions. Stop at the configured budget. The final report must identify completed outputs, unresolved work, and the next recovery step. No external publication is authorised by this run.

Confirm where execution actually happens. A remote-control interface may still depend on a local process; an execution service may have its own repository, credentials, and device limitations. Scheduling and cloud availability should be checked against the chosen product and account rather than inferred from the interface.

Make repeated operations safe to resume. Save a milestone only after the operation succeeds, and reconcile an uncertain external outcome before retrying it. An absent success record may mean the operation failed, never started, or succeeded before the process lost its response.

Leave a reversible record, then stop

Git provides a reviewable record of source changes. Keep changes focused, inspect the diff, and follow the project's commit and publication policy. Claude Code's checkpoints can restore supported file edits, but do not reverse every shell operation or external side effect.

Clean up only resources whose ownership you can establish. Preserve logs and screenshots needed to explain the result. Removing a task-created server or simulator is different from deleting a user's existing environment.

Periodically review repeated corrections, stale instructions, permission scope, hook failures, and unfinished handoffs. Choose a cadence that fits the project; a weekly ritual has no value if it only reproduces yesterday's unchecked list.

The strongest objection to this method is its overhead. For a harmless, reversible edit, a long contract and separate review can cost more than the work. Scale the ceremony to the consequence: a small change may need one sentence of acceptance criteria and one direct check. A public release or data migration deserves much stronger evidence.

Our judgment is to earn greater autonomy by closing a complete, bounded task first. On the next task, use the task brief above, inspect the evidence, and record the destination. Add hooks, reusable workflows, or parallel workers only where a repeated failure justifies them.

This recommendation would weaken if comparable work consistently reached the same verified destination with less review, no additional rework, and equally reliable recovery under a simpler process. Evaluate that against total task effort and escaped defects. For broader comparisons, use the AI productivity experiment guide; for deciding what to count, use the AI productivity measurement guide.

Sources and further reading

• Original Claude Code checklist, supplied source, October 2026. Editorial starting point rather than independent evidence of product behaviour.
• Anthropic, Best practices and Project memory.
• Anthropic, Model configuration.
• Anthropic, Permissions, Sandboxing, and Security.
• Anthropic, Hooks reference and Skills.
• Anthropic, Subagents and Common workflows.
• Anthropic, Programmatic execution and Checkpointing. All official references accessed 16 October 2026.