How to Scope Engineering Projects with AI Before Writing Code

The most expensive moment in any engineering project is the one before the first commit. The wrong scope at the start compounds for weeks: too narrow and you are back inside the same module a sprint later, refactoring the thing you should have refactored the first time; too broad and you have burned a quarter of the runway on work nobody asked for. Yet this is exactly the moment that mainstream AI coding tools skip. Cursor, Copilot, and the various assistant chat windows all share the same pattern. You hand them a brief, they hand you a function. The work of *scoping*, deciding how deep to go, what to include, what to defer, what to refuse, is treated as if it does not exist. The tool reads your prompt, picks a reasonable interpretation, and starts writing. That is fine for autocomplete. It is a disaster for project work.

Scoping is the work of an engineering lead, and it is the single hardest thing to do well in software. It requires reading the codebase as it actually is, not as the brief assumes it is. It requires holding several plausible implementation paths in your head and weighing them against each other on time, risk, and reversibility. It requires the discipline to come back to the requester with a structured set of options rather than a single take, and the judgment to flag when the brief itself is the problem. The /apex-plan skill exists to do this work. It is the part of tonone that runs before any code is written, and it is the part that most directly maps to what an experienced tech lead does when a Slack message lands in their DMs at 2pm on a Tuesday.

Why generalist AI skips the scoping step

When you ask ChatGPT or Claude.ai to help with a feature, the model is shaped by the format of the question. You typed a prompt, the model produces output. The session has a conversational arc that strongly favors momentum: the longer the chat goes without code, the more it feels like the model is dodging. So generalist tools optimize for the appearance of progress. They write *something*, usually the most obvious interpretation of the brief, and they write it fast. That feels productive in the moment, and it produces the wrong artifact. A scope document is short, often boring, and contains decisions that the requester did not realize they needed to make. Code feels valuable. A scope document feels like overhead. The tools that respond fastest to the prompt are the ones that skip the overhead, and that is precisely why they cannot replace a tech lead.

Cursor and Copilot are not even trying to do this work. They are autocomplete layers, designed to extend the line you are already typing or fill in the function you are already writing. That is a genuinely useful capability, and it is the wrong tool to point at the question of whether the feature should exist in its proposed shape at all. When you ask Cursor to implement a multi-tenant migration, it will start writing the migration. It will not ask whether the tenancy model should be schema-per-tenant or row-level isolation, because that is a decision Cursor cannot make from the editor context. It will simply pick one (usually the more popular one in its training data), write it, and leave you to discover the mismatch with your existing infrastructure on integration day.

The deeper issue is role confusion. A generalist coding assistant plays one role, code responder, and plays it in every situation regardless of whether the situation calls for a responder, a planner, a reviewer, or a refuser. Engineering teams work because they have layered roles: a lead who scopes, contributors who execute, a reviewer who challenges, a manager who decides. Compressing all of that into a single prompt-response loop produces output that looks productive in the short term and creates technical debt at integration time. /apex-plan is a deliberate step out of the responder role and into the lead role, with the goal of producing a small, structured artifact that the requester can read, push back on, and approve before any code is dispatched.

What real scoping actually requires

When a senior engineer scopes a project, they do four things in sequence. First, they read the brief carefully and identify the parts that are underspecified, the parts that contradict each other, and the parts that imply a constraint the requester may not have thought through. Second, they read the codebase as it currently exists: the actual file structure, the actual dependency graph, the actual hot paths in the code, not the idealized version in last quarter's architecture diagram. Third, they hold the brief and the codebase together in their head and produce *several* plausible paths through the work, each with its own tradeoffs. Fourth, they pick a small number of those paths (usually two or three), give each one a time and risk estimate, and present them as options to the requester.

This is the work that mainstream AI tools cannot do, because it requires judgment that operates above the code level. It is not about syntax or framework knowledge; it is about knowing when a request is underspecified, when a quick fix will accumulate technical debt that costs ten times more to remove later, when a system needs a new abstraction instead of another patch, and when the right answer is to push back on the brief itself. These are judgment calls that require context, and that context has to be built by reading the actual repository, not by skimming the prompt. The /apex-plan skill is built for this specifically: it does the read, holds the options in structured form, and returns a document that surfaces the tradeoffs rather than burying them.

How /apex-plan works

Step one: read the brief and challenge it

When you invoke /apex-plan, the first thing Apex does is read the brief carefully and look for the parts that are underspecified or contradictory. If the brief says "add multi-tenancy to the API," Apex will surface the questions that brief implies: are we isolating at the database, the application, or the infrastructure layer; are tenants billed separately or pooled; do tenants need their own audit trail; what happens to existing data on rollout. These questions are not pedantic; they are the decisions that shape the entire scope. A generalist AI will pick a reasonable answer and proceed. /apex-plan will ask, in writing, before doing anything that costs tokens.

Step two: read the actual codebase

Apex then performs a structured read of the codebase: the file layout, the dependency graph, the test coverage shape, the hot paths in the code, and any signals of recent churn. This is not a deep static analysis; it is the kind of orientation a senior engineer does in their first hour on a new project. The goal is to produce a quick map of the system as it actually is, so the scoping options are grounded in real constraints rather than imagined ones. If your authentication is already mediated by a third-party identity provider, the scoping options will reflect that. If your data layer has not been touched in eight months, that gets flagged before it surprises someone halfway through implementation.

Step three: produce S, M, and L options

The core output of /apex-plan is three options. Small addresses the core requirement with the minimum surface area: the most direct path to a working feature, with explicit lists of things being deferred. Medium includes the obvious adjacent improvements: tests for the changed code, the small refactor that the new feature exposes, the documentation update that prevents the next person from being confused. Large treats the requirement as an opportunity to modernize the relevant subsystem: the migration that has been on the backlog for six months, the abstraction that would let you extend cleanly next quarter. Each option is presented with a time estimate, a token cost estimate, and a list of what is included and what is explicitly out of scope. You pick the depth before any work is dispatched.

Step four: time and token estimates

Each option carries two estimates. The time estimate is in human-readable units (hours for a Small, a couple of days for a Medium, a sprint for a Large) and reflects the wall-clock cost if the work is dispatched to specialist agents. The token estimate is in API units and reflects the cost of generating, reviewing, and revising the work through Claude Code. Token estimates matter because they are the lever that lets you reason about budget. A /apex-plan output that says "Large costs about 4x the tokens of Small" lets you decide whether the scope is worth the spend before you commit to it. This is information no generalist tool surfaces, and it is the difference between running a token budget and discovering you blew through it on Friday afternoon.

Tonone's /apex-plan skill scopes engineering work before any code is written, presenting S, M, and L depth options with time and token cost estimates so the requester chooses the investment level.

When to use /apex-plan, and when not to

/apex-plan is for non-trivial work where scope is unclear. The signal is when more than one reasonable implementation path exists, or when the brief uses words like "refactor," "redesign," "add support for," or "start using." These are framing words that hide a scope decision. If the requester says "fix the timezone bug in the daily summary," that is a bug fix and you do not need a scoping skill; the scope is the bug and the test that proves it. If the requester says "make the daily summary work for international users," that is a scope decision dressed as a feature, and /apex-plan is the right entry point.

The skill is also the right starting point for any project where the codebase is unfamiliar to the person making the request. Inheriting a service, picking up a colleague's branch, doing a year-end review of a system you have not touched in six months: in all of these, the scoping output is doing double duty as an orientation document. You learn the shape of the system *and* you get a structured set of paths through the work. For purely greenfield projects, where the codebase is empty and the question is what to build first, /apex-plan still helps but the value is lower; the bottleneck is product decisions, not engineering tradeoffs, and /helm-brief may be the better entry point.

What the dispatch step looks like

Once you pick an option, /apex-plan does not start writing the code itself. It dispatches the work to the right specialist agent or sequence of agents. A scoping option that touches the API surface and the database schema goes to Spine and Flux; a scoping option that adds new auth flows goes to Warden; a scoping option that adds a new dashboard goes to Prism and Lens. The plan output includes the dispatch chain so you can see, before approval, which specialists will own which slices of the work and in what order. This is the multi-agent coordination layer that mainstream tools do not have, and it is the reason scoping with /apex-plan is materially different from scoping with a generalist chatbot.

A worked example

Suppose the brief is: "We need to support team accounts. Right now everything is per-user. By end of quarter, ideally." That brief looks like a feature request. It is actually four scope decisions in a trench coat: the data model change, the billing change, the access-control change, and the migration path for existing users. Run /apex-plan against the repository and you get back something like the following structure.

Brief: Add team accounts. End of quarter target.

Clarifying questions (resolved before estimating):
- Are team members billed at a flat rate, per seat, or pooled across the team?
- Do existing users get migrated into a default team, or do teams start empty?
- Is access scoped at the API layer, the database layer, or both?
- Are roles (owner, admin, member) part of v1 or deferred?

Recommended Small (~3 days, ~600k tokens):
- Add `teams` and `team_members` tables.
- Add `team_id` to existing user-scoped resources behind a feature flag.
- API stays per-user; team context resolved server-side from membership.
- Migration: each existing user gets a default solo team.
- Out of scope: team billing, role-based permissions, team invites UI.

Recommended Medium (~2 weeks, ~2.4M tokens):
- Everything in Small, plus:
- Roles (owner, admin, member) and a per-route permission check layer.
- Team invite flow with email and signed token.
- Audit log entries scoped per team.
- Out of scope: SSO at the team level, billing changes.

Recommended Large (~4 weeks, ~6M tokens):
- Everything in Medium, plus:
- Per-team billing (Stripe customer per team).
- SSO at the team level via SAML connector.
- Team-scoped API tokens with scoped permissions.
- Migration tool with rollback for tenants who request reversal.

Dispatch chain (Medium):
1. Flux: schema migration, backfill plan.
2. Warden: permission check layer, audit scope.
3. Spine: route changes, invite endpoint.
4. Prism: invite UI, team settings page.
5. Proof: integration tests covering team isolation.

That output is the artifact a senior engineer would produce in two to four hours of focused reading. /apex-plan produces it in minutes, and it produces it from the actual state of the repository rather than from memory. The requester reads the document, picks Medium, and the dispatch chain runs. Or they push back, ask for a different cut, and the plan is revised. Either way, the scope decision is made before the first line of code is written, which is the whole point.

Related skills

/apex-plan is most useful in combination with the skills that come before and after it in the work cycle. Before the brief lands, /helm-brief turns a vague feature idea into the structured input /apex-plan reads from. After the plan is approved, /apex-takeover is the right call when the codebase is unfamiliar and you need a deeper read before dispatch. And once the work is shipped, /apex-status produces the executive summary that closes the loop.

Install

/apex-plan ships with the Apex agent in the Tonone for Claude Code package. Install Tonone, invoke /apex-plan from any Claude Code session, and you have the scoping skill available wherever you work. The skill is free and MIT-licensed; the only cost is Claude Code token usage during the work itself, and the token estimates produced by the plan let you control that spend before you commit.

Use /apex-plan whenever a brief crosses your desk and the right answer is not yet obvious. The discipline of producing options before code is what separates engineering from typing, and the skill is built specifically to make that discipline cheap enough to apply every time.