@autohq/cli 0.1.90 → 0.1.92

package/dist/agent-bridge.js

@@ -22516,7 +22516,6 @@ var SessionRunDispatchCommandRecordSchema = external_exports.discriminatedUnion(
 var RuntimeRecordSchema = external_exports.object({
   id: RuntimeIdSchema2,
   sandboxId: external_exports.string().trim().min(1).nullable(),
-  gitAuthExpiresAt: external_exports.string().datetime().nullable(),
   createdAt: external_exports.string().datetime(),
   updatedAt: external_exports.string().datetime()
 });

package/dist/index.js

@@ -18363,7 +18363,6 @@ var init_runtimes = __esm({
     RuntimeRecordSchema = external_exports.object({
       id: RuntimeIdSchema2,
       sandboxId: external_exports.string().trim().min(1).nullable(),
-      gitAuthExpiresAt: external_exports.string().datetime().nullable(),
       createdAt: external_exports.string().datetime(),
       updatedAt: external_exports.string().datetime()
     });
@@ -21599,7 +21598,7 @@ var init_package = __esm({
   "package.json"() {
     package_default = {
       name: "@autohq/cli",
-      version: "0.1.90",
+      version: "0.1.92",
       license: "SEE LICENSE IN README.md",
       publishConfig: {
         access: "public"
@@ -21622,6 +21621,7 @@ var init_package = __esm({
         build: "tsup",
         dev: "tsx src/main.ts",
         "dev:tui": "node ../../scripts/cli-tui-dev-watch.mjs",
+        "skill:generate": "tsx scripts/generate-skill-content.ts",
         test: "npm run test:unit",
         "test:unit": 'tsx --test "test/**/*.unit.test.ts"',
         typecheck: "tsc --noEmit"
@@ -29880,286 +29880,7 @@ function acceptedInvitationLine(response) {
   ].join(" ");
 }
 
-// src/commands/onboard/skill-content.ts
-var onboardingSkillMarkdown = `# Onboard your user to auto
-
-You are a coding agent running inside the user's repository. Your job is to
-take them from zero to a working auto deployment in one conversation, with
-the least possible friction. Follow the six beats in order, and run every
-waiting step in parallel with your own work.
-
-## Ground rules
-
-- This document is choreography, not mechanics. Trust \`auto --help\` and live
-  command output over this document whenever they disagree.
-- Never block on the user. When a step needs a human click (sign-in, Slack
-  install, GitHub App), hand them the link and keep working on the next beat
-  while they click.
-- Ask before changing anything outside \`.auto/\`. Editing AGENTS.md happens
-  only with the user's explicit opt-in: show the exact block you intend to
-  append and wait for a yes.
-- Install exactly one workflow, not a menu. Bias hard toward the lowest
-  time-to-first-trigger: a workflow that fires within hours beats one that
-  fires next quarter.
-- Talk like a collaborator. One question at a time, short messages, no walls
-  of setup output.
-
-## Beat 1: Pitch
-
-Explain what auto is in your own words, grounded in this repository. The
-canonical framing:
-
-> auto lets you program software factories the same way you program CI/CD.
-> Compose agents and triggers into workflows using simple YAML files, and
-> deploy them into the cloud on merge. Anything that can be described in a
-> standard operating procedure can become a chart of agents and triggers.
-
-Localize it: name a real procedure you can see in this repo ("your PR review
-flow could be a chart that reviews every PR against your conventions").
-Close with why the next beat matters: factory agents work while the user is
-not looking, so they need a way to reach the user.
-
-## Beat 2: Channel
-
-Say something like: "I work best when I can reach you proactively \u2014 let's
-get me into your Slack." Then, without waiting:
-
-1. Start sign-in with \`auto auth login --device\` and give the user the
-   verification URL. Account, organization, and project setup happen in the
-   browser.
-2. Check \`auto connections list --available\` and start the Slack connection
-   (\`auto connect slack\`), giving the user that link too.
-3. Move straight to Beat 3 while the user clicks. Poll for completion in the
-   background; never sit idle waiting for a click.
-
-## Beat 3: Study
-
-Build a repo dossier while the clicks happen. Explore the codebase and git
-history for:
-
-- Stack and layout: languages, frameworks, build and test setup, CI and
-  deploy workflows (Beat 6 wires into these).
-- How the team works: PR conventions, review patterns, branch and release
-  habits, merge frequency.
-- Tools referenced: issue tracker keys in commits and branches, chat or
-  deploy tooling named in docs and workflow files, existing agent config
-  (CLAUDE.md, AGENTS.md, .cursor).
-- Live state, using the user's own credentials (git, gh): open PRs, CI
-  status, recent activity.
-
-Write the dossier as structured markdown. It has two consumers: the
-concierge agent (Beat 4) and your own interview (Beat 5). End it with 2-3
-candidate workflows from the playbook below, each tied to a concrete signal
-you found.
-
-## Beat 4: First contact
-
-The concierge is a session you create in this project, not one that ships
-pre-installed. When sign-in, Slack, and the dossier are all ready:
-
-1. Draft the concierge into \`.auto/\` from the template below. Adapt names,
-   reuse an existing profile or environment if the project already has one,
-   and verify with \`auto apply --dry-run\` before applying.
-2. Launch it headlessly with the dossier as the run message:
-   \`auto run concierge --message <dossier>\`. Run messages cap at 20,000
-   characters, so distill the dossier to fit; lead with the live state
-   (open PRs, CI status) since that is what makes first contact specific.
-
-\`\`\`yaml
-kind: session
-metadata:
-  name: concierge
-spec:
-  profile: concierge
-  identity:
-    displayName: auto concierge
-    username: auto-concierge
-    description: This project's auto agent. Ask it to add or change workflows.
-  tools:
-    chat:
-      ref: slack-chat
-  initialPrompt: |
-    You are this project's auto concierge. If your message contains a repo
-    dossier, this is first contact: send the user exactly one Slack message
-    via chat.send - one concrete, verifiable observation from the dossier
-    plus one offer. Short, specific, never templated. Otherwise the user is
-    consulting you: help them add or adjust workflows by editing .auto/
-    resources and applying them.
-\`\`\`
-
-The profile and the slack-chat tool follow the project's existing
-conventions; if the project has neither, draft minimal ones (see
-\`auto apply --help\` and the resource examples in the docs).
-
-The concierge reads the dossier and sends the user one proactive Slack
-message: a specific observation about this repo plus one offer. Do not
-attach to the run or take over the terminal; you remain the user's
-interface.
-
-Tell the user to check Slack. The buzz is the point: an agent they just met
-already knows their codebase and can reach them.
-
-If the apply fails or the Slack identity is not ready yet, skip this beat
-and let the installed workflow's first firing be first contact instead.
-
-## Beat 5: Interview, then install
-
-Back in the terminal, ask 3-5 questions, one at a time, each grounded in
-the dossier ("I see FRA- refs everywhere \u2014 who triages those?"). Converge on
-one workflow. Then:
-
-1. Draft the session YAML into \`.auto/sessions/\`.
-2. Show a plain-language summary of what will run and when ("on every PR
-   opened, I'll review it against your conventions and report in Slack").
-3. Get one explicit yes.
-4. If the workflow needs repository events, connect the GitHub App now
-   (\`auto connect github\`) \u2014 this is the moment the ask is motivated. Other
-   providers (Linear, Notion, ...) connect only when the chosen workflow
-   needs them, never speculatively.
-5. Apply with \`auto apply\` and confirm the trigger is active. Route the
-   workflow's reports to the Slack channel from Beat 2.
-
-## Beat 6: Wire CI to apply on merge
-
-Every apply so far ran from this terminal under the user's own login. Its
-durable home is CI: a dry-run plan as a check on every PR, and the real
-apply when changes merge \u2014 \`.auto/\` ships the same way the code does. Do
-this once the GitHub App is connected and the first apply has succeeded.
-
-1. CI authenticates as a service account, never as the user. Create two \u2014
-   the \`applier\` token lives only on the merge path, while the \`read-only\`
-   token is exposed to PR-triggered runs: it can produce the dry-run plan
-   but cannot perform a real apply, and it stays revocable on its own. Pipe
-   each token straight into a GitHub secret so it never touches your
-   transcript or disk \u2014 with \`pipefail\` and \`jq -re\` so a failed create
-   cannot silently store an empty secret:
-
-   \`\`\`sh
-   set -o pipefail
-   auto service-account create github-actions-auto-apply \\
-     --preset applier --json \\
-     | jq -re .token | gh secret set AUTO_APPLY_SERVICE_ACCOUNT_TOKEN
-   auto service-account create github-actions-auto-apply-dry-run \\
-     --preset read-only --json \\
-     | jq -re .token | gh secret set AUTO_APPLY_DRY_RUN_SERVICE_ACCOUNT_TOKEN
-   \`\`\`
-
-   Confirm both pipelines exited 0 and \`gh secret list\` shows both names
-   before moving on. If deploys go through a GitHub environment, scope the
-   apply secret to it (\`gh secret set --env\`).
-2. Fit into the deploy process you mapped in Beat 3. If a workflow already
-   ships merges, splice two steps in after its deploy succeeds \u2014 plan
-   (\`auto apply --dry-run\`), then \`auto apply\` \u2014 reusing its checkout and
-   Node setup. If nothing deploys from CI yet, add the standalone workflow
-   below. Either way, keep the PR dry-run check: it shows reviewers the
-   exact create/update/archive plan their merge will execute.
-3. Workflow files live outside \`.auto/\`, so show the user the file and get
-   a yes; commit it on the same branch as the \`.auto/\` resources.
-
-\`\`\`yaml
-name: Auto Apply
-
-# Both triggers assume the default branch is main; swap in the repo's
-# actual default branch before committing.
-on:
-  pull_request:
-    branches: [main]
-  push:
-    branches: [main]
-
-permissions:
-  contents: read
-
-concurrency:
-  group: auto-apply-\${{ github.event.pull_request.number || github.ref }}
-  cancel-in-progress: \${{ github.event_name == 'pull_request' }}
-
-jobs:
-  plan:
-    runs-on: ubuntu-latest
-    timeout-minutes: 10
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: lts/*
-      - run: npx -y --package=@autohq/cli auto apply --dry-run
-        env:
-          AUTO_API_TOKEN: \${{ secrets.AUTO_APPLY_DRY_RUN_SERVICE_ACCOUNT_TOKEN }}
-
-  apply:
-    if: \${{ github.event_name == 'push' }}
-    needs: plan
-    runs-on: ubuntu-latest
-    timeout-minutes: 10
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: lts/*
-      - run: npx -y --package=@autohq/cli auto apply
-        env:
-          AUTO_API_TOKEN: \${{ secrets.AUTO_APPLY_SERVICE_ACCOUNT_TOKEN }}
-\`\`\`
-
-Adapt it to the repo: the default branch name, the team's Node setup or
-pinned tool versions, and set \`AUTO_API_BASE_URL\` only if the project runs
-against a non-default Auto host. \`pull_request\` runs from forks do not
-receive secrets; if fork PRs are routine here, run the dry-run from a
-\`pull_request_target\` workflow that checks out workflow code from the base
-branch and only \`.auto/\` from the PR head.
-
-After the PR merges, watch the first run and confirm its plan reports the
-resources you already applied as unchanged. From then on, \`.auto/\` on the
-default branch is the source of truth \u2014 directory apply prunes resources
-that are no longer declared, so the team changes agents by PR, not by
-terminal.
-
-## Workflow playbook
-
-Candidates, strongest signals, and what confirms fit:
-
-- PR review: frequent PRs, visible review conventions. Confirm: "what do
-  reviewers always catch by hand?" Fires on the next PR.
-- CI failure triage: CI config plus red or flaky runs in recent history.
-  Confirm: "who notices when main goes red?" Fires within hours.
-- Issue triage: tracker refs in commits, an untriaged backlog. Confirm:
-  "who looks at new issues today?" Needs the tracker connected.
-- Daily digest: busy repo, distributed team. Confirm: "would a morning
-  summary of PRs, CI, and issues be useful?" Fires next morning.
-- Dependency or flaky-test watch: lockfile churn or retry patterns in CI.
-  Slower to first fire; prefer the options above for the first install.
-
-Estimate time-to-first-trigger for each candidate you propose, and say it
-out loud when proposing.
-
-## If something is blocked
-
-- Slack needs admin approval: continue without the channel. Finish the
-  interview and install; tell the user their agent will appear in Slack once
-  the install is approved, and have the concierge retry.
-- Sign-in stalls: the user may not have an invite yet; point them at the
-  auto site and pause gracefully rather than failing.
-- \`gh secret set\` fails (no repo admin rights, gh not authenticated):
-  leave the CI workflow in the PR anyway and hand the user the two
-  create-and-pipe commands from Beat 6 to run themselves. Tokens are shown
-  once and must never be pasted into the conversation.
-- A command disagrees with this document: the command is right. Re-read
-  \`auto --help\` and adapt.
-
-## What you leave behind
-
-- \`.auto/\` committed on a branch with a PR the user can merge: the
-  concierge and workflow session YAML, the CI apply workflow from Beat 6,
-  plus \`context.md\` (the distilled dossier). Write the PR description for
-  teammates \u2014 it doubles as the announcement that this repo now has an
-  auto agent.
-- With the user's opt-in, an AGENTS.md section that tells every future
-  coding agent in this repo that auto exists, what is deployed, and how to
-  add workflows.
-- Tell the user the two ways back: talk to the bot in Slack, or run
-  \`auto onboard --agent\` again any time.
-`;
+// src/commands/onboard/quickstart-content.ts
 var humanQuickstartText = `Get started with auto:
 
   1. auto auth login          sign in (device flow; account setup in browser)
@@ -30178,6 +29899,9 @@ a first workflow tailored to how your team works.
 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";
+
 // src/commands/onboard/commands.ts
 function registerOnboardCommands(program, context) {
   program.command("onboard").description(

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autohq/cli",
-  "version": "0.1.90",
+  "version": "0.1.92",
   "license": "SEE LICENSE IN README.md",
   "publishConfig": {
     "access": "public"
@@ -23,6 +23,7 @@
     "build": "tsup",
     "dev": "tsx src/main.ts",
     "dev:tui": "node ../../scripts/cli-tui-dev-watch.mjs",
+    "skill:generate": "tsx scripts/generate-skill-content.ts",
     "test": "npm run test:unit",
     "test:unit": "tsx --test \"test/**/*.unit.test.ts\"",
     "typecheck": "tsc --noEmit"