# Set up barua You are helping someone set up lifecycle email for their product. Read their project and the current workspace state, then carry out the work their permissions allow. If setup has already started, resume it. ## 1. Load the setup skill Install the skill in the project: ```sh npx skills add getbarua/skills --skill barua-setup ``` Read the installed `SKILL.md` before making changes. If installation is unavailable, fetch [the public skill](https://barua.ai/skills/barua-setup/SKILL.md). Resolve its relative references against `https://barua.ai/skills/barua-setup/` and fetch the referenced files when needed. Download its helper scripts locally before running them. The skill is the detailed procedure. Its references and the API's current capabilities define the supported actions. This page helps you choose the starting point; it does not replace those instructions. ## 2. Understand the project Read the available repos and their agent instructions. Find the product's server and its deployment setup. Use the skill's repo-reading reference to locate the source of each product event. Check existing Barua integration code before adding another emitter. Infer a proposed setup from what the project establishes, including its site and sender identity. Keep inferred choices distinct from confirmed facts. Present the choices briefly and ask together for anything still missing, such as access to another repo or the intended sending domain. Reuse answers already supplied. Continue independent work while an answer is pending. An existing workspace keeps its data. Setting up or resuming Barua does not authorize a reset or deletion. Replacing another email service requires a separate request. If the user asks to bring past activity, follow the skill's history instructions with source access and an explicit history grant. Historical events cannot prove the live integration or start email plays. ## 3. Use the owner's chosen access Explain the key's purpose before asking the owner to save it. The agent connection creates a **management key** (`mk_…`), stored as `BARUA_MANAGEMENT_KEY` in the agent's secret store and loaded into its environment when running the management helper. It has no test or production mode. Its permissions apply to the real workspace; a fully delegated connection with launch permission can enable live events and sending once the setup requirements are met. Product events use separate `ik_…` keys, both named `BARUA_API_KEY` in their respective environments. Use the **test event key** in development and CI to validate events without creating people or sending email. Put the **live event key** in production hosting secrets for real product activity. Both event modes use the same prefix, so check the recorded mode rather than guessing from the key. Never substitute an event key for the management key. With `BARUA_MANAGEMENT_KEY` already available, read the skill's [management reference](https://barua.ai/skills/barua-setup/references/management.md). Run its helper's `capabilities` and `setup` commands to discover the connection's permissions and current work. Do not ask for another connection when this one is sufficient. Full delegation removes review checkpoints for the granted permissions. It does not establish launch permission; read the connection's actual grant before saying the agent can enable sending. Before creating a connection, establish the secure secret destination and a permitted way to save the key there. With authorized owner credentials, use the management helper's `connect` command, which reserves its destination before creating the connection. Otherwise direct the workspace owner to **Settings → Agents** in [the app](https://barua.ai/app/) and arrange for them to save the key. They choose the permitted changes and whether to review the plan, brand, plays or launch. Full delegation is available within those permissions. Never ask someone to paste a key into chat. Keep keys out of output and tracked files. If browser tools cannot transfer the management key securely, explain that it controls the real workspace, then ask the owner to save it as `BARUA_MANAGEMENT_KEY` in the chosen agent secret store and share only its location. Keep the key panel open until saving is confirmed. Load it without printing it and verify access with `capabilities`. **Access granted** means the permissions are saved; it does not prove that the helper has the key. Older screens may call this **Connected**. Continue independent repo work while the handoff is pending. If the key panel has disappeared and no saved key is available, the owner who created the connection can use **Save key again** on that connection in Settings → Agents. With authorized credentials for that owner, use the management helper's `recover-key --id ` with a secure destination. Both recover the same active key and preserve the connection's current permissions and pending work. Current terms are required. Check that the deployed app supports recovery before directing someone to it; if the button or endpoint is unavailable, report that limitation and arrange a secure replacement connection with the owner. Do not repeatedly ask for a key they cannot retrieve. Do not duplicate or revoke an existing connection without authorization. A missing recovery button alone does not prove the app is outdated. First check that the signed-in owner created the connection and its access is active. Then check that the terms are current. Resolve that condition before proposing replacement access. If only a test event key (`BARUA_API_KEY`) is available, follow the skill's event-only path and finish the work it permits. Report the remaining setup links accurately. If the user has no workspace yet, Barua is in early access: access starts with chris@barua.ai. You can still inspect the project while access is arranged. Terms acceptance stays with the owner. A permission grant does not establish a factual marketing permission statement; use only a statement the owner supplies or explicitly authorizes you to make. ## 4. Complete or resume setup Follow the skill for the selected access path. Read current state before changing it. Preserve completed work, reconcile the full event plan as instructed, and make requested updates without repeating satisfied setup steps. Start domain verification early. Use already authorized DNS and hosting tools, and continue event integration while DNS settles. If a required tool is unavailable, give the owner the exact records or action needed and continue independent work. Follow the current grant and review policy. For a checkpoint, report the exact operation awaiting approval and resume that operation after review. Recover retries through the same operation or idempotency key. Do not create a replacement request to get around review. Put live event keys in the production host's secret store using the skill's secure transfer helper. Check the readback from each setup action. Follow the skill's launch order before triggering the fresh event used for delivery proof. ## 5. Verify the result Exercise events through the product's real code and run the skill's event verification. With management access and permission to launch, complete its fresh delivery proof using an owner-controlled test recipient. Check that the proof reaches `delivered`. An accepted request or a completed checklist does not establish delivery. If a review or external action is pending, finish the independent work and report the exact continuation. Do not fabricate an event or send to customers just to pass a check. Event-only verification establishes event health; it cannot establish fresh provider delivery. End with the skill's required evidence report. Lead with what you verified and what remains. Use short, factual sentences and concrete results. Distinguish local changes, deployed integration, accepted mail and confirmed delivery. Name any owner action with its link or operation ID, and any unavailable tool with the action it would perform. Keep secrets out of the report.