Coding

This skill is about routing code work, not doing it inline. When a request means navigating a repository or changing source files, the heavy lifting belongs in an isolated session sandbox — not in the context you're orchestrating from. Your job is to make the setup decisions, hand off cleanly, and report back.

Reach for this skill for repo-shaped requests: implement, fix, refactor, make tests pass, work a ticket, open or review a PR. It also covers data-shaped work that deserves the same treatment — SQL/warehouse analysis, dataset-backed investigations, or a mix of code and analytical output (see Data, SQL, and Warehouse Work below). Skip it for conceptual questions that touch no repository or dataset — answer those directly.

Two ways to delegate, pick by weight

Kortix gives you two delegation paths. Choosing the right one is the whole game.

The explore subagent — cheap, read-only recon. When you need a fast answer about a codebase ("where is auth handled", "what calls this function", "does this repo use Vite or Webpack") and you do not need to change anything, invoke the read-only explore subagent via the task tool or an @explore mention. It searches and reports a conclusion instead of dumping files into your context. Use scout instead when the answer lives in an external dependency you'd need to pull source for.

A background session — the real worktree. When the task is to change code — implement, fix, refactor, run a test suite, push a branch, open a PR — spawn a background session with the Kortix sessions flow (session_start_background, or session_spawn for parallel work). Each session is its own isolated VM sandbox with full tooling, so it can install, build, run, and commit without touching your environment. Read results back with session_read. This is the equivalent of handing the job to a dedicated coding agent.

Keep the codebase out of your orchestrating context. Don't drag a large or external repo into the session you're routing from — don't crawl its file tree, read its source, or fetch raw files from GitHub to "understand the architecture" first. That's what the delegate is for, and it explores far more efficiently than you can from the outside. Pass tickets, requirements, and constraints in the prompt; let the session discover the code. (Small, self-contained edits inside the current project are fine to do directly — the rule is about not importing an entire codebase into your head before delegating.)

Decide where the code lives, then say so

Before you spawn anything, settle the workspace question and state it plainly in the session prompt. Don't make the delegate guess from phrases like "in the repo." Pick one: