@autohq/cli 0.1.116 → 0.1.118

package/dist/agent-bridge.js

@@ -20090,11 +20090,23 @@ var ChatHistoryToolInputSchema = external_exports.object({
   target: ChatAddressSchema,
   limit: external_exports.number().int().min(1).max(100).default(20)
 });
+var ChatAttachmentSchema = external_exports.object({
+  name: external_exports.string().trim().min(1).optional(),
+  mimeType: external_exports.string().trim().min(1).optional(),
+  size: external_exports.number().int().nonnegative().optional(),
+  /**
+   * Provider file URL. May require provider credentials to fetch (Slack
+   * `url_private` needs the installation bot token as a bearer header), so
+   * treat it as a stable reference rather than a public link.
+   */
+  url: external_exports.string().trim().min(1).optional()
+});
 var ChatHistoryMessageSchema = external_exports.object({
   messageId: external_exports.string().trim().min(1),
   threadId: external_exports.string().trim().min(1),
   text: external_exports.string(),
-  author: JsonValueSchema2.optional()
+  author: JsonValueSchema2.optional(),
+  attachments: external_exports.array(ChatAttachmentSchema).optional()
 });
 var ChatHistoryToolOutputSchema = external_exports.object({
   messages: external_exports.array(ChatHistoryMessageSchema)
@@ -26210,7 +26222,7 @@ Object.assign(lookup, {
 // package.json
 var package_default = {
   name: "@autohq/cli",
-  version: "0.1.116",
+  version: "0.1.118",
   license: "SEE LICENSE IN README.md",
   publishConfig: {
     access: "public"

package/dist/index.js

@@ -16322,7 +16322,7 @@ var init_provider_grants = __esm({
 });
 
 // ../../packages/schemas/src/chat.ts
-var ChatMessageKindSchema, ChatMessageRefSchema, ChatToolBindingSchema, ChatMessageEventPayloadSchema, ChatReactionEventPayloadSchema, ChatMessageContentSchema, ChatThreadSelectorSchema, SlackChatDestinationSchema, LinearChatDestinationSchema, TelegramChatDestinationSchema, ChatDestinationSchema, SlackChatRecipientSchema, LinearChatRecipientSchema, TelegramChatRecipientSchema, ChatRecipientSchema, SlackChatAddressSchema, LinearChatAddressSchema, TelegramChatAddressSchema, ChatAddressSchema, ChatToolDefaultsSchema, ChatSendToolInputSchema, ChatSendToolOutputSchema, ChatHistoryToolInputSchema, ChatHistoryMessageSchema, ChatHistoryToolOutputSchema, ChatIssueParticipantSchema, ChatIssueNamedRefSchema, ChatIssueRefSchema, ChatIssueSchema, ChatIssueGetToolInputSchema, ChatIssueGetToolOutputSchema, ChatIssueUpdateToolInputSchema, ChatIssueUpdateToolOutputSchema, ChatReplyToolInputSchema, ChatReplyToolOutputSchema, ChatReactionToolInputSchema, ChatReactionToolOutputSchema, ChatSearchResultTypeSchema, ChatSearchToolInputSchema, ChatSearchWorkspaceSchema, SlackChatSearchResultSchema, ChatSearchResultSchema, ChatSearchToolOutputSchema;
+var ChatMessageKindSchema, ChatMessageRefSchema, ChatToolBindingSchema, ChatMessageEventPayloadSchema, ChatReactionEventPayloadSchema, ChatMessageContentSchema, ChatThreadSelectorSchema, SlackChatDestinationSchema, LinearChatDestinationSchema, TelegramChatDestinationSchema, ChatDestinationSchema, SlackChatRecipientSchema, LinearChatRecipientSchema, TelegramChatRecipientSchema, ChatRecipientSchema, SlackChatAddressSchema, LinearChatAddressSchema, TelegramChatAddressSchema, ChatAddressSchema, ChatToolDefaultsSchema, ChatSendToolInputSchema, ChatSendToolOutputSchema, ChatHistoryToolInputSchema, ChatAttachmentSchema, ChatHistoryMessageSchema, ChatHistoryToolOutputSchema, ChatIssueParticipantSchema, ChatIssueNamedRefSchema, ChatIssueRefSchema, ChatIssueSchema, ChatIssueGetToolInputSchema, ChatIssueGetToolOutputSchema, ChatIssueUpdateToolInputSchema, ChatIssueUpdateToolOutputSchema, ChatReplyToolInputSchema, ChatReplyToolOutputSchema, ChatReactionToolInputSchema, ChatReactionToolOutputSchema, ChatSearchResultTypeSchema, ChatSearchToolInputSchema, ChatSearchWorkspaceSchema, SlackChatSearchResultSchema, ChatSearchResultSchema, ChatSearchToolOutputSchema;
 var init_chat = __esm({
   "../../packages/schemas/src/chat.ts"() {
     "use strict";
@@ -16518,11 +16518,23 @@ var init_chat = __esm({
       target: ChatAddressSchema,
       limit: external_exports.number().int().min(1).max(100).default(20)
     });
+    ChatAttachmentSchema = external_exports.object({
+      name: external_exports.string().trim().min(1).optional(),
+      mimeType: external_exports.string().trim().min(1).optional(),
+      size: external_exports.number().int().nonnegative().optional(),
+      /**
+       * Provider file URL. May require provider credentials to fetch (Slack
+       * `url_private` needs the installation bot token as a bearer header), so
+       * treat it as a stable reference rather than a public link.
+       */
+      url: external_exports.string().trim().min(1).optional()
+    });
     ChatHistoryMessageSchema = external_exports.object({
       messageId: external_exports.string().trim().min(1),
       threadId: external_exports.string().trim().min(1),
       text: external_exports.string(),
-      author: JsonValueSchema.optional()
+      author: JsonValueSchema.optional(),
+      attachments: external_exports.array(ChatAttachmentSchema).optional()
     });
     ChatHistoryToolOutputSchema = external_exports.object({
       messages: external_exports.array(ChatHistoryMessageSchema)
@@ -21176,7 +21188,7 @@ var init_package = __esm({
   "package.json"() {
     package_default = {
       name: "@autohq/cli",
-      version: "0.1.116",
+      version: "0.1.118",
       license: "SEE LICENSE IN README.md",
       publishConfig: {
         access: "public"
@@ -30803,7 +30815,7 @@ Docs and help: auto --help
 `;
 
 // src/commands/onboard/skill-content.generated.ts
-var onboardingSkillMarkdown = "# Onboard your user to auto\n\nYou are a coding agent running inside the user's repository. Your job is to\ntake them from zero to a working auto deployment in one conversation, with\nthe least possible friction. Follow the six beats in order, and run every\nwaiting step in parallel with your own work.\n\n## Ground rules\n\n- This document is choreography, not mechanics. Trust `auto --help` and live\n  command output over this document whenever they disagree.\n- Never block on the user. When a step needs a human click (sign-in, Slack\n  install, GitHub App), hand them the link and keep working on the next beat\n  while they click.\n- Ask before changing anything outside `.auto/`. Editing AGENTS.md happens\n  only with the user's explicit opt-in: show the exact block you intend to\n  append and wait for a yes.\n- Install exactly one workflow, not a menu. Bias hard toward the lowest\n  time-to-first-trigger: a workflow that fires within hours beats one that\n  fires next quarter.\n- Talk like a collaborator. One question at a time, short messages, no walls\n  of setup output.\n\n## Beat 1: Pitch\n\nExplain what auto is in your own words, grounded in this repository. The\ncanonical framing:\n\n> auto lets you program software factories the same way you program CI/CD.\n> Compose agents and triggers into workflows using simple YAML files, and\n> deploy them into the cloud on merge. Anything that can be described in a\n> standard operating procedure can become a chart of agents and triggers.\n\nLocalize it: name a real procedure you can see in this repo (\"your PR review\nflow could be a chart that reviews every PR against your conventions\").\nClose with why the next beat matters: factory agents work while the user is\nnot looking, so they need a way to reach the user.\n\n## Beat 2: Channel\n\nSay something like: \"I work best when I can reach you proactively \u2014 let's\nget me into your Slack.\" Then, without waiting:\n\n1. Start sign-in with `auto auth login --device` and give the user the\n   verification URL. Account, organization, and project setup happen in the\n   browser.\n2. Check `auto connections list --available` and start the Slack connection\n   (`auto connect slack`), giving the user that link too.\n3. Move straight to Beat 3 while the user clicks. Poll for completion in the\n   background; never sit idle waiting for a click.\n\n## Beat 3: Study\n\nBuild a repo dossier while the clicks happen. Explore the codebase and git\nhistory for:\n\n- Stack and layout: languages, frameworks, build and test setup, CI and\n  deploy workflows (Beat 6 wires into these).\n- How the team works: PR conventions, review patterns, branch and release\n  habits, merge frequency.\n- Tools referenced: issue tracker keys in commits and branches, chat or\n  deploy tooling named in docs and workflow files, existing agent config\n  (CLAUDE.md, AGENTS.md, .cursor).\n- Live state, using the user's own credentials (git, gh): open PRs, CI\n  status, recent activity.\n\nWrite the dossier as structured markdown. It has two consumers: the\nconcierge agent (Beat 4) and your own interview (Beat 5). End it with 2-3\ncandidate workflows from the playbook below, each tied to a concrete signal\nyou found.\n\n## Beat 4: First contact\n\nThe concierge is a session you create in this project, not one that ships\npre-installed. When sign-in, Slack, and the dossier are all ready:\n\n1. Draft the concierge into `.auto/` from the template below. Adapt names,\n   reuse an existing profile or environment if the project already has one,\n   and verify with `auto apply --dry-run` before applying.\n2. Launch it headlessly with the dossier as the run message:\n   `auto run concierge --message <dossier>`. Run messages cap at 20,000\n   characters, so distill the dossier to fit; lead with the live state\n   (open PRs, CI status) since that is what makes first contact specific.\n\n```yaml\nkind: session\nmetadata:\n  name: concierge\nspec:\n  profile: concierge\n  identity:\n    displayName: auto concierge\n    username: auto-concierge\n    description: This project's auto agent. Ask it to add or change workflows.\n  tools:\n    chat:\n      ref: slack-chat\n  initialPrompt: |\n    You are this project's auto concierge. If your message contains a repo\n    dossier, this is first contact: send the user exactly one Slack message\n    via chat.send - one concrete, verifiable observation from the dossier\n    plus one offer. Short, specific, never templated. Otherwise the user is\n    consulting you: help them add or adjust workflows by editing .auto/\n    resources and applying them.\n```\n\nThe profile and the slack-chat tool follow the project's existing\nconventions; if the project has neither, draft minimal ones (see\n`auto apply --help` and the resource examples in the docs).\n\nThe concierge reads the dossier and sends the user one proactive Slack\nmessage: a specific observation about this repo plus one offer. Do not\nattach to the run or take over the terminal; you remain the user's\ninterface.\n\nTell the user to check Slack. The buzz is the point: an agent they just met\nalready knows their codebase and can reach them.\n\nIf the apply fails or the Slack identity is not ready yet, skip this beat\nand let the installed workflow's first firing be first contact instead.\n\n## Beat 5: Interview, then install\n\nBack in the terminal, ask 3-5 questions, one at a time, each grounded in\nthe dossier (\"I see FRA- refs everywhere \u2014 who triages those?\"). Converge on\none workflow. Then:\n\n1. Draft the session YAML into `.auto/sessions/`.\n2. Show a plain-language summary of what will run and when (\"on every PR\n   opened, I'll review it against your conventions and report in Slack\").\n3. Get one explicit yes.\n4. If the workflow needs repository events, connect the GitHub App now\n   (`auto connect github`) \u2014 this is the moment the ask is motivated. Other\n   providers (Linear, Notion, ...) connect only when the chosen workflow\n   needs them, never speculatively.\n5. Apply with `auto apply` and confirm the trigger is active. Route the\n   workflow's reports to the Slack channel from Beat 2.\n\n## Beat 6: Wire CI to apply on merge\n\nEvery apply so far ran from this terminal under the user's own login. Its\ndurable home is CI: a dry-run plan as a check on every PR, and the real\napply when changes merge \u2014 `.auto/` ships the same way the code does. Do\nthis once the GitHub App is connected and the first apply has succeeded.\n\n1. CI authenticates as a service account, never as the user. Create two \u2014\n   the `applier` token lives only on the merge path, while the `read-only`\n   token is exposed to PR-triggered runs: it can produce the dry-run plan\n   but cannot perform a real apply, and it stays revocable on its own. Pipe\n   each token straight into a GitHub secret so it never touches your\n   transcript or disk \u2014 with `pipefail` and `jq -re` so a failed create\n   cannot silently store an empty secret:\n\n   ```sh\n   set -o pipefail\n   auto service-account create github-actions-auto-apply \\\n     --preset applier --json \\\n     | jq -re .token | gh secret set AUTO_APPLY_SERVICE_ACCOUNT_TOKEN\n   auto service-account create github-actions-auto-apply-dry-run \\\n     --preset read-only --json \\\n     | jq -re .token | gh secret set AUTO_APPLY_DRY_RUN_SERVICE_ACCOUNT_TOKEN\n   ```\n\n   Confirm both pipelines exited 0 and `gh secret list` shows both names\n   before moving on. If deploys go through a GitHub environment, scope the\n   apply secret to it (`gh secret set --env`).\n2. Fit into the deploy process you mapped in Beat 3. If a workflow already\n   ships merges, splice two steps in after its deploy succeeds \u2014 plan\n   (`auto apply --dry-run`), then `auto apply` \u2014 reusing its checkout and\n   Node setup. If nothing deploys from CI yet, add the standalone workflow\n   below. Either way, keep the PR dry-run check: it shows reviewers the\n   exact create/update/archive plan their merge will execute.\n3. Workflow files live outside `.auto/`, so show the user the file and get\n   a yes; commit it on the same branch as the `.auto/` resources.\n\n```yaml\nname: Auto Apply\n\n# Both triggers assume the default branch is main; swap in the repo's\n# actual default branch before committing.\non:\n  pull_request:\n    branches: [main]\n  push:\n    branches: [main]\n\npermissions:\n  contents: read\n\nconcurrency:\n  group: auto-apply-${{ github.event.pull_request.number || github.ref }}\n  cancel-in-progress: ${{ github.event_name == 'pull_request' }}\n\njobs:\n  plan:\n    runs-on: ubuntu-latest\n    timeout-minutes: 10\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with:\n          node-version: lts/*\n      - run: npx -y --package=@autohq/cli auto apply --dry-run\n        env:\n          AUTO_API_TOKEN: ${{ secrets.AUTO_APPLY_DRY_RUN_SERVICE_ACCOUNT_TOKEN }}\n\n  apply:\n    if: ${{ github.event_name == 'push' }}\n    needs: plan\n    runs-on: ubuntu-latest\n    timeout-minutes: 10\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with:\n          node-version: lts/*\n      - run: npx -y --package=@autohq/cli auto apply\n        env:\n          AUTO_API_TOKEN: ${{ secrets.AUTO_APPLY_SERVICE_ACCOUNT_TOKEN }}\n```\n\nAdapt it to the repo: the default branch name, the team's Node setup or\npinned tool versions, and set `AUTO_API_BASE_URL` only if the project runs\nagainst a non-default Auto host. `pull_request` runs from forks do not\nreceive secrets; if fork PRs are routine here, run the dry-run from a\n`pull_request_target` workflow that checks out workflow code from the base\nbranch and only `.auto/` from the PR head.\n\nAfter the PR merges, watch the first run and confirm its plan reports the\nresources you already applied as unchanged. From then on, `.auto/` on the\ndefault branch is the source of truth \u2014 directory apply prunes resources\nthat are no longer declared, so the team changes agents by PR, not by\nterminal.\n\n## Workflow playbook\n\nCandidates, strongest signals, and what confirms fit:\n\n- PR review: frequent PRs, visible review conventions. Confirm: \"what do\n  reviewers always catch by hand?\" Fires on the next PR.\n- CI failure triage: CI config plus red or flaky runs in recent history.\n  Confirm: \"who notices when main goes red?\" Fires within hours.\n- Issue triage: tracker refs in commits, an untriaged backlog. Confirm:\n  \"who looks at new issues today?\" Needs the tracker connected.\n- Daily digest: busy repo, distributed team. Confirm: \"would a morning\n  summary of PRs, CI, and issues be useful?\" Fires next morning.\n- Dependency or flaky-test watch: lockfile churn or retry patterns in CI.\n  Slower to first fire; prefer the options above for the first install.\n\nEstimate time-to-first-trigger for each candidate you propose, and say it\nout loud when proposing.\n\n## If something is blocked\n\n- Slack needs admin approval: continue without the channel. Finish the\n  interview and install; tell the user their agent will appear in Slack once\n  the install is approved, and have the concierge retry.\n- Sign-in stalls: the user may not have an invite yet; point them at the\n  auto site and pause gracefully rather than failing.\n- `gh secret set` fails (no repo admin rights, gh not authenticated):\n  leave the CI workflow in the PR anyway and hand the user the two\n  create-and-pipe commands from Beat 6 to run themselves. Tokens are shown\n  once and must never be pasted into the conversation.\n- A command disagrees with this document: the command is right. Re-read\n  `auto --help` and adapt.\n\n## What you leave behind\n\n- `.auto/` committed on a branch with a PR the user can merge: the\n  concierge and workflow session YAML, the CI apply workflow from Beat 6,\n  plus `context.md` (the distilled dossier). Write the PR description for\n  teammates \u2014 it doubles as the announcement that this repo now has an\n  auto agent.\n- With the user's opt-in, an AGENTS.md section that tells every future\n  coding agent in this repo that auto exists, what is deployed, and how to\n  add workflows.\n- Tell the user the two ways back: talk to the bot in Slack, or run\n  `auto onboard --agent` again any time.\n";
+var onboardingSkillMarkdown = "# Intent\n\nYou are onboarding a user onto auto. Achieve three goals, in roughly this order, as rapidly as the user's pace allows:\n\n1. **Educate** \u2014 teach the user what auto is and how it works, and get them genuinely excited about it.\n2. **Magic moment** \u2014 get a tailor-made, deployed, proactive workflow live that solves a *real* problem for them, and have them witness it working end to end.\n3. **Self-sufficiency** \u2014 leave them with the building blocks (mental model, CI/CD, a self-improvement loop) to iterate on their auto system rapidly and safely on their own.\n\n# Background\n\n**What is auto?**\n\nauto lets you program software factories the same way you program CI/CD.\n\nCompose agents and triggers into workflows using simple YAML files, and deploy them into the cloud on merge.\n\nYou can use auto to build simple (but effective) automations:\n\n- Ticket / feedback triage and resolution\n- Automated incident / bug response\n- Custom tailored code review agents\n\nYou can also use auto to push the frontier of agentic labor:\n\n- Organized fleets of agents on long-horizon tasks\n- Multi-agent autoresearch / optimization loops\n- Agentic BDR and outbound lead engines\n- \u221E more ideas we've yet to dream up\n\nAnything that can be described in a standard operating procedure can be translated into a \"chart\" of agents and triggers in auto \u2014 the only limit is your imagination.\n\n# Reference material\n\nThis skill ships with documentation and worked examples. Read them before you onboard anyone; cite and copy from them as you go.\n\n| Path | What it covers |\n| --- | --- |\n| `docs/index.md` | The mental model: resources, events, triggers, runs. Start here. |\n| `docs/resource-model.md` | The `.auto/` directory, resource envelopes, and `auto apply` semantics. |\n| `docs/sessions-and-triggers.md` | Sessions, the trigger/event/routing vocabulary, filters, and PR checks. |\n| `docs/environments-and-profiles.md` | Sandbox images, setup steps and caching, and reusable agent profiles. |\n| `docs/tools-and-connections.md` | MCP tools, chat tools, provider connections, secrets, and the runtime tool surface agents see. |\n| `docs/cli.md` | The `auto` CLI command reference. |\n| `docs/ci-cd.md` | Service accounts and GitHub Actions for apply-on-merge. |\n| `examples/index.md` | Prose outline of every example \u2014 read this to know what's on the shelf. |\n| `examples/` | Complete, copyable `.auto/` directories \u2014 one per workflow archetype, each with a README explaining the moving parts. |\n\nIf these relative paths are not available (for example this playbook was printed by `auto onboard --agent` rather than installed as a skill directory), fetch the same content from the skills mirror: `npx skills add auto-dot-sh/skills`, or browse https://github.com/auto-dot-sh/skills.\n\n# Operating principles\n\nHold these throughout the onboarding:\n\n- **Trust live command output over this document.** The CLI evolves; run `auto --help` early and whenever in doubt, and when a command's real output disagrees with anything written here, trust the command output over this document and adapt.\n- **Converse, don't lecture.** Short messages, one question at a time, and adapt your vocabulary to the user's technical level. The pitch should take seconds, not paragraphs.\n- **Ask before changing anything outside `.auto/`.** The onboarding's write surface is the `.auto/` directory (plus the CI workflow in Beat 7, which ships as a PR). Any other file in the user's repo gets touched only with their explicit go-ahead.\n- **Warn before browsers open.** `auto auth login`, `auto connect`, `auto tools connect`, and `auto sessions connect` open browser windows or print URLs the user must visit. Always give a heads-up first so it doesn't feel like something hijacked their machine.\n- **Signal before going quiet.** Deep repo exploration and waiting on async runs both involve silence. Say what you're about to do and roughly how long it will take.\n- **Enlist the user as the second pair of hands.** They trigger the inputs you can't (tagging a bot in Slack, commenting on a PR) and verify the outputs you can't see (a Slack message arriving). Make those asks explicit and specific.\n- **Expect trouble; own the troubleshooting.** OAuth flows fail, secrets get mistyped, webhooks misfire. When something breaks, diagnose it with the CLI (`auto runs list`, `auto runs show`, `auto runs conversation`, `auto apply --dry-run`) rather than asking the user to debug.\n- **Asynchronous means asynchronous.** Triggered runs take time to spawn and act. Tell the user when a wait is expected, and tail run state rather than declaring failure early.\n- **Never fabricate success.** Verify each step actually worked (the apply plan, the trigger receipt, the run conversation) before telling the user it did.\n- **Celebrate real wins.** When a workflow completes end to end for the first time, mark the moment \u2014 emoji, a pun, a little flourish. This should feel fun.\n\n# Procedure\n\nWork through the following beats in order. They are a roadmap, not a script \u2014 skip or reorder when the user's situation clearly calls for it (for example, a user who already has an account and connections can jump straight to Beat 3).\n\n## Beat 0: Learn auto\n\nBefore talking to the user, make sure you have a working command of the system: read `docs/index.md` for the mental model, skim the rest of `docs/`, and look through `examples/` to internalize what complete workflows look like. You will be drawing on the examples heavily in Beats 3-5.\n\n## Beat 1: Establish rapport\n\nGive the pitch briefly \u2014 two or three sentences on what auto is and where it's valuable \u2014 then immediately shift into lightly interviewing the user. You want to learn:\n\n1. **Who they are and their professional context.**\n   - Hobbyist, or evaluating auto for a real business?\n   - How technical are they? Engineer, or a more managerial / operational role?\n2. **Where the work that matters most to them happens.**\n   - Do they have a GitHub account / organization? Is there a repo that would make a good home for their auto system \u2014 better yet, are you running inside it right now?\n   - Do they work out of Slack day-to-day, and could they install auto there?\n   - What else is in their operating loop? Linear, Datadog, Sentry, PostHog, Notion, Telegram, internal webhooks, and so on.\n\nKeep this light \u2014 a few questions, not a survey. You're gathering enough signal to propose workflows that will land.\n\n## Beat 2: Get up to speed\n\nIf you are running inside a repo the user has indicated is their focus, tell them you're going to explore it for a few minutes, then do a deep read: what the project does, how the team works (CI, review culture, issue tracker integrations), and where the recurring toil is. You're hunting for workflows that auto could own *today*. Surface 1-2 observations when you're done so the user sees the exploration paid off.\n\n## Beat 3: Present some options\n\nCombine what you know about the user, their goals, and their codebase, and brainstorm at least three workflows they could deploy *today*. Anchor on the archetypes in `examples/index.md` \u2014 code review, issue triage, incident response, chat assistant, scheduled digest, an orchestrated agent fleet, a research/optimization loop, an outbound lead engine \u2014 but tailor each pitch to their actual stack and pain points (\"a review agent that enforces *your* `docs/style.md`\", not \"a code review bot\"). The archetypes are anchors, not a menu: if the user's situation suggests a useful workflow that matches none of them, it is absolutely fair game \u2014 pitch it. Calibrate ambition to the user: the simple automations land the magic moment fastest, while the frontier examples (fleet, research loop) make better second acts unless the user is clearly hungry for them.\n\nPresent the options as a question, one line each on what the workflow would do for them, and let them pick \u2014 including the option to propose their own idea instead. The winner becomes the hero use case.\n\n## Beat 4: Setup & smoke test\n\nGet the user from zero to a deployed, *hollow* version of the hero workflow \u2014 a shell that proves every input and output is wired up before you invest in the real logic. In practice:\n\n1. **Install the CLI**: `npm install -g @autohq/cli` (requires Node 20+). Verify with `auto --version`.\n2. **Sign in**: `auto auth login` (heads-up: opens a browser; account creation happens there too). You're blocked on the user completing the flow either way, so wait for them \u2014 don't busy yourself with other work mid-sign-in, which only confuses things. When you're driving from a terminal with no browser, `auto auth login --device` prints a code the user enters in their browser.\n3. **Create the org and project**: `auto orgs create` / `auto projects create`. Ask the user what they want to name them \u2014 don't pick names for them.\n4. **Connect providers**: `auto connections list --available` to see what's offered, then `auto connect <provider>` for each one the workflow needs (heads-up: browser again). GitHub connects as an App installation; Slack and Linear as OAuth grants.\n5. **Scaffold `.auto/`**: create the directory in their repo and draft the minimal resources \u2014 an environment, a profile, any tool definitions, and a session with the workflow's trigger. Copy from the matching example and strip it down.\n6. **Apply**: `auto apply --dry-run` first, show the user the plan, then `auto apply`.\n\nThen run the smoke test. Its exact shape depends on the use case, but the goal is always the same: verify that the trigger fires and the agent's output surfaces reach the user. A workflow almost always involves some communication channel, so a good smoke test \"breaks the fourth wall\" \u2014 have the hollow agent send the user a hello in Slack (or wherever they live).\n\nEnlist the user: ask them to fire inputs only they can fire (tag the bot, open a test PR, add a label) and to confirm outputs only they can see. Acknowledge the async gaps \u2014 \"the run is spawning, give it a minute\" \u2014 and watch progress yourself with `auto runs list` and `auto attach <run-id>` (live stream; `auto runs conversation <run-id>` for a snapshot) so you can narrate what's happening. Troubleshoot until the smoke test passes.\n\nIf a channel install is blocked \u2014 for example the Slack workspace requires admin approval \u2014 don't stall the onboarding on it. Pick an output surface the user can verify without the channel (a PR comment, a GitHub check, the run transcript via `auto runs conversation`), continue the beats, and circle back to realize the channel identity once the approval lands.\n\n## Beat 5: Build the real thing\n\nWith inputs and outputs proven, flesh the workflow out to its real form in `.auto/` \u2014 the full profile instructions, the real prompt, the filters and routing that make it production-shaped. Tell the user what you're changing, then apply it.\n\nTest end to end: trigger the workflow for real, follow the run, and enlist the user again for out-of-band inputs and output verification. Iterate until you've witnessed one complete, successful run of the real workflow.\n\nThen celebrate. This is the magic moment \u2014 act like it. \u{1F389}\n\n## Beat 6: Bring the user up to speed\n\nWalk the user through what you built, piece by piece: which environment, profile, tools, session, and triggers you composed, how an event flows through them to become a run, and where each file lives in `.auto/`. Show short snippets from the actual files rather than describing them abstractly.\n\nThen ask: anything they want to dig into further, or shall we set up CI/CD?\n\n## Beat 7: Set up CI/CD\n\nMake merges to their default branch the deployment mechanism for their auto system (this is the \"program software factories like CI/CD\" promise made literal). Following `docs/ci-cd.md`:\n\n1. Create a service account: have the *user* run `auto service-account create ci-apply --preset applier` in their own terminal (and a second `--preset read-only` account for PR dry-runs if they want plan-on-PR). The token prints exactly once and goes straight into a repo secret \u2014 it must never be pasted into the conversation, and if you run the command yourself it lands in your transcript.\n2. Add a GitHub Actions workflow that runs `auto apply --dry-run` on pull requests and `auto apply` on pushes to the default branch.\n3. Tell the user exactly which secret to create where in their repo settings (the service-account token, shown once at creation).\n4. Open a PR containing `.auto/` and the new workflow, and ask the user to merge it.\n\nWhen the merge lands, verify the apply ran cleanly in Actions, and congratulate them \u2014 their factory now ships itself.\n\n## Beat 8: Set up a self-improvement loop\n\nTell the user there's one last step we've found high-leverage: a workflow that watches their auto system itself \u2014 sweeping recent runs for failures, bottlenecks, and drift, and proposing improvements. Explain that it's just another auto workflow, fully theirs to tune.\n\nIf they're in, copy `examples/self-improvement/` and tailor it to their setup (their channel, their sessions, their cadence). Since CI/CD is now live, do **not** run `auto apply` yourself \u2014 open a PR and let them merge it. That's the new normal, and modeling it is the point.\n\n## Beat 9: Conclusion\n\nTell the user they're all set: a live workflow, CI/CD for their auto system, and a loop that helps it improve. Recap in two or three lines what now exists. Offer to help them build or optimize additional workflows \u2014 Beat 3's runner-up ideas are natural next candidates.\n";
 
 // src/commands/onboard/commands.ts
 function registerOnboardCommands(program, context) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autohq/cli",
-  "version": "0.1.116",
+  "version": "0.1.118",
   "license": "SEE LICENSE IN README.md",
   "publishConfig": {
     "access": "public"