TL;DR Most of the value sits in four habits: keep standing instructions lean, turn repeated work into skills, schedule the skills that earn it, and make anything that ships pass an adversarial review.
- Match model and reasoning effort to the difficulty of the job. Reserve the top of the range for work that genuinely needs it.
- Start hard work in plan mode, give the goal, and ask the model to interrogate you before it writes anything.
- Everything in a standing instructions file is re-read every session, so it competes for context. Keep it short and review it when models change.
- The skills worth building are the ones you already repeat. Ours cover writing register, article production, deck design and market segmentation.
- A loop only improves if it can judge its own output against something measurable. Without that it repeats, and repetition is not improvement.
Claude Code writes code, and most setups stop there. It also runs long tasks unattended, drives a browser, coordinates parallel agents, and enforces standards that would otherwise depend on someone remembering them.
Getting that takes an environment: standing instructions that stay short, reusable skills for the work that repeats, automation for the skills that have proved reliable, and review gates on anything reaching a client or a live site.
Everything below is how we run it at Lift-Off. Product names, settings and model tiers change often, so check current documentation before copying any specific configuration.
The same habits transfer between tools. Our companion guide covers the equivalent setup in Codex, where the threading model and the safeguards differ but the underlying discipline does not.
Matching model and reasoning effort to the job
Reasoning effort behaves like any other input cost. Raising it improves results on hard problems and adds nothing on easy ones, and the returns flatten well before the top of the range.
Run most work at a middle setting and raise it when a task turns out to be hard. Reserve the highest settings for problems where extra reasoning changes the answer. Paying top rates by default leaves no headroom for the work that needs it.
Model names and effort labels differ between accounts and change between releases. The routing habit carries over even when the names do not.
Prompting for hard work
Start anything substantial in plan mode. It forces agreement on what is being built before any file is touched, and it makes disagreement cheap, because rejecting a plan costs nothing, while rejecting finished work costs everything that went into it.
The prompt itself needs two things. Give the goal as the end state you want, and leave the sequence of steps open. Then ask the model to interrogate you before it starts.
Questions surface the constraints you forgot to mention and the edge cases you had not considered. Without them the model fills those gaps with assumptions, and the output comes back plausible and generic.
Keeping standing instructions lean
Claude Code reads a standing instructions file at the start of every session. Every line is re-read on every run and competes with the work itself for context.
Ours splits in two. A global file carries identity, communication rules, security rules and tool routing: which connector handles email, which handles calendars, which accounting tools may draft but never authorise. A project file carries only what that project needs, so the website repository holds its own build rules and regression patterns, which never reach the global file.
Keep a line only if it needs to change behaviour on every run. Notes about a fix that already shipped belong in the repository.
Rules also expire. Plenty of instructions exist to compensate for weaknesses in an older model generation, and they linger long after the weakness is gone, still consuming context on every run. Review the file when a new generation lands.
Turning repeated work into skills
A skill packages instructions Claude Code can invoke by name. At its simplest it is a prompt you no longer paste by hand, and the useful ones fall into two groups.
Capability skills teach the model to do one kind of work properly. Our humanizer skill carries the register we write in, a list of sentence structures that read as machine-generated, and a scanner that flags them. It exists because the same corrections kept coming back in review, and they now run as a check on every draft.
Workflow skills encode a sequence that should run the same way every time. Our article-forge skill takes a topic through grounding, angle selection, drafting, a deterministic pre-gate and an adversarial review panel, and it will not return an article that has not passed. Others handle deck production, positioning research and market segmentation.
The skills worth building are rarely the ones available to download. They are the sequences you already repeat, with your standards baked in. A useful starting point is to ask Claude Code to look back over recent sessions and identify what you keep doing by hand.
Connecting Claude Code to the rest of the toolchain
Connectors, plugins, MCP servers and command-line tools all let Claude Code reach the systems where the work already lives. The distinction between them matters less than the routing rule.
Ours sends email and calendar work to the account connectors, documentation lookups to a library-documentation server, live database reads to the platform plugin, and accounting to a local server with a standing restriction that it may prepare drafts and never authorise a payment. Browser control handles anything that only exists behind a web interface.
Write the routing down once in the standing instructions. Without it the model picks a plausible tool in place of the correct one, which is how a retired connector keeps getting called months after it was replaced.
Hooks for the events you keep forgetting
A hook encodes a rule of the form: when this happens, do that. The trivial version plays a sound when a long task finishes so you can work elsewhere until it does.
The valuable version is defensive. An agent with real permissions will occasionally propose a destructive command, and instructions alone cannot guarantee otherwise. A hook that inspects a command before the tool runs it moves the critical restrictions out of the model's judgement and into the execution layer, where a bad command is stopped regardless of what the agent decided.
Scheduling the skills that have earned it
Once a workflow is reliable as a skill, running it by hand becomes the bottleneck. A scheduled routine names the skill, picks a model and a working directory, and runs on a fixed cadence. Because the instructions already live in the skill, the routine stays a few lines long.
Loops that improve themselves
A loop that repeats a task is automation. A loop that improves needs two more parts: a way to judge its own output, and a memory of what worked last time.
The judging part is where most attempts collapse. An agent cannot iterate towards better unless better is stated in something it can measure on its own. A test suite going green, an error count falling, a benchmark clearing a threshold, a page staying inside a performance budget: each gives the loop a signal it can act on unattended. Reviewer satisfaction gives it nothing, and a loop aimed at a subjective target will optimise for whatever proxy it can find.
The review gate described in the next section is our clearest working example. Its evaluators return structured verdicts with severities, the revision step acts on those verdicts, and the loop stops on a stated condition. A recent long-form piece entered failing four of five reviewers and left passing all five, three rounds later, without a person supplying the fixes in between.
The memory is a file the loop writes and reads. Ours records the rule that would have prevented each defect, so the next run starts from the accumulated set instead of from zero.
Be precise about what that automates. The loop enforces standards it already holds. It does not discover new ones. When a genuinely new class of defect appears, a person still notices it and writes the rule, and our scanner has needed exactly that twice in the past week. Treating enforcement and discovery as the same capability is how teams end up trusting a loop further than it has earned.
Multi-agent review
Fanning work across many agents costs real money, and a quality gate on published work earns it back.
Every article we publish passes through a panel of independent reviewers, each briefed on one dimension and blind to the others. A fact-checker traces every specific claim back to a grounding pack and rejects anything that cannot be sourced. A reader advocate judges whether the piece is worth finishing. An editor checks structure and length. A voice reviewer hunts machine-written patterns. A cannibalisation reviewer checks the piece against its own siblings so two pages never compete for the same query.
Three things make the gate work.
Reviewers are briefed separately and never see each other's verdicts. A piece that satisfies all five has been attacked from five angles a single reviewer would have run together.
Their default is rejection, because a reviewer told to confirm quality will confirm it.
The loop has a cap. Ours allows three revision rounds, after which anything unresolved goes to a human with the objection quoted. Without a cap two reviewers can disagree indefinitely.
Capping the cost of parallel agents
Fanning work across many agents multiplies token usage, and a workflow that spawns dozens of them will spend accordingly. Name the model the sub-agents should use, cap how many may run, and save the pattern for work where a mistake reaches a customer. Exploratory analysis does not need five reviewers arguing about it.
Building the environment
The concepts above form a progression. Get the fundamentals right, which means routing models sensibly, starting hard work in plan mode and keeping standing instructions short. Make the work reusable by turning repeated sequences into skills and connecting the tools those skills need. Then automate what has proved reliable, and add measurement and memory so the automation improves with each run.
None of it is elaborate. A short instructions file, a few skills covering work you already repeat, a scanner with a test corpus, a learnings file, and a review gate on anything published. Together they hold what good looks like and what must never happen, so those standards survive a session ending.
We build these systems with clients running AI on work that reaches customers. If you want quality controls you can check, get in touch.