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 measure success and remember what worked. A test corpus supplies the first and a learnings file supplies the second.
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 gets better needs two more parts: a way to tell whether the output was any good, and a memory of what worked last time.
Our humanizer scanner works this way, and it changed twice in one week for this reason.
The trigger is a draft heading for publication and the task is a scan for machine-written patterns. Success is measurable, which is the step most loops skip. The scanner ships with a test corpus: passages that must be flagged, and legitimate near-miss prose that must stay clean. A change that improves detection while breaking normal writing fails the corpus immediately.
The memory is a learnings file. When a pattern slips through and a human catches it, the pattern joins the scanner, examples join the corpus on both sides, and the rule that would have prevented it joins the file. Two recent additions came from exactly that route: a class of jargon nouns the regular expressions had no entry for, and a spacing rule that had let unpaired dashes hang fragments through several reviews.
Trigger, task, measurable result, log, next run. Without the corpus there is no way to know whether a change helped. Without the log every session starts blank and relearns the same lesson.
Loops work best where success is objective. A test suite, an error count, a benchmark score and a page-performance budget all qualify. Reviewer satisfaction does not, and a loop pointed at a subjective target will optimise for whatever proxy it can measure.
Multi-agent review for anything that ships
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.
The cost of fanning out
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.