Turn a complex feature into a team of AI sessions

An export button is more than one task

“Add an export button to the dashboard.”

The request sounds small. Does it export every record or the current filter? Can any member use it? What happens when there are no matching records? What will users see if the request fails? Do the interface and server agree on the fields?

Keeping every detail in one conversation can mix requirements, implementation, and test results. Opening unrelated conversations creates another job: you have to carry each decision from one window to the next.

Onevium Team gives work with clear boundaries a persistent structure. A lead session coordinates real member sessions. Members work on their parts and report back, and you can open their conversations to inspect or continue the work.

This guide uses a fictional SaaS export feature. You will leave with a task prompt, a division of responsibilities, and a way to decide whether the complete feature is ready for review.

The business scenario and coordination example are fictional teaching material. They have not been run end to end in a demonstration project and are not measured customer results. Entry points follow the Onevium 1.1.23 Team documentation.

Give the team a goal you can verify

A business owner wants administrators to export the currently filtered customer list as CSV for an operations workflow. Keep the first version focused on that behavior.

The table below sets out this example’s choices. Adjust the roles and fields to your product before starting. Actual accounts, routes, file locations, and commands must come from the project.

Divide the work, then identify dependencies

The lead keeps the overall goal consistent. Each of the four members owns a deliverable that can be checked. The table and conceptual workflow below show how their work depends on the others.

Four members fit this teaching example. For a first trial, two may be enough: one implements a bounded change, another checks it. More members also mean more briefs, reviews, and model usage.

Early investigation can overlap: member 1 clarifies behavior while the others inspect their modules and plan checks without changing implementation. Once the contract is agreed, server and interface work can proceed in separate files. End-to-end verification follows when both run together.

Start from @Team in Onevium

Open a regular project session. Type @, select Team under extensions, add the task, and send it.

First confirm that the session can load a compatible team Skill and use the Sessions tools under Settings → Tools → Sessions. Seeing a Team label does not establish that the Skill is installed and available. Follow the Team prerequisites if something is missing. This workflow uses Onevium session teams; the upstream Claude CLI experimental Agent Teams toggle is not its master switch.

After sending the task, review the proposed members, files, deliverables, and checks. When they are right, confirm the first phase. The lead creates real child sessions one at a time and sends their tasks. Confirm both session creation and initial delivery, then open the members through the session tree or Team card.

The prompt below asks for a plan first and states the three phases, start conditions, write boundaries, and local delivery requirements.

Confirm that you can load the team Skill and use the tools for creating member sessions, session communication, and team reports.

I want to add a customer export feature to the current demonstration project.
Inspect the project and propose a Team plan. Wait for my confirmation before starting.

Goal: administrators export the currently filtered customer list as CSV.
Columns for this example: record ID, demo name, status.
Ordinary members must not export through either the page or a direct request.
Show a clear empty state without generating a CSV; preserve filters and allow a retry after a failure.
Use local synthetic records. Do not use real customer accounts or contact recipients.

Proposed responsibilities:
1. Behavior and interface contract: roles, fields, empty state, errors.
2. Server: implement the agreed endpoint and authorization checks.
3. Interface: implement the page, state feedback, and narrow-screen layout.
4. Verification: prepare independent cases, then check the running result.

Inspect existing changes first. Name actual files and give each member a unique write scope.
Assign shared types, configuration, and common files to one writer.
Run dependent work in order.
The lead maintains the shared plan, interface decisions, briefs, and verification conclusions.
Summarize each phase and wait for my confirmation before starting the next.

Use three phases: agree the contract; implement independent parts; integrate and verify.
List inputs, deliverables, start conditions, member models, and estimated usage.
Use documented project commands; report missing instructions instead of guessing.
Deliver locally only. Do not commit, push, deploy, or send promotional content.

Make the shared agreement easy to find

The Team protocol stores the shared plan and member briefs under the project's .claude/sdd/team-<slug>/ directory. The lead maintains team.md; each member brief describes the task and write scope. Member reports are also expected here, but their actual files must be checked.

For this feature, the shared agreement should say how filters are passed, what the CSV columns mean, how authorization fails, and what an empty result does. Reference that agreement from the member briefs.

Members do not automatically receive each other's complete conversation history. Include necessary context in the brief, relevant files, and messages from the lead. A field changed in one session is not automatically understood by every other member.

Assign shared type files to one writer. Other members can read them or request a change. The Team tree does not create separate file copies, and an ownership instruction is not a filesystem lock. Review the final diff.

What coordination looks like when an interface changes

Suppose the server member discovers that the existing status field means something different from the label in the interface. The export needs a clear decision about which value to use.

Onevium session tools can send a message to a member. An idle target can start another turn; a busy target may receive the update in its current turn or have it queued. Inspect the delivery result instead of repeatedly creating members or resending the task.

This can reduce the technical details you have to relay yourself. Business decisions and review still need attention. The current Team protocol centers coordination on the lead; it is not a promise that every member freely chats and independently resolves every decision.

Here is the intended workflow, shown as an illustration rather than a recorded product run:

• Find: The server member reports the mismatch, its impact, and the decision needed to the lead.
• Decide: The lead checks the agreement and clarifies the meaning. If it is a business decision, the lead brings that question to you.
• Communicate: After updating the agreement, the lead sends the change and the relevant file location to the interface and verification members.
• Adjust: Those members update their work and checks, then report back.
• Check: The lead confirms that everyone is using the same contract before continuing.

Turn member reports into a verified feature

At the end of its work for a phase, each member should use report_team_result to report its outcome, changed files, checks, and unmet acceptance conditions. The lead checks the actual report, message, and diff before returning defects to the responsible member. A reporting acknowledgment does not establish that the file, delivery, and verification all succeeded.

Run the checks against the same candidate version. If relevant files change afterwards, repeat the affected checks instead of carrying forward an old result.

For the export feature, check at least the actual paths listed below.

Keep delivery evidence and unfinished work together

In the team record, reported means a member has reported and still needs review. verified records the lead's verification conclusion and contributes to the card's verified count. An idle session, an increased count, or a completion message still needs to be understood alongside the evidence.

Use the handoff format below and replace every bracket with actual evidence.

Delivered behavior: [scope]
Candidate: [file snapshot or existing commit identifier]
Passed: [case, environment, result evidence]
Remaining work: [issue, responsible member, next step]
Not verified: [paths missing environment, data, or permission]
Member reports: [report locations and final diff]
Production status: no commit or deployment in this exercise

The business value to evaluate

A person handling every part of a feature repeatedly switches context. Several sessions without coordination can also consume time in repeated explanations and incompatible decisions.

Team provides work that can be inspected and continued: a contract has an owner, an interface problem has a member to return to, and a verification gap comes back with evidence. Independent parts can overlap when their dependencies allow it.

During a pilot, record manual handoffs, clarification rounds, dependency waiting, rework after review, and model usage. Compare with similarly sized tasks before expanding. Four sessions do not establish a fourfold productivity gain.

Anthropic's AI-native SDLC playbook connects work across development stages and discusses parallel sessions and independent checks. This guide applies that broader direction to a Onevium session team. The business example, prompts, and division of work here are independently designed.

Carry verified work into tutorials and promotion

Once the feature has been checked, prepare a factual capability brief: who can use it, what was verified, remaining limits, and which demonstration assets may be public.

A separate lead session can use that brief to organize content work. One member writes the tutorial, another prepares a demonstration script, and another drafts the announcement. Give them verified facts and approved public assets instead of the full internal engineering conversation.

Send the task below in a separate lead session, using verified facts and approved public assets to prepare local content drafts.

Propose a content Team plan and wait for confirmation before starting.
Inputs: the verified capability brief, approved public demonstration assets, and audience description I provide.
Goal: help a first-time administrator understand the export feature and complete one export.

Member 1 writes the tutorial.
Member 2 prepares the demonstration script.
Member 3 drafts the blog summary and social copy.
Use separate output files. The lead owns the shared fact list and final integration.
Connect each feature claim to evidence in the inputs; mark missing evidence for review.
Start with the user's problem, explain steps and conditions, and invent no customers or performance numbers.
Produce local drafts only. Do not post, email, or publish the website.

Further reading

This connects the original request, implementation, verification, and launch preparation. Read the existing AI-native SDLC guide for the wider development workflow, and use the Team documentation to check entry points, prerequisites, and troubleshooting before starting.