From a rough request to a reviewable coding task in VS Code

An AI coding session involves more than asking for a change. Someone still needs to settle the requirements, choose how to approach the work and decide what to check afterward.

This walkthrough uses a small contacts-search task to explain four controls in a custom VS Code/Kilo configuration: Clarify goal, reusable prompts, native subagents and next-message suggestions.

The screenshots were rendered from the installed interface in an isolated browser with sample data. The responses and job states are illustrative. No live coding run or performance comparison is being presented.

1. Review the goal before sending it

Start with: “Add search to the contacts list. Keep the current layout.”

That leaves several decisions open. Does search match names, email addresses or both? Should matching ignore case? What should happen when the query is empty or finds nothing?

Clarify goal opens an editable suggestion. In this sample, the suggestion names those behaviours and asks for checks covering them.

The important part is the review. A clarification model can misunderstand the task or add an assumption. Read the suggestion and change it before applying it. If the goal is genuinely uncertain, settle the missing requirement rather than accepting a guess.

Use this prompt puts the reviewed text into the composer. It does not send the message, and Cancel preserves the original draft.

2. Separate the goal from reusable instructions

The goal describes the behaviour you want. A reusable instruction describes how you want the agent to approach the work.

For example, “Inspect before coding” asks it to trace the existing flow and reuse current patterns. “Run tests” asks it to run the relevant checks. The Prompts menu keeps those instructions available without requiring you to type them every time.

Selecting a prompt inserts editable text. Review it in the context of the task. An instruction that is useful for one change may be unnecessary for another.

In particular, selecting Use multiple agents does not launch agents by itself. It adds an instruction that the lead will receive when you send the message.

3. Split independent work deliberately

For the sample search feature, imagine two agreed file boundaries:

• Filter logic in filter.js: accept a contact list and a query, return matching contacts.
• Search input in ContactsView.jsx: capture the query, use the agreed filter function and display the empty state.

The function contract needs to be agreed before both parts can proceed independently. If both agents need to redesign the same interface, resolve that decision first.

The strip shows the child jobs and their states. It helps you inspect delegated work; it does not establish that the combined change is correct. The lead still needs to inspect the results and run the relevant integration checks.

Native child sessions and separate terminal workers are different mechanisms. Do not assume every external worker will appear in this strip. The repository documents the two paths separately.

Small changes may be simpler with one agent. Nothing in this walkthrough measures a benefit from adding more.

4. Review the suggested next message

Once the work moves forward, the next useful request might be a review or a check rather than more implementation.

The next-message feature uses recent chat context to offer a suggestion. Tab accepts it into the composer; Escape dismisses it. Accepting a suggestion does not send it.

Here the sample message asks for a review of the combined changes and the search behaviour. You can make it more specific before sending—for example, by naming a missing edge case.

Recent context is not the entire history of the project. Check the suggestion against older decisions and the actual state of the files. It is an editing aid, not proof that the proposed action is right.

5. See which agents and models are involved

The composer identifies the selected CTO profile and model. These sample views show CTO or CTO + JEV with Opus 5.5 at Xhigh, following the requested setup reference. They do not change the installed default model. The worker strip also displays the role and model for each child, such as a DeepSeek implementer or a GLM investigator.

Those labels explain who is assigned to the work. They do not establish whether the result is correct. The selected profile still needs appropriate scope and verification.

6. Keep usage visible

The native header separates input, cached-input and output token totals. The screenshot below uses illustrative counts so you can see the fields clearly; they are not usage measured during a real run.

The current-context count and cumulative usage answer different questions. The first describes the context represented by the latest available assistant usage; the cumulative totals can include the relevant child sessions. Neither number is a productivity result or a measure of answer quality.

7. Evaluate the setup one piece at a time

The reference repository contains configuration, patches and installation notes. It is not a stock VS Code feature or a packaged one-click extension. Some patches target specific Kilo versions and require the documented checks before installation.

Read the prerequisites, use your own provider credentials and inspect one feature before adopting the whole configuration. In a disposable project, check whether applying a clarified prompt preserves the draft, whether prompt insertion behaves as expected and whether the next-message suggestion remains editable.

For the search task itself, keep implementation checks separate from interface checks. Name matching, email matching, case handling, an empty query and an unmatched query are a reasonable sample acceptance list. Replace that list with the actual requirements of your task.

Reference implementation and documentation: https://github.com/shrikrishna-skg/vs-code-configuration

Disclosure: This walkthrough was drafted with AI assistance. All screenshots contain clearly labeled sample data; they are not evidence of a live task being completed.