Introduction#
The fastest way to replicate this way of working is to get the environment right once. A single multi-repo workspace, a few core settings, one rule, one skill, and a verified set of connections do most of the heavy lifting before any real work starts.
The first part of the book was about the judgment that has to stay human. This part is about giving that judgment a place to operate, so the agent starts each task inside the right boundaries instead of waiting for you to rebuild them in every prompt. I am not going to give you a settings file to copy, because the exact keys and the editor of the month will have changed by the time you read this. What I want to give you here is the shape of a good environment, the part that does not expire, so you can rebuild it in whatever tool you are using.
One Multi-Repo Workspace#
The most valuable structural decision I make is to put every related repository into one workspace, even the ones I never commit to. I work as part of a larger team, with separate repositories for the data, the backend, and the user interface, and they all combine into one product. My own work lives almost entirely in the data layer, but the agent is dramatically more useful when it can see the whole thing.
The reason is context. When the agent can read across boundaries, it can reason about how a backend contract change ripples into the data models and the interface, instead of guessing at the half of the system it cannot see. That single change removes an entire category of cross-team surprises, the “did anyone tell the data side?” class of bug, because the data side is sitting right there in the same index. Search quality improves too, since the agent has the real surrounding code to ground its answers in rather than a single repository floating in isolation.
There is a small ordering trick worth knowing. Many tools scan the workspace from top to bottom, so I place the repository I work in most at the top and the ones I only read for context further down. The result is that the most relevant answers surface first. Then I save the workspace as a file, so I can reopen the exact same context every morning instead of rebuilding it by hand. The boundary you give the agent is the boundary it reasons within, so it is worth setting deliberately.
Core Settings and Shortcuts#
The settings that matter are the ones that remove small costs you would otherwise pay hundreds of times a day. Formatting on save eliminates style drift and the manual fiddling that goes with it. A visible line-length guide keeps width visible without thinking about it. Autosave on focus change means the agent and I are never arguing about unsaved state. None of these are exotic. They are defaults that keep the loop between intention and result short.
Shortcuts matter for the same reason. The two I reach for constantly are the one that opens the agent panel and the one that opens the command palette, because together they are the entry point to almost everything else. When the path to the agent is a reflex rather than a hunt, you ask it for help more often and at lower cost, and that changes how much of the tool you actually use.
I will name my own bias openly here. I am fortunate to work with strong hardware and broad access to capable models, and that does make some things smoother. I call it out so you can discount it, because the truth underneath is more encouraging, not less. The largest gains in this chapter do not come from expensive hardware. They come from clean workspace boundaries, reusable instructions, and consistent verification, all of which are free.
A First Rule and a First Skill#
Everything above is configuration. The part that turns a generic assistant into something that actually knows your project is the encoded standards, and the minimum viable version is exactly one rule and one skill. Start there, resist the urge to build a library on day one, and let real pain points tell you what to add next.
A rule is a persistent, always-on instruction that the agent carries into every task. I use my first one to encode the things I got tired of repeating, including naming patterns, the boundary of what a task should and should not touch, and the validation I expect to run on substantive changes. A good first rule is small and mostly about restraint, telling the agent to stay scoped and to follow the patterns already in the codebase rather than inventing new ones.
A skill is a step-by-step runbook for a task you do over and over. My first and most valuable one creates a new data model end to end, handling the SQL, the documentation, the tests, and a validation summary in a single pass. The full anatomy of rules and skills gets its own chapter, so here the goal is just to stand up one of each and feel the difference. The shift from re-explaining yourself every session to having the agent start already knowing your standards is the moment this way of working clicks.
Verifying the Setup#
A setup you have not verified is a guess, so the last step is to connect things one at a time and prove each one before moving on. When I add a connection to an external system, I add only that one, then run a small, safe prompt that exercises it, and only then move to the next. Connecting six things at once and discovering something is broken is how you lose an afternoon to a process of elimination you could have skipped entirely.
The verification prompts are deliberately boring smoke tests. Ask the agent to scan the workspace and summarize the architecture in a handful of bullets. Ask it to list the project conventions it should follow before editing anything. For a data project, ask it to explain the lineage of one model and suggest tests for it. If the answers are coherent and grounded in your actual code, the wiring is good. If they are vague or invented, you have found the problem now, cheaply, instead of in the middle of real work.
The most common failure this catches is context drift, where the agent wanders the codebase burning effort instead of solving the thing you asked about. The fix is almost always to be explicit about which files and folders matter rather than making the agent hunt for them. If I already know where the answer lives, I point the agent straight at it. A verified setup is simply one where you have already proven the agent can find its footing before you ask it to do anything that counts.
Putting It Into Practice#
- Put every related repository into one saved workspace, ordered with your most-used repository first.
- Set the few workflow-smoothing defaults, including format on save, a line-length guide, and reliable autosave.
- Make the agent panel and command palette muscle memory, so reaching for help costs nothing.
- Create exactly one always-on rule for your standards and one skill for your most repeated workflow.
- Exclude secrets, generated files, and vendor noise from the index so the agent reads signal, not garbage.
- Connect external systems one at a time, running a safe verification prompt after each before adding the next.
- Point the agent directly at the files that matter instead of making it hunt, and keep the literal config on the living web where it can age gracefully.
