Developing features

Building a feature with an agent is not one giant prompt. With 4RGE, the reliable path matches good engineering — just faster:

Spec → plan → slice → review → verify → ship.

You say what "done" means and what to avoid; the agent implements and runs tests; you approve each diff and decide when to merge. This lesson shows how to run that loop without losing control of scope or quality.

What this page is for

Who this page is for

From idea to shippable

A practical flow that works for most features:

Skip heavy planning for tiny, familiar edits. Use the full flow when the feature touches multiple files, APIs, or behavior you will regret getting wrong.

Write a mini-spec

You do not need a formal PRD. You do need enough detail that "done" is obvious.

Include:

Answer the agent's clarifying questions — they prevent wrong assumptions early.

Plan before you code

For multi-file work, align on approach before source edits:

Review the plan like a design doc: remove steps that are not v1, add missing constraints, name the files you expect to touch. Then implement step 1 only in a focused run — Working with agents.

4RGE can track multi-step progress in the UI during long runs. For details on modes and planning, see Prompting and your product quickstart.

Build in slices

Prefer vertical slices — one thin end-to-end path — over "all backend first, UI later" unless your team already works that way.

After each slice:

1. Review the diff — scope creep shows up here
2. Run the tests you named in the spec
3. New message or run for the next slice if context is getting heavy — Context

Commit or stash when a slice is good — same as human workflow. "Scaffold, wire, test, polish" is still valid; the agent just accelerates each pass.

Example feature prompts

Copy, edit, and paste — use @ to anchor files in your repo.

First message (mini-spec + slices):

Add a discount code field on checkout.
 
Done when:
- Invalid code shows inline error (no page crash)
- Valid code lowers total before tax; total never below zero
- Match existing checkout UI in @checkout/OrderSummary.tsx
 
Build in two slices: (1) pricing validation + unit tests,
(2) checkout UI wiring.
Run: pnpm test apps/web -- checkout
Do not change the task list API or database schema.

Plan only (no code yet):

Before editing source: outline steps and files for the discount code feature above.
List risks and what we should cut for v1. Do not write code yet.

Slice 1 (backend / logic first):

Implement slice 1 only: validate discount code in the pricing service and add unit tests.
Follow patterns in @services/pricing. No checkout UI changes yet.
Run pricing tests when done.

Slice 2 (UI wiring):

Implement slice 2: wire checkout input to validation; match @checkout/OrderSummary.tsx UX.
Run: pnpm test apps/web -- checkout

Verify before merge:

1. pnpm test apps/web -- checkout must pass.
2. Flag anything outside discount scope in the diff.
3. One-sentence summary of what shipped — I'll merge if green.

When the direction is wrong (reset):

This diverged from the spec — wrong pattern in pricing. Revert changes outside
packages/billing. Restate plan for slice 1 only; match @services/pricing exactly.

More templates: Prompting. After the diff exists, optional review pass — Reviewing and testing code.

Match your repo

Features go wrong when the agent invents a parallel pattern.

Project rules and plugins nudge the agent toward team conventions — Customizing agents. You still review the diff.

Verify before you merge

Agent-generated code is draft until you say otherwise.

What good feature work looks like

When to hand off to cloud

Use local agents when you are pairing interactively — quick approvals, tight loops.

Use cloud agents when:

Cloud still needs a clear brief — vague cloud jobs produce vague diffs. Same mini-spec discipline.

When the first build is wrong

Fixing a bad direction with ten follow-up messages often loses to reset:

1. Revert agent changes (checkpoint, Git, or discard files)
2. Tighten the spec or plan — what was missing?
3. Run again — one slice, not "fix everything"

This is faster than arguing with a thread that already went down the wrong path — Working with agents.

Habits that work

1. Mini-spec in the first message — acceptance + constraints.
2. Plan for multi-file — Plan mode or outline-only pass.
3. One slice per approval cycle — review before the next expansion.
4. Name tests to run — agent and CI should agree on green.
5. Capture learnings in rules — e.g. "percentage before fixed discounts" for next time.
6. Explore unfamiliar areas first — Understanding your codebase.

Where to go next

Questions about developing features?