Claude Code or Codex can set up barua onboarding email by connecting your product's server events and completing the setup steps your permissions allow. Start with a specific activation milestone. Review the proposed play, then verify delivery with a recipient you control and check that completed users stop qualifying.
This guide follows barua's current setup documentation. The website-builder example below is a planning example, not a customer case study. Your agent must verify the result in your own product.
What do you need before starting?
You need access to a barua workspace and to the project that records your users' actions. barua is in early access; the homepage is the access path.
Give your agent the repositories it needs to inspect, including the server. Decide which domain should send the messages and where replies should go. If authentication or billing already sends email, tell the agent to preserve those paths.
Choose an activation milestone you can observe. For a website builder, that might be the first successful publication. The event must mean that the task succeeded; clicking a publish button is only an attempt.
1. Start with the maintained setup instructions
Give your agent this prompt with the project open:
Fetch and follow the instructions at https://barua.ai/setup.md
to set up barua for this project.
Start by inspecting existing integrations and the current workspace.
Preserve working email paths and resume completed setup.
Our first onboarding journey should help users finish publishing
their first site. Confirm that this matches the actual product.
Keep launch awaiting my approval. Report progress in plain US English
with concrete evidence and short paragraphs. Don't invent product facts
or describe an accepted request as a delivered email.
Replace the website sentence with your real activation milestone. The setup entry point loads the current skill and directs the agent to the right references. That keeps the detailed procedure current as the product changes.
2. Give the agent the permissions you intend
The workspace owner can create an agent connection in Settings → Agents. Choose its permitted changes and the review checkpoints you want to retain.
The management key controls those permitted workspace actions. Event keys have a separate job: the test key validates events in development, while the live key is used for real product activity. The installation guide explains the distinction and secure handoff.
Save keys through the supported secret handling process. Keep them out of chat and source files. If a connection already exists, have the agent inspect and reuse it when its permissions are sufficient.
Full delegation only covers the granted permissions. The agent still needs launch permission to enable sending. The owner accepts the terms and supplies or authorizes the statement about permission to email people.
3. Agree on what the events mean
Have the agent show where the server records each fact. For the example product, registration maps to signed_up. The plan could use created for site creation and activated for first successful publication.
The agent should send each event after the underlying change is saved. It should use the same user identity throughout the journey and preserve the event's identity when retrying a request.
Review the completion event as carefully as the starting event. If activation arrives only from one publishing path, users who publish another way could keep receiving setup reminders.
Where your product has no source for a declared event, the plan should say so. The event contract describes which events are required and how unsupported declarable events are recorded.
The lifecycle event worksheet helps you record the source and meaning of each fact before implementation.
4. Review the play and its actual email
barua proposes plays from the available events and writes their messages in your brand's voice. A useful first play might wait after site creation and help the user finish publishing if activation hasn't happened.
Inspect the exact proposed rule and the rendered email. Confirm the unfinished step and the destination button. Check the delay against your product's normal usage.
Approval applies to a specific revision. A change to the words or rule needs another approval. An authorized agent can perform the approvals you delegate; checkpoints you retain stay with you.
Keep the example narrow enough to assess. A single reminder with a clear completion condition is easier to verify than a long sequence whose later messages assume facts you don't yet collect.
5. Validate the events before enabling sending
Run the product paths with a test event key and inspect the recorded results. The test key validates event shape without creating people or sending email.
That makes it useful for integration checks, but it cannot establish that an email was delivered. Live processing also has identity and state that a test-key validation does not exercise.
Ask your agent to show the source action and the result for each required event. If something fails, resolve it before moving to the delivery check. Leave the integration's diagnostics available so a future failed event can be investigated.
6. Follow launch order and verify a fresh delivery
Approving plays and enabling sending are separate steps. A new workspace starts with sending off. An event from before you first enable sending cannot start a play.
When launch is authorized, have the agent follow the current setup procedure in order. Verify the sender domain and production event access, then confirm that sending is enabled before producing a fresh qualifying event through your product.
Use a recipient you control. Check the recorded delivery result and open the received message to inspect the sender and destination link. A provider's delivery status describes delivery to the receiving mail system; inspect the mailbox too when checking placement.
The setup instructions require the fresh proof to reach delivered. If it is still pending or failed, report that state and its cause. A completed configuration screen isn't a substitute.
How do you verify that reminders stop?
Exercise the completion cases as well as the send case. For the proposed site-publishing journey, use this acceptance table:
| Case | Result to verify |
|---|---|
| User creates a site and leaves it unfinished | One eligible reminder after the approved delay and sending rules |
| User publishes before the delay ends | No unfinished-site reminder |
| User publishes while a reminder waits for the sending window | The completed user receives no stale reminder |
| The same event is retried | No second reminder caused by that retry |
| The user refuses marketing email | No marketing reminder |
Run these in an isolated test setup and record which cases passed. If the environment cannot exercise a case, keep it listed as unverified instead of inferring a pass.
Ask the agent to finish with evidence for the events it verified and the delivery result. Record the approved play revision alongside any remaining owner action. The maintained barua setup guide is the starting point for that work.