Sign up to create a workspace, or use the owner procedure after explicitly accepting current terms. New workspaces start paused. Browser onboarding opens agent access for that workspace, then hands a tailored prompt to your coding agent. The agent guides the rest.
New onboarding connections use a project-based name. All permissions start selected with full delegation. Change these under More permissions and review choices before creating access. Existing grants are unchanged. Copy the prompt, then choose Continue to workspace. Skip for now opens the workspace without completing setup or changing access.
Start with one custom event or a test email to yourself. A broader setup review is recommended, but optional.
Connect the agent first
Install the skill in the product repository:
npx skills add getbarua/skills --skill barua-setup
Set BARUA_SKILL to the installed skill directory, for example $PWD/.agents/skills/barua-setup. Read its SKILL.md task router, then only the complete sections for your chosen task. The installation reference covers portable fallback and helper dependencies. No particular model or native tool names are required.
Authorize scoped management access and choose a private key destination. You do not need an existing key file. Never put credentials in the setup prompt. Set BARUA_MANAGEMENT_KEY privately and BARUA_WORKSPACE_ID to the selected UUID, then run:
node "$BARUA_SKILL/scripts/manage.mjs" capabilities
node "$BARUA_SKILL/scripts/manage.mjs" setup
Confirm connection.tenant_id matches that UUID and inspect the allowed actions. A grant controls Barua only. The agent should discover its repo, hosting, DNS, database and browser access, then ask about missing access only when needed.
Reach the first sample
Choose a forwarded email design or a brand sample. With an explicit test:send grant, the agent can prepare an owner-only sample using Barua's sender before customer DNS or server events. Mailbox confirmation and sample sending are separate actions. The sample never enables customer email.
After each milestone, the agent recommends one relevant next task and explains why. It respects completed, skipped or deferred steps and continues authorized work. It reports when required setup is verified complete. Pixel setup and imports remain optional.
Add custom events
Start with one event or any chosen set, up to 100 custom event types per workspace. Name what you need, such as report_exported. Your agent can define its properties, add it to your existing plan and test it through your product's server. Follow Start with one event for the schema and commands. Existing events and pending work must be preserved.
This works in a new workspace without a complete journey map or independent review. Test events validate data and send no email. The owner sample is a separate test; it does not prove the event triggered an automated email.
For customer automation, configure a Play under your existing permissions. Custom-event Plays currently follow the person's latest occurrence and marketing rules. They do not guarantee a separate email for every occurrence. The built-in receipt and order updates have separate service-email behavior.
Optional broader setup review
When you want a complete email strategy, ask your agent to follow the journey reference. It creates a local HTML plan and matching JSON. You choose the scope and review workflow. Customer sending retains its own approval and sender requirements.
Verify the result
For one event or sample, report its actual result and any relevant pending action. A full review package is optional for this path. Only a delivery confirmation establishes that mail was delivered. Customer activation uses the separate fresh-event proof; historical imports and duplicate events cannot prove live deployment.
If work stops, use Recover a blocked task and resume the saved operation.