mirror of
https://github.com/qwibitai/nanoclaw.git
synced 2026-06-04 10:14:47 +08:00
refactor(skills): merge /new-setup-2 into unified /new-setup
Collapses the two-phase setup into a single linear skill: steps 1-6 (prereqs through end-to-end CLI ping) run straight through, steps 7-13 (naming, timezone, channel wiring, mounts, QoL, done) are skippable. Drops the "chat now vs. continue" branch point — after the ping the flow emits "Test Agent success, proceeding with setup" and continues directly into the naming questions. Also updates stale `/new-setup-2` header comments in setup/install-*.sh. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Koshkoshinsk
@@ -1,155 +0,0 @@
|
||||
---
|
||||
name: new-setup-2
|
||||
description: Follow-on to /new-setup. Captures the operator and agent names, wires a real messaging channel, and adds quality-of-life extras. Linear rollthrough; every step is skippable. Invoked when the user picks "continue setup" at the end of /new-setup.
|
||||
allowed-tools: Bash(bash setup/probe.sh) Bash(bash setup/install-telegram.sh) Bash(bash setup/install-telegram.sh:*) Bash(pnpm exec tsx setup/index.ts:*) Bash(pnpm exec tsx scripts/init-first-agent.ts:*) Bash(tail:*) Bash(head:*) Bash(grep:*)
|
||||
---
|
||||
|
||||
# NanoClaw phase-2 setup
|
||||
|
||||
Runs after `/new-setup`. At this point the host is running and a throwaway CLI-only agent exists (used during /new-setup for the end-to-end ping check — inferred name, not user-facing). This flow creates the **real** agent and wires it to a messaging channel.
|
||||
|
||||
**Linear — one step at a time.** Every step is skippable: if the user says "skip", "not now", "later", or similar, move on without complaint. If they say they're done at any point, stop cleanly — don't push the remaining steps.
|
||||
|
||||
Before each step, narrate in your own words what's about to happen — one short, friendly sentence, no jargon. Match the tone of `/new-setup`.
|
||||
|
||||
## Current state
|
||||
|
||||
!`bash setup/probe.sh`
|
||||
|
||||
Parse the probe block above for `INFERRED_DISPLAY_NAME` and `PLATFORM` — referenced below.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. What should the agent call you?
|
||||
|
||||
Plain-prose ask (do **not** use `AskUserQuestion`):
|
||||
|
||||
> What should your agent call you? (Default: `<INFERRED_DISPLAY_NAME>`)
|
||||
|
||||
Capture the answer into a local variable `OPERATOR_NAME`. **Don't persist yet** — this value is consumed by step 3's channel wiring. If the user skips or confirms the default, set `OPERATOR_NAME = INFERRED_DISPLAY_NAME`.
|
||||
|
||||
### 2. What's your agent's name?
|
||||
|
||||
Plain-prose ask:
|
||||
|
||||
> What would you like to call your agent? (Default: `<OPERATOR_NAME>`)
|
||||
|
||||
Capture as `AGENT_NAME`. If skipped, set `AGENT_NAME = OPERATOR_NAME`. Nothing persisted yet.
|
||||
|
||||
### 3. Timezone
|
||||
|
||||
Run `pnpm exec tsx setup/index.ts --step timezone` and parse the status block.
|
||||
|
||||
- **RESOLVED_TZ is `UTC` or `Etc/UTC`** — before leaving UTC in `.env`, confirm with `AskUserQuestion`:
|
||||
|
||||
- **Question**: "Your system reports UTC as the timezone. Is that right, or are you somewhere else?"
|
||||
- **Header**: "Timezone"
|
||||
- **Options**:
|
||||
1. `Keep UTC` — "Leave timezone as UTC."
|
||||
2. `I'm somewhere else` — "I'll name the IANA zone (e.g. `America/New_York`, `Europe/London`, `Asia/Tokyo`) via Other."
|
||||
|
||||
If they pick "I'm somewhere else" (or type an IANA zone via Other), re-run `pnpm exec tsx setup/index.ts --step timezone -- --tz <answer>` to overwrite `.env`. If they keep UTC or skip, leave UTC in place.
|
||||
|
||||
- **NEEDS_USER_INPUT=true** — autodetection failed. Use `AskUserQuestion` with the same two options above (reword the question to "Autodetection failed — what timezone are you in?"), then re-run `pnpm exec tsx setup/index.ts --step timezone -- --tz <answer>` if they supply one. If they skip, move on.
|
||||
|
||||
- Otherwise — timezone is already set; move on.
|
||||
|
||||
### 4. Pick a messaging channel
|
||||
|
||||
Print the list as a numbered plain-prose list (too many options for `AskUserQuestion`, which caps at 4). The user replies with a number or channel name. Preserve the numbering exactly:
|
||||
|
||||
> Which messaging channel should I wire your agent to?
|
||||
>
|
||||
> 1. **WhatsApp (native)** — `/add-whatsapp`
|
||||
> 2. **WhatsApp Cloud (Meta official)** — `/add-whatsapp-cloud`
|
||||
> 3. **Telegram** — `/add-telegram`
|
||||
> 4. **Slack** — `/add-slack`
|
||||
> 5. **Discord** — `/add-discord`
|
||||
> 6. **iMessage** — `/add-imessage`
|
||||
> 7. **Teams** — `/add-teams`
|
||||
> 8. **Matrix** — `/add-matrix`
|
||||
> 9. **Google Chat** — `/add-gchat`
|
||||
> 10. **Linear** — `/add-linear`
|
||||
> 11. **GitHub** — `/add-github`
|
||||
> 12. **Webex** — `/add-webex`
|
||||
> 13. **Resend (email)** — `/add-resend`
|
||||
> 14. **Emacs** — `/add-emacs`
|
||||
>
|
||||
> Or say "skip" to leave this for later.
|
||||
|
||||
When the user picks one:
|
||||
|
||||
1. **Install the adapter.** For **Telegram**, run `bash setup/install-telegram.sh` directly — it bundles the preflight + fetch + copy + register + `pnpm install` + build from `/add-telegram` into one idempotent call. Then handle Telegram credentials inline (below) — **do not** invoke `/add-telegram` afterward; its Credentials section would generate an unapprovable `grep && sed && rm` to write `.env`. For every other channel, invoke the matching `/add-<channel>` skill via the Skill tool; it copies the adapter source in from the `channels` branch, registers it, installs the pinned npm package, and handles credentials. Some channels also run a pairing step as part of their flow.
|
||||
|
||||
**Telegram credentials (inline):**
|
||||
- Walk the user through BotFather: `/newbot` → pick name + username ending in `bot` → copy the token.
|
||||
- Remind them: in `@BotFather` → `/mybots` → their bot → Bot Settings → Group Privacy → **Turn off** (only needed if the bot will live in groups; DM-only can skip).
|
||||
- Persist the token and sync it to the container mount with the generic setter:
|
||||
|
||||
```
|
||||
pnpm exec tsx setup/index.ts --step set-env -- \
|
||||
--key TELEGRAM_BOT_TOKEN --value "<token>" --sync-container
|
||||
```
|
||||
|
||||
2. **Capture platform IDs.** After the `/add-<channel>` skill finishes (or after inline credentials for Telegram), you need two values: the operator's user-id on that platform, and the chat/channel platform-id. Each channel surfaces these differently — consult the **Channel Info** section at the bottom of that skill's `SKILL.md` for the exact path. For Telegram, run `pnpm exec tsx setup/index.ts --step pair-telegram -- --intent <main|wire-to:folder|new-agent:folder>` directly and follow its `PAIR_TELEGRAM_ISSUED`/`PAIR_TELEGRAM STATUS=success` blocks — `PLATFORM_ID` and `ADMIN_USER_ID` land in the success block.
|
||||
3. **Wire the agent.** Run `init-first-agent.ts` in DM mode with `--no-cli-bonus` (this keeps the new agent off the CLI messaging group so the pre-existing throwaway agent still owns CLI routing cleanly):
|
||||
|
||||
```
|
||||
pnpm exec tsx scripts/init-first-agent.ts \
|
||||
--channel <channel> \
|
||||
--user-id "<platform-user-id>" \
|
||||
--platform-id "<platform-chat-id>" \
|
||||
--display-name "<OPERATOR_NAME>" \
|
||||
--agent-name "<AGENT_NAME>" \
|
||||
--no-cli-bonus
|
||||
```
|
||||
|
||||
4. **Announce.** On success, emit the encouragement line verbatim:
|
||||
|
||||
> Your agent is now available on {channel-name}, you can already start chatting — But I encourage you to continue and finish this setup, we're almost done!
|
||||
|
||||
Substitute `{channel-name}` with the friendly name (e.g. "Telegram", "WhatsApp", "Slack").
|
||||
|
||||
If the user skipped, move on to step 5.
|
||||
|
||||
### 5. Host directory access
|
||||
|
||||
By default, agent containers can only touch their own workspace. If the user wants the agent to read or write files in specific host directories, those paths need to go on the mount allowlist.
|
||||
|
||||
Use `AskUserQuestion`:
|
||||
|
||||
- **Question**: "Want your agent to read or write files in any host directories (e.g. a code project, `~/Documents`)?"
|
||||
- **Header**: "Host mounts"
|
||||
- **Options**:
|
||||
1. `Keep isolated` — "Agent only touches its own workspace (Recommended)."
|
||||
2. `Add host paths` — "I'll name the directories to allowlist via Other."
|
||||
|
||||
If they pick "Add host paths" (or name paths via Other), invoke `/manage-mounts` via the Skill tool to add them. If they keep it isolated or skip, move on.
|
||||
|
||||
### 6. Quality of life
|
||||
|
||||
Optional polish. Print the list; the user may pick zero, one, or several — invoke each chosen skill in sequence:
|
||||
|
||||
> Want to add any of these? Pick any that sound useful — or skip:
|
||||
>
|
||||
> - `/add-dashboard` — browser dashboard showing agent activity
|
||||
> - `/add-compact` — `/compact` slash command for managing long sessions
|
||||
> - `/add-karpathy-llm-wiki` — persistent knowledge-base memory for the agent
|
||||
|
||||
If the probe reports `PLATFORM=darwin`, also offer:
|
||||
|
||||
> - `/add-macos-statusbar` — macOS menu bar indicator with Start/Stop/Restart controls
|
||||
|
||||
Do **not** list `/add-macos-statusbar` on Linux. If the user skips everything, just move on.
|
||||
|
||||
### 7. Done
|
||||
|
||||
Short wrap-up:
|
||||
|
||||
> Setup complete. You can chat with your agent on {channel-name} — or via CLI with `pnpm run chat <message>`.
|
||||
|
||||
Substitute `{channel-name}` with whatever was wired in step 4. If step 4 was skipped, drop the "on {channel-name} — or" clause entirely so the line just mentions the CLI form.
|
||||
|
||||
## If anything fails
|
||||
|
||||
Same rule as `/new-setup`: don't bypass errors to keep moving. Read `logs/setup.log` or `logs/nanoclaw.log`, diagnose, fix the underlying cause, re-run the failed step.
|
||||
@@ -1,14 +1,17 @@
|
||||
---
|
||||
name: new-setup
|
||||
description: Shortest path from zero to a working two-way agent chat, for any user regardless of technical background — ends at a running NanoClaw instance with at least one CLI-reachable agent.
|
||||
allowed-tools: Bash(bash setup.sh) Bash(bash setup/probe.sh) Bash(bash setup/install-node.sh) Bash(bash setup/install-docker.sh) Bash(pnpm exec tsx setup/index.ts:*) Bash(pnpm run chat) Bash(pnpm run chat:*) Bash(open -a Docker) Bash(sudo systemctl start docker) Bash(node --version) Bash(tail:*) Bash(head:*) Bash(grep:*)
|
||||
description: End-to-end NanoClaw setup for any user regardless of technical background — from zero to a named agent reachable on a real messaging channel, with sensible defaults and every post-verification step skippable.
|
||||
allowed-tools: Bash(bash setup.sh) Bash(bash setup/probe.sh) Bash(bash setup/install-node.sh) Bash(bash setup/install-docker.sh) Bash(bash setup/install-telegram.sh) Bash(bash setup/install-telegram.sh:*) Bash(pnpm exec tsx setup/index.ts:*) Bash(pnpm exec tsx scripts/init-first-agent.ts:*) Bash(pnpm run chat) Bash(pnpm run chat:*) Bash(open -a Docker) Bash(sudo systemctl start docker) Bash(node --version) Bash(tail:*) Bash(head:*) Bash(grep:*)
|
||||
---
|
||||
|
||||
# NanoClaw bare-minimum setup
|
||||
# NanoClaw setup
|
||||
|
||||
Purpose of this skill is to take any user — technical or not — from zero to a two-way chat with an agent in the fewest steps possible. Done means a running NanoClaw instance with at least one agent reachable via the CLI channel.
|
||||
Purpose of this skill is to take any user — technical or not — from zero to a named agent wired to a real messaging channel in the fewest steps possible.
|
||||
|
||||
Only run the steps strictly required for the NanoClaw process to start and respond to the user end-to-end. Everything else is deferred to post-setup skills.
|
||||
The flow has two halves:
|
||||
|
||||
- **Steps 1–6 — required.** Prerequisites, credential, service start, end-to-end ping. These run straight through.
|
||||
- **Steps 7–12 — skippable.** Naming, channel wiring, QoL. Every step here is skippable: if the user says "skip", "not now", "later", or similar, move on without complaint. If they say they're done at any point, stop cleanly — don't push the remaining steps.
|
||||
|
||||
Before each step, narrate to the user in your own words what's about to happen — one short, friendly sentence, no jargon. Don't read a scripted line; use the step context below to speak naturally.
|
||||
|
||||
@@ -109,13 +112,13 @@ Start the NanoClaw background service — it relays messages between the user an
|
||||
|
||||
`pnpm exec tsx setup/index.ts --step service`
|
||||
|
||||
### 6. Wire the CLI agent and verify end-to-end
|
||||
### 6. Wire a scratch CLI agent and verify end-to-end
|
||||
|
||||
**Do not narrate this step.** No "creating your first agent…", no "sending a ping…" chatter. The user's experience here is: they finished the last visible step (service), then a single success line appears. Wiring is an implementation detail at this point, not a user-facing milestone.
|
||||
|
||||
If step 2's container build is still running in the background, join it here before proceeding — the agent needs the image.
|
||||
|
||||
Use `INFERRED_DISPLAY_NAME` from the probe silently. **Do not ask the user.** The CLI agent at this stage is a scratch agent whose only purpose is to verify the end-to-end pipeline (host → container → agent → back). The user's real name capture happens in `/new-setup-2` when they wire a messaging channel.
|
||||
Use `INFERRED_DISPLAY_NAME` from the probe silently. **Do not ask the user.** The CLI agent at this stage is a scratch agent whose only purpose is to verify the end-to-end pipeline (host → container → agent → back). The user's real name capture happens in step 7.
|
||||
|
||||
Run wiring and ping back-to-back, silently:
|
||||
|
||||
@@ -126,35 +129,141 @@ pnpm run chat ping
|
||||
|
||||
First container spin-up takes ~60s. When the agent's reply arrives, emit exactly one line to the user:
|
||||
|
||||
> Your agent is up, running and ready to go!
|
||||
> Test Agent success, proceeding with setup
|
||||
|
||||
If `pnpm run chat ping` times out or errors, tail `logs/nanoclaw.log`, diagnose, and fix — don't surface a half-success.
|
||||
|
||||
> **Loose command:** `pnpm run chat ping`. Justification: this is the same command the user will keep using after setup, so verification and the real channel are one and the same.
|
||||
|
||||
### 7. Chat now, or keep setting up?
|
||||
### 7. What should the agent call you?
|
||||
|
||||
Ask the user via `AskUserQuestion` which they'd like to do next:
|
||||
Plain-prose ask (do **not** use `AskUserQuestion`):
|
||||
|
||||
1. **Keep chatting with the agent via CLI** — happy with the CLI channel for now.
|
||||
2. **Continue setup** — name the agent, wire a messaging channel, add quality-of-life extras.
|
||||
> What should your agent call you? (Default: `<INFERRED_DISPLAY_NAME>`)
|
||||
|
||||
**If they pick "keep chatting":** print both options below, then stop. The user is chatting with the agent now, not with you — no further output from you.
|
||||
Capture the answer into a local variable `OPERATOR_NAME`. **Don't persist yet** — this value is consumed by step 10's channel wiring. If the user skips or confirms the default, set `OPERATOR_NAME = INFERRED_DISPLAY_NAME`.
|
||||
|
||||
**Option 1 — from inside this Claude Code session.** Type your message with a leading `!`, which runs it as a bash command in this shell:
|
||||
### 8. What's your agent's name?
|
||||
|
||||
```
|
||||
!pnpm run chat your message here
|
||||
```
|
||||
Plain-prose ask:
|
||||
|
||||
**Option 2 — from a separate terminal.** Open a new terminal, `cd` into your nanoclaw checkout, then:
|
||||
> What would you like to call your agent? (Default: `<OPERATOR_NAME>`)
|
||||
|
||||
```
|
||||
pnpm run chat your message here
|
||||
```
|
||||
Capture as `AGENT_NAME`. If skipped, set `AGENT_NAME = OPERATOR_NAME`. Nothing persisted yet.
|
||||
|
||||
**If they pick "continue setup":** hand off directly to `/new-setup-2` via the Skill tool. That follow-on flow is structured like this one (linear, skippable steps) and covers naming, messaging-channel wiring, and QoL. Invoke it immediately — do not offer a menu of individual skills.
|
||||
### 9. Timezone
|
||||
|
||||
Run `pnpm exec tsx setup/index.ts --step timezone` and parse the status block.
|
||||
|
||||
- **RESOLVED_TZ is `UTC` or `Etc/UTC`** — before leaving UTC in `.env`, confirm with `AskUserQuestion`:
|
||||
|
||||
- **Question**: "Your system reports UTC as the timezone. Is that right, or are you somewhere else?"
|
||||
- **Header**: "Timezone"
|
||||
- **Options**:
|
||||
1. `Keep UTC` — "Leave timezone as UTC."
|
||||
2. `I'm somewhere else` — "I'll name the IANA zone (e.g. `America/New_York`, `Europe/London`, `Asia/Tokyo`) via Other."
|
||||
|
||||
If they pick "I'm somewhere else" (or type an IANA zone via Other), re-run `pnpm exec tsx setup/index.ts --step timezone -- --tz <answer>` to overwrite `.env`. If they keep UTC or skip, leave UTC in place.
|
||||
|
||||
- **NEEDS_USER_INPUT=true** — autodetection failed. Use `AskUserQuestion` with the same two options above (reword the question to "Autodetection failed — what timezone are you in?"), then re-run `pnpm exec tsx setup/index.ts --step timezone -- --tz <answer>` if they supply one. If they skip, move on.
|
||||
|
||||
- Otherwise — timezone is already set; move on.
|
||||
|
||||
### 10. Pick a messaging channel
|
||||
|
||||
Print the list as a numbered plain-prose list (too many options for `AskUserQuestion`, which caps at 4). The user replies with a number or channel name. Preserve the numbering exactly:
|
||||
|
||||
> Which messaging channel should I wire your agent to?
|
||||
>
|
||||
> 1. **WhatsApp (native)** — `/add-whatsapp`
|
||||
> 2. **WhatsApp Cloud (Meta official)** — `/add-whatsapp-cloud`
|
||||
> 3. **Telegram** — `/add-telegram`
|
||||
> 4. **Slack** — `/add-slack`
|
||||
> 5. **Discord** — `/add-discord`
|
||||
> 6. **iMessage** — `/add-imessage`
|
||||
> 7. **Teams** — `/add-teams`
|
||||
> 8. **Matrix** — `/add-matrix`
|
||||
> 9. **Google Chat** — `/add-gchat`
|
||||
> 10. **Linear** — `/add-linear`
|
||||
> 11. **GitHub** — `/add-github`
|
||||
> 12. **Webex** — `/add-webex`
|
||||
> 13. **Resend (email)** — `/add-resend`
|
||||
> 14. **Emacs** — `/add-emacs`
|
||||
>
|
||||
> Or say "skip" to leave this for later.
|
||||
|
||||
When the user picks one:
|
||||
|
||||
1. **Install the adapter.** For **Telegram**, run `bash setup/install-telegram.sh` directly — it bundles the preflight + fetch + copy + register + `pnpm install` + build from `/add-telegram` into one idempotent call. Then handle Telegram credentials inline (below) — **do not** invoke `/add-telegram` afterward; its Credentials section would generate an unapprovable `grep && sed && rm` to write `.env`. For every other channel, invoke the matching `/add-<channel>` skill via the Skill tool; it copies the adapter source in from the `channels` branch, registers it, installs the pinned npm package, and handles credentials. Some channels also run a pairing step as part of their flow.
|
||||
|
||||
**Telegram credentials (inline):**
|
||||
- Walk the user through BotFather: `/newbot` → pick name + username ending in `bot` → copy the token.
|
||||
- Remind them: in `@BotFather` → `/mybots` → their bot → Bot Settings → Group Privacy → **Turn off** (only needed if the bot will live in groups; DM-only can skip).
|
||||
- Persist the token and sync it to the container mount with the generic setter:
|
||||
|
||||
```
|
||||
pnpm exec tsx setup/index.ts --step set-env -- \
|
||||
--key TELEGRAM_BOT_TOKEN --value "<token>" --sync-container
|
||||
```
|
||||
|
||||
2. **Capture platform IDs.** After the `/add-<channel>` skill finishes (or after inline credentials for Telegram), you need two values: the operator's user-id on that platform, and the chat/channel platform-id. Each channel surfaces these differently — consult the **Channel Info** section at the bottom of that skill's `SKILL.md` for the exact path. For Telegram, run `pnpm exec tsx setup/index.ts --step pair-telegram -- --intent <main|wire-to:folder|new-agent:folder>` directly and follow its `PAIR_TELEGRAM_ISSUED`/`PAIR_TELEGRAM STATUS=success` blocks — `PLATFORM_ID` and `ADMIN_USER_ID` land in the success block.
|
||||
3. **Wire the agent.** Run `init-first-agent.ts` in DM mode:
|
||||
|
||||
```
|
||||
pnpm exec tsx scripts/init-first-agent.ts \
|
||||
--channel <channel> \
|
||||
--user-id "<platform-user-id>" \
|
||||
--platform-id "<platform-chat-id>" \
|
||||
--display-name "<OPERATOR_NAME>" \
|
||||
--agent-name "<AGENT_NAME>"
|
||||
```
|
||||
|
||||
4. **Announce.** On success, emit the encouragement line verbatim:
|
||||
|
||||
> Your agent is now available on {channel-name}, you can already start chatting — But I encourage you to continue and finish this setup, we're almost done!
|
||||
|
||||
Substitute `{channel-name}` with the friendly name (e.g. "Telegram", "WhatsApp", "Slack").
|
||||
|
||||
If the user skipped, move on to step 11.
|
||||
|
||||
### 11. Host directory access
|
||||
|
||||
By default, agent containers can only touch their own workspace. If the user wants the agent to read or write files in specific host directories, those paths need to go on the mount allowlist.
|
||||
|
||||
Use `AskUserQuestion`:
|
||||
|
||||
- **Question**: "Want your agent to read or write files in any host directories (e.g. a code project, `~/Documents`)?"
|
||||
- **Header**: "Host mounts"
|
||||
- **Options**:
|
||||
1. `Keep isolated` — "Agent only touches its own workspace (Recommended)."
|
||||
2. `Add host paths` — "I'll name the directories to allowlist via Other."
|
||||
|
||||
If they pick "Add host paths" (or name paths via Other), invoke `/manage-mounts` via the Skill tool to add them. If they keep it isolated or skip, move on.
|
||||
|
||||
### 12. Quality of life
|
||||
|
||||
Optional polish. Print the list; the user may pick zero, one, or several — invoke each chosen skill in sequence:
|
||||
|
||||
> Want to add any of these? Pick any that sound useful — or skip:
|
||||
>
|
||||
> - `/add-dashboard` — browser dashboard showing agent activity
|
||||
> - `/add-compact` — `/compact` slash command for managing long sessions
|
||||
> - `/add-karpathy-llm-wiki` — persistent knowledge-base memory for the agent
|
||||
|
||||
If the probe reports `PLATFORM=darwin`, also offer:
|
||||
|
||||
> - `/add-macos-statusbar` — macOS menu bar indicator with Start/Stop/Restart controls
|
||||
|
||||
Do **not** list `/add-macos-statusbar` on Linux. If the user skips everything, just move on.
|
||||
|
||||
### 13. Done
|
||||
|
||||
Short wrap-up:
|
||||
|
||||
> Setup complete. You can chat with your agent on {channel-name} — or via CLI with `pnpm run chat <message>`.
|
||||
|
||||
Substitute `{channel-name}` with whatever was wired in step 10. If step 10 was skipped, drop the "on {channel-name} — or" clause entirely so the line just mentions the CLI form.
|
||||
|
||||
## If anything fails
|
||||
|
||||
Any step that reports `STATUS: failed` in its status block: read `logs/setup.log`, diagnose, fix the underlying cause, re-run the same `--step`. Don't bypass errors to keep moving.
|
||||
Any step that reports `STATUS: failed` in its status block: read `logs/setup.log` (or `logs/nanoclaw.log` for runtime failures), diagnose, fix the underlying cause, re-run the same `--step`. Don't bypass errors to keep moving.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-discord — bundles the preflight + install commands
|
||||
# from the /add-discord skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-discord skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the Discord adapter in from the `channels` branch; appends the
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-gchat — bundles the preflight + install commands
|
||||
# from the /add-gchat skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-gchat skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the Google Chat adapter in from the `channels` branch; appends the
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-github — bundles the preflight + install commands
|
||||
# from the /add-github skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-github skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the GitHub adapter in from the `channels` branch; appends the
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-imessage — bundles the preflight + install commands
|
||||
# from the /add-imessage skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-imessage skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the iMessage adapter in from the `channels` branch; appends the
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-linear — bundles the preflight + install commands
|
||||
# from the /add-linear skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-linear skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the Linear adapter in from the `channels` branch; appends the
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-matrix — bundles the preflight + install commands
|
||||
# from the /add-matrix skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-matrix skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the Matrix adapter in from the `channels` branch; appends the
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-resend — bundles the preflight + install commands
|
||||
# from the /add-resend skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-resend skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the Resend adapter in from the `channels` branch; appends the
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-slack — bundles the preflight + install commands
|
||||
# from the /add-slack skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-slack skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the Slack adapter in from the `channels` branch; appends the
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-teams — bundles the preflight + install commands
|
||||
# from the /add-teams skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-teams skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the Teams adapter in from the `channels` branch; appends the
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-telegram — bundles the preflight + install commands
|
||||
# from the /add-telegram skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-telegram skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials and pairing.
|
||||
#
|
||||
# Copies the Telegram adapter, helpers, tests, and the pair-telegram setup
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-webex — bundles the preflight + install commands
|
||||
# from the /add-webex skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-webex skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the Webex adapter in from the `channels` branch; appends the
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-whatsapp-cloud — bundles the preflight + install
|
||||
# commands from the /add-whatsapp-cloud skill into one idempotent script so
|
||||
# /new-setup-2 can run them programmatically before continuing to credentials.
|
||||
# /new-setup can run them programmatically before continuing to credentials.
|
||||
#
|
||||
# Copies the WhatsApp Cloud adapter in from the `channels` branch; appends the
|
||||
# self-registration import; installs the pinned @chat-adapter/whatsapp package;
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
# Setup helper: install-whatsapp — bundles the preflight + install commands
|
||||
# from the /add-whatsapp skill into one idempotent script so /new-setup-2 can
|
||||
# from the /add-whatsapp skill into one idempotent script so /new-setup can
|
||||
# run them programmatically before continuing to QR/pairing-code auth.
|
||||
#
|
||||
# Copies the native Baileys WhatsApp adapter, its whatsapp-auth and groups
|
||||
|
||||
Reference in New Issue
Block a user