Alvera Platform — Guided Setup

1. Resolve the alvera prefix — references/bootstrap.md → "Step 0". Try alvera --version, then npx -p @alvera-ai/platform-sdk alvera --version. Pin whichever works. If both fail, hand the user npm install -g @alvera-ai/platform-sdk and stop.
2. Bootstrap the session — references/bootstrap.md. Confirm the user has run alvera login themselves; verify with alvera whoami + alvera ping; pick the target datalake via alvera datalakes list.
3. Open the resource loop — ask what the user wants to set up, and always list the options inline. Example: "What's next? You can set up a data source, tool, action status updater, AI agent, connected app, agentic workflow, interop contract, or data activation client. For a custom dataset / generic table from a sample file → custom-dataset-creation skill. For a production-grade workflow with templates and dry-run testing → agentic-workflow-creation skill." Repeat the option list every time you return to the loop (after each successful create or skip) — don't assume the user remembers.
4. Per resource:
   • List first to detect collisions (alvera <resource> list ...).
   • Elicit fields per references/resources.md. Enum lists there are hints to guide the conversation, not authoritative — the CLI/API is the source of truth.
   • Summarise in plain language for explicit confirmation — a compact bulleted recap of the fields, not a JSON dump. Raw JSON belongs in the tempfile that goes to --body-file, not in chat. Example: "Creating data source prime-emr-source (uri our-emr:prime-emr-source, status active, not default). Proceed?" Only fall back to a JSON-ish form when the user explicitly asks ("show me the JSON", "show the full body").
   • Call create via the CLI (references/cli-cheatsheet.md). Treat any non-zero exit / 4xx as an authoritative validation failure: surface the stderr verbatim, map it back to the offending field, and re-elicit only that field. Do not retry the same payload.
   • Append to infra.yaml if the receipt is enabled (references/yaml-receipt.md) — only after a successful (2xx) create.
5. Loop until the user is done.

Stance: be proactive

Assume the user wants to do the positive action. Default to the forward path and ask for a yes/no confirmation — don't present long option menus when one answer is clearly what they want. For example:

• Datalake exists → "Use prime-health? Or create a new one?" (not "what do you want to do with datalakes?")
• Data source fields collected → "Creating Acme EMR. Proceed?" (not "would you like to create this, or review, or skip?")
• Auth missing → present both auth paths inline (interactive + VM/token), don't interrogate what kind of terminal they have first.

When the user agrees, move immediately — don't re-confirm.

Hard constraints

Read these before any user interaction:

• references/scope.md — what is in/out of scope, with refusal language.
• references/guardrails.md — non-negotiable rules: no silent upsert, destructive confirmations, secrets handling, dependency ordering, read-before-write for updates.

CLI

This skill drives the alvera CLI shipped by @alvera-ai/platform-sdk (>= 0.2.0). Two equivalent invocation forms — pick one and stay consistent in the conversation:

# Zero-install (preferred — no project pollution)
npx -p @alvera-ai/platform-sdk alvera <command>

# Or install globally once
npm install -g @alvera-ai/platform-sdk
alvera <command>

All examples in the references use the bare alvera <command> form for readability. Substitute the npx -p ... prefix at run time.

The CLI exits non-zero on any API error. Surface stderr verbatim — no fallbacks, no swallowing. Output is pretty JSON on stdout; status messages and prompts go to stderr, so responses stay pipeable.

Auth is session-based and stored AWS-CLI-style under ~/.alvera-ai/:

• ~/.alvera-ai/config — base URL, default tenant, email per profile
• ~/.alvera-ai/credentials — session token + expires_at (mode 0600)

The user runs alvera login once in their own shell. The skill never collects the password and never invokes login itself.

References

• references/scope.md — allowed/refused operations
• references/bootstrap.md — first-turn questions and connectivity checks
• references/guardrails.md — non-negotiable rules
• references/resources.md — per-resource field elicitation rules
• references/yaml-receipt.md — emitted YAML schema and rules
• references/cli-cheatsheet.md — CLI command surface
• references/example-transcript.md — reference end-to-end conversation