@openparachute/agent 0.1.1 → 0.2.0

package/.claude/skills/update-nanoclaw/SKILL.md

@@ -1,243 +0,0 @@
----
-name: update-nanoclaw
-description: Efficiently bring upstream NanoClaw updates into a customized install, with preview, selective cherry-pick, and low token usage.
----
-
-# About
-
-Your NanoClaw fork drifts from upstream as you customize it. This skill pulls upstream changes into your install without losing your modifications.
-
-Run `/update-nanoclaw` in Claude Code.
-
-## How it works
-
-**Preflight**: checks for clean working tree (`git status --porcelain`). If `upstream` remote is missing, asks you for the URL (defaults to `https://github.com/qwibitai/nanoclaw.git`) and adds it. Detects the upstream branch name (`main` or `master`).
-
-**Backup**: creates a timestamped backup branch and tag (`backup/pre-update-<hash>-<timestamp>`, `pre-update-<hash>-<timestamp>`) before touching anything. Safe to run multiple times.
-
-**Preview**: runs `git log` and `git diff` against the merge base to show upstream changes since your last sync. Groups changed files into categories:
-- **Skills** (`.claude/skills/`): unlikely to conflict unless you edited an upstream skill
-- **Source** (`src/`): may conflict if you modified the same files
-- **Build/config** (`package.json`, `tsconfig*.json`, `container/`): review needed
-
-**Update paths** (you pick one):
-- `merge` (default): `git merge upstream/<branch>`. Resolves all conflicts in one pass.
-- `cherry-pick`: `git cherry-pick <hashes>`. Pull in only the commits you want.
-- `rebase`: `git rebase upstream/<branch>`. Linear history, but conflicts resolve per-commit.
-- `abort`: just view the changelog, change nothing.
-
-**Conflict preview**: before merging, runs a dry-run (`git merge --no-commit --no-ff`) to show which files would conflict. You can still abort at this point.
-
-**Conflict resolution**: opens only conflicted files, resolves the conflict markers, keeps your local customizations intact.
-
-**Validation**: runs `pnpm run build` and `pnpm test`.
-
-**Breaking changes check**: after validation, reads CHANGELOG.md for any `[BREAKING]` entries introduced by the update. If found, shows each breaking change and offers to run the recommended skill to migrate.
-
-## Rollback
-
-The backup tag is printed at the end of each run:
-```
-git reset --hard pre-update-<hash>-<timestamp>
-```
-
-Backup branch `backup/pre-update-<hash>-<timestamp>` also exists.
-
-## Token usage
-
-Only opens files with actual conflicts. Uses `git log`, `git diff`, and `git status` for everything else. Does not scan or refactor unrelated code.
-
----
-
-# Goal
-Help a user with a customized NanoClaw install safely incorporate upstream changes without a fresh reinstall and without blowing tokens.
-
-# Operating principles
-- Never proceed with a dirty working tree.
-- Always create a rollback point (backup branch + tag) before touching anything.
-- Prefer git-native operations (fetch, merge, cherry-pick). Do not manually rewrite files except conflict markers.
-- Default to MERGE (one-pass conflict resolution). Offer REBASE as an explicit option.
-- Keep token usage low: rely on `git status`, `git log`, `git diff`, and open only conflicted files.
-
-# Step 0: Preflight (stop early if unsafe)
-Run:
-- `git status --porcelain`
-If output is non-empty:
-- Tell the user to commit or stash first, then stop.
-
-Confirm remotes:
-- `git remote -v`
-If `upstream` is missing:
-- Ask the user for the upstream repo URL (default: `https://github.com/qwibitai/nanoclaw.git`).
-- Add it: `git remote add upstream <user-provided-url>`
-- Then: `git fetch upstream --prune`
-
-Determine the upstream branch name:
-- `git branch -r | grep upstream/`
-- If `upstream/main` exists, use `main`.
-- If only `upstream/master` exists, use `master`.
-- Otherwise, ask the user which branch to use.
-- Store this as UPSTREAM_BRANCH for all subsequent commands. Every command below that references `upstream/main` should use `upstream/$UPSTREAM_BRANCH` instead.
-
-Fetch:
-- `git fetch upstream --prune`
-
-# Step 1: Create a safety net
-Capture current state:
-- `HASH=$(git rev-parse --short HEAD)`
-- `TIMESTAMP=$(date +%Y%m%d-%H%M%S)`
-
-Create backup branch and tag (using timestamp to avoid collisions on retry):
-- `git branch backup/pre-update-$HASH-$TIMESTAMP`
-- `git tag pre-update-$HASH-$TIMESTAMP`
-
-Save the tag name for later reference in the summary and rollback instructions.
-
-# Step 2: Preview what upstream changed (no edits yet)
-Compute common base:
-- `BASE=$(git merge-base HEAD upstream/$UPSTREAM_BRANCH)`
-
-Show upstream commits since BASE:
-- `git log --oneline $BASE..upstream/$UPSTREAM_BRANCH`
-
-Show local commits since BASE (custom drift):
-- `git log --oneline $BASE..HEAD`
-
-Show file-level impact from upstream:
-- `git diff --name-only $BASE..upstream/$UPSTREAM_BRANCH`
-
-Bucket the upstream changed files:
-- **Skills** (`.claude/skills/`): unlikely to conflict unless the user edited an upstream skill
-- **Source** (`src/`): may conflict if user modified the same files
-- **Build/config** (`package.json`, `pnpm-lock.yaml`, `tsconfig*.json`, `container/`, `launchd/`): review needed
-- **Other**: docs, tests, misc
-
-**Large drift check:** If the upstream commit count and age suggest the user has a lot of catching up to do, mention that `/migrate-nanoclaw` might be a better fit — it extracts customizations and reapplies them on clean upstream instead of merging. Offer it as an option but don't push.
-
-Present these buckets to the user and ask them to choose one path using AskUserQuestion:
-- A) **Full update**: merge all upstream changes
-- B) **Selective update**: cherry-pick specific upstream commits
-- C) **Abort**: they only wanted the preview
-- D) **Rebase mode**: advanced, linear history (warn: resolves conflicts per-commit)
-
-If Abort: stop here.
-
-# Step 3: Conflict preview (before committing anything)
-If Full update or Rebase:
-- Dry-run merge to preview conflicts. Run these as a single chained command so the abort always executes:
-  ```
-  git merge --no-commit --no-ff upstream/$UPSTREAM_BRANCH; git diff --name-only --diff-filter=U; git merge --abort
-  ```
-- If conflicts were listed: show them and ask user if they want to proceed.
-- If no conflicts: tell user it is clean and proceed.
-
-# Step 4A: Full update (MERGE, default)
-Run:
-- `git merge upstream/$UPSTREAM_BRANCH --no-edit`
-
-If conflicts occur:
-- Run `git status` and identify conflicted files.
-- For each conflicted file:
-  - Open the file.
-  - Resolve only conflict markers.
-  - Preserve intentional local customizations.
-  - Incorporate upstream fixes/improvements.
-  - Do not refactor surrounding code.
-  - `git add <file>`
-- When all resolved:
-  - If merge did not auto-commit: `git commit --no-edit`
-
-# Step 4B: Selective update (CHERRY-PICK)
-If user chose Selective:
-- Recompute BASE if needed: `BASE=$(git merge-base HEAD upstream/$UPSTREAM_BRANCH)`
-- Show commit list again: `git log --oneline $BASE..upstream/$UPSTREAM_BRANCH`
-- Ask user which commit hashes they want.
-- Apply: `git cherry-pick <hash1> <hash2> ...`
-
-If conflicts during cherry-pick:
-- Resolve only conflict markers, then:
-  - `git add <file>`
-  - `git cherry-pick --continue`
-If user wants to stop:
-  - `git cherry-pick --abort`
-
-# Step 4C: Rebase (only if user explicitly chose option D)
-Run:
-- `git rebase upstream/$UPSTREAM_BRANCH`
-
-If conflicts:
-- Resolve conflict markers only, then:
-  - `git add <file>`
-  - `git rebase --continue`
-If it gets messy (more than 3 rounds of conflicts):
-  - `git rebase --abort`
-  - Recommend merge instead.
-
-# Step 5: Validation
-Run:
-- `pnpm run build`
-- `pnpm test` (do not fail the flow if tests are not configured)
-
-If build fails:
-- Show the error.
-- Only fix issues clearly caused by the merge (missing imports, type mismatches from merged code).
-- Do not refactor unrelated code.
-- If unclear, ask the user before making changes.
-
-# Step 6: Breaking changes check
-After validation succeeds, check if the update introduced any breaking changes.
-
-Determine which CHANGELOG entries are new by diffing against the backup tag:
-- `git diff <backup-tag-from-step-1>..HEAD -- CHANGELOG.md`
-
-Parse the diff output for lines that contain `[BREAKING]` anywhere in the line. Each such line is one breaking change entry. The format is:
-```
-[BREAKING] <description>. Run `/<skill-name>` to <action>.
-```
-
-If no `[BREAKING]` lines are found:
-- Skip this step silently. Proceed to Step 7 (skill updates check).
-
-If one or more `[BREAKING]` lines are found:
-- Display a warning header to the user: "This update includes breaking changes that may require action:"
-- For each breaking change, display the full description.
-- Collect all skill names referenced in the breaking change entries (the `/<skill-name>` part).
-- Use AskUserQuestion to ask the user which migration skills they want to run now. Options:
-  - One option per referenced skill (e.g., "Run /add-whatsapp to re-add WhatsApp channel")
-  - "Skip — I'll handle these manually"
-- Set `multiSelect: true` so the user can pick multiple skills if there are several breaking changes.
-- For each skill the user selects, invoke it using the Skill tool.
-- After all selected skills complete (or if user chose Skip), proceed to Step 7 (skill updates check).
-
-# Step 7: Check for skill updates
-After the summary, check if skills are distributed as branches in this repo:
-- `git branch -r --list 'upstream/skill/*'`
-
-If any `upstream/skill/*` branches exist:
-- Use AskUserQuestion to ask: "Upstream has skill branches. Would you like to check for skill updates?"
-  - Option 1: "Yes, check for updates" (description: "Runs /update-skills to check for and apply skill branch updates")
-  - Option 2: "No, skip" (description: "You can run /update-skills later any time")
-- If user selects yes, invoke `/update-skills` using the Skill tool.
-- After the skill completes (or if user selected no), proceed to Step 8.
-
-# Step 8: Summary + rollback instructions
-Show:
-- Backup tag: the tag name created in Step 1
-- New HEAD: `git rev-parse --short HEAD`
-- Upstream HEAD: `git rev-parse --short upstream/$UPSTREAM_BRANCH`
-- Conflicts resolved (list files, if any)
-- Breaking changes applied (list skills run, if any)
-- Remaining local diff vs upstream: `git diff --name-only upstream/$UPSTREAM_BRANCH..HEAD`
-
-Tell the user:
-- To rollback: `git reset --hard <backup-tag-from-step-1>`
-- Backup branch also exists: `backup/pre-update-<HASH>-<TIMESTAMP>`
-- Restart the service to apply changes:
-  - If using launchd: `launchctl unload ~/Library/LaunchAgents/com.nanoclaw.plist && launchctl load ~/Library/LaunchAgents/com.nanoclaw.plist`
-  - If running manually: restart `pnpm run dev`
-
-
-## Diagnostics
-
-1. Use the Read tool to read `.claude/skills/update-nanoclaw/diagnostics.md`.
-2. Follow every step in that file before finishing.

package/.claude/skills/update-nanoclaw/diagnostics.md

@@ -1,48 +0,0 @@
-# Diagnostics
-
-Gather system info:
-
-```bash
-node -p "require('./package.json').version"
-uname -s
-uname -m
-node -p "process.versions.node.split('.')[0]"
-git log -1 --format=%ci HEAD@{1} 2>/dev/null || echo "unknown"
-```
-
-Write `/tmp/nanoclaw-diagnostics.json`. No paths, usernames, hostnames, or IP addresses.
-
-```json
-{
-  "api_key": "phc_fx1Hhx9ucz8GuaJC8LVZWO8u03yXZZJJ6ObS4yplnaP",
-  "event": "update_complete",
-  "distinct_id": "<uuid>",
-  "properties": {
-    "success": true,
-    "nanoclaw_version": "1.2.21",
-    "os_platform": "darwin",
-    "arch": "arm64",
-    "node_major_version": 22,
-    "version_age_days": 45,
-    "update_method": "merge",
-    "conflict_count": 0,
-    "breaking_changes_found": false,
-    "error_count": 0
-  }
-}
-```
-
-Show the entire JSON to the user and ask via AskUserQuestion: **Yes** / **No** / **Never ask again**
-
-**Yes**:
-```bash
-curl -s -X POST https://us.i.posthog.com/capture/ -H 'Content-Type: application/json' -d @/tmp/nanoclaw-diagnostics.json
-rm /tmp/nanoclaw-diagnostics.json
-```
-
-**No**: `rm /tmp/nanoclaw-diagnostics.json`
-
-**Never ask again**:
-1. Replace contents of `.claude/skills/update-nanoclaw/diagnostics.md` with `# Diagnostics — opted out`
-2. Remove the `## Diagnostics` section from `.claude/skills/update-nanoclaw/SKILL.md`
-3. `rm /tmp/nanoclaw-diagnostics.json`

package/.claude/skills/update-skills/SKILL.md

@@ -1,130 +0,0 @@
----
-name: update-skills
-description: Check for and apply updates to installed skill branches from upstream.
----
-
-# About
-
-Skills are distributed as git branches (`skill/*`). When you install a skill, you merge its branch into your repo. This skill checks upstream for newer commits on those skill branches and helps you update.
-
-Run `/update-skills` in Claude Code.
-
-## How it works
-
-**Preflight**: checks for clean working tree and upstream remote.
-
-**Detection**: fetches upstream, lists all `upstream/skill/*` branches, determines which ones you've previously merged (via merge-base), and checks if any have new commits.
-
-**Selection**: presents a list of skills with available updates. You pick which to update.
-
-**Update**: merges each selected skill branch, resolves conflicts if any, then validates with build + test.
-
----
-
-# Goal
-Help users update their installed skill branches from upstream without losing local customizations.
-
-# Operating principles
-- Never proceed with a dirty working tree.
-- Only offer updates for skills the user has already merged (installed).
-- Use git-native operations. Do not manually rewrite files except conflict markers.
-- Keep token usage low: rely on `git` commands, only open files with actual conflicts.
-
-# Step 0: Preflight
-
-Run:
-- `git status --porcelain`
-
-If output is non-empty:
-- Tell the user to commit or stash first, then stop.
-
-Check remotes:
-- `git remote -v`
-
-If `upstream` is missing:
-- Ask the user for the upstream repo URL (default: `https://github.com/qwibitai/nanoclaw.git`).
-- `git remote add upstream <url>`
-
-Fetch:
-- `git fetch upstream --prune`
-
-# Step 1: Detect installed skills with available updates
-
-List all upstream skill branches:
-- `git branch -r --list 'upstream/skill/*'`
-
-For each `upstream/skill/<name>`:
-1. Check if the user has merged this skill branch before:
-   - `git merge-base --is-ancestor upstream/skill/<name>~1 HEAD` — if this succeeds (exit 0) for any ancestor commit of the skill branch, the user has merged it at some point. A simpler check: `git log --oneline --merges --grep="skill/<name>" HEAD` to see if there's a merge commit referencing this branch.
-   - Alternative: `MERGE_BASE=$(git merge-base HEAD upstream/skill/<name>)` — if the merge base is NOT the initial commit and the merge base includes commits unique to the skill branch, it has been merged.
-   - Simplest reliable check: compare `git merge-base HEAD upstream/skill/<name>` with `git merge-base HEAD upstream/main`. If the skill merge-base is strictly ahead of (or different from) the main merge-base, the user has merged this skill.
-2. Check if there are new commits on the skill branch not yet in HEAD:
-   - `git log --oneline HEAD..upstream/skill/<name>`
-   - If this produces output, there are updates available.
-
-Build three lists:
-- **Updates available**: skills that are merged AND have new commits
-- **Up to date**: skills that are merged and have no new commits
-- **Not installed**: skills that have never been merged
-
-# Step 2: Present results
-
-If no skills have updates available:
-- Tell the user all installed skills are up to date. List them.
-- If there are uninstalled skills, mention them briefly (e.g., "3 other skills available in upstream that you haven't installed").
-- Stop here.
-
-If updates are available:
-- Show the list of skills with updates, including the number of new commits for each:
-  ```
-  skill/<name>: 3 new commits
-  skill/<other>: 1 new commit
-  ```
-- Also show skills that are up to date (for context).
-- Use AskUserQuestion with `multiSelect: true` to let the user pick which skills to update.
-  - One option per skill with updates, labeled with the skill name and commit count.
-  - Add an option: "Skip — don't update any skills now"
-- If user selects Skip, stop here.
-
-# Step 3: Apply updates
-
-For each selected skill (process one at a time):
-
-1. Tell the user which skill is being updated.
-2. Run: `git merge upstream/skill/<name> --no-edit`
-3. If the merge is clean, move to the next skill.
-4. If conflicts occur:
-   - Run `git status` to identify conflicted files.
-   - For each conflicted file:
-     - Open the file.
-     - Resolve only conflict markers.
-     - Preserve intentional local customizations.
-     - `git add <file>`
-   - Complete the merge: `git commit --no-edit`
-
-If a merge fails badly (e.g., cannot resolve conflicts):
-- `git merge --abort`
-- Tell the user this skill could not be auto-updated and they should resolve it manually.
-- Continue with the remaining skills.
-
-# Step 4: Validation
-
-After all selected skills are merged:
-- `pnpm run build`
-- `pnpm test` (do not fail the flow if tests are not configured)
-
-If build fails:
-- Show the error.
-- Only fix issues clearly caused by the merge (missing imports, type mismatches).
-- Do not refactor unrelated code.
-- If unclear, ask the user.
-
-# Step 5: Summary
-
-Show:
-- Skills updated (list)
-- Skills skipped or failed (if any)
-- New HEAD: `git rev-parse --short HEAD`
-- Any conflicts that were resolved (list files)
-
-If the service is running, remind the user to restart it to pick up changes.

package/.claude/skills/use-native-credential-proxy/SKILL.md

@@ -1,167 +0,0 @@
----
-name: use-native-credential-proxy
-description: Replace OneCLI gateway with the built-in credential proxy. For users who want simple .env-based credential management without installing OneCLI. Reads API key or OAuth token from .env and injects into container API requests.
----
-
-# Use Native Credential Proxy
-
-This skill replaces the OneCLI gateway with NanoClaw's built-in credential proxy. Containers get credentials injected via a local HTTP proxy that reads from `.env` — no external services needed.
-
-## Phase 1: Pre-flight
-
-### Check if already applied
-
-Check if `src/credential-proxy.ts` is imported in `src/index.ts`:
-
-```bash
-grep "credential-proxy" src/index.ts
-```
-
-If it shows an import for `startCredentialProxy`, the native proxy is already active. Skip to Phase 3 (Setup).
-
-### Check if OneCLI is active
-
-```bash
-grep "@onecli-sh/sdk" package.json
-```
-
-If `@onecli-sh/sdk` appears, OneCLI is the active credential provider. Proceed with Phase 2 to replace it.
-
-If neither check matches, you may be on an older version. Run `/update-nanoclaw` first, then retry.
-
-## Phase 2: Apply Code Changes
-
-### Ensure upstream remote
-
-```bash
-git remote -v
-```
-
-If `upstream` is missing, add it:
-
-```bash
-git remote add upstream https://github.com/qwibitai/nanoclaw.git
-```
-
-### Merge the skill branch
-
-```bash
-git fetch upstream skill/native-credential-proxy
-git merge upstream/skill/native-credential-proxy || {
-  git checkout --theirs pnpm-lock.yaml
-  git add pnpm-lock.yaml
-  git merge --continue
-}
-```
-
-This merges in:
-- `src/credential-proxy.ts` and `src/credential-proxy.test.ts` (the proxy implementation)
-- Restored credential proxy usage in `src/index.ts`, `src/container-runner.ts`, `src/container-runtime.ts`, `src/config.ts`
-- Removed `@onecli-sh/sdk` dependency
-- Restored `CREDENTIAL_PROXY_PORT` config (default 3001)
-- Restored platform-aware proxy bind address detection
-- Reverted setup skill to `.env`-based credential instructions
-
-If the merge reports conflicts beyond `pnpm-lock.yaml`, resolve them by reading the conflicted files and understanding the intent of both sides.
-
-### Update main group CLAUDE.md
-
-Replace the OneCLI auth reference with the native proxy:
-
-In `groups/main/CLAUDE.md`, replace:
-> OneCLI manages credentials (including Anthropic auth) — run `onecli --help`.
-
-with:
-> The native credential proxy manages credentials (including Anthropic auth) via `.env` — see `src/credential-proxy.ts`.
-
-### Validate code changes
-
-```bash
-pnpm install
-pnpm run build
-pnpm exec vitest run src/credential-proxy.test.ts src/container-runner.test.ts
-```
-
-All tests must pass and build must be clean before proceeding.
-
-## Phase 3: Setup Credentials
-
-AskUserQuestion: Do you want to use your **Claude subscription** (Pro/Max) or an **Anthropic API key**?
-
-1. **Claude subscription (Pro/Max)** — description: "Uses your existing Claude Pro or Max subscription. You'll run `claude setup-token` in another terminal to get your token."
-2. **Anthropic API key** — description: "Pay-per-use API key from console.anthropic.com."
-
-### Subscription path
-
-Tell the user to run `claude setup-token` in another terminal and copy the token it outputs. Do NOT collect the token in chat.
-
-Once they have the token, add it to `.env`:
-
-```bash
-# Add to .env (create file if needed)
-echo 'CLAUDE_CODE_OAUTH_TOKEN=<token>' >> .env
-```
-
-Note: `ANTHROPIC_AUTH_TOKEN` is also supported as a fallback.
-
-### API key path
-
-Tell the user to get an API key from https://console.anthropic.com/settings/keys if they don't have one.
-
-Add it to `.env`:
-
-```bash
-echo 'ANTHROPIC_API_KEY=<key>' >> .env
-```
-
-### After either path
-
-**If the user's response happens to contain a token or key** (starts with `sk-ant-` or looks like a token): write it to `.env` on their behalf using the appropriate variable name.
-
-**Optional:** If the user needs a custom API endpoint, they can add `ANTHROPIC_BASE_URL=<url>` to `.env` (defaults to `https://api.anthropic.com`).
-
-## Phase 4: Verify
-
-1. Rebuild and restart:
-
-```bash
-pnpm run build
-```
-
-Then restart the service:
-- macOS: `launchctl kickstart -k gui/$(id -u)/com.nanoclaw`
-- Linux: `systemctl --user restart nanoclaw`
-- WSL/manual: stop and re-run `bash start-nanoclaw.sh`
-
-2. Check logs for successful proxy startup:
-
-```bash
-tail -20 logs/nanoclaw.log | grep "Credential proxy"
-```
-
-Expected: `Credential proxy started` with port and auth mode.
-
-3. Send a test message in the registered chat to verify the agent responds.
-
-4. Note: after applying this skill, the OneCLI credential steps in `/setup` no longer apply. `.env` is now the credential source.
-
-## Troubleshooting
-
-**"Credential proxy upstream error" in logs:** Check that `.env` has a valid `ANTHROPIC_API_KEY` or `CLAUDE_CODE_OAUTH_TOKEN`. Verify the API is reachable: `curl -s https://api.anthropic.com/v1/messages -H "x-api-key: test" | head`.
-
-**Port 3001 already in use:** Set `CREDENTIAL_PROXY_PORT=<other port>` in `.env` or as an environment variable.
-
-**Container can't reach proxy (Linux):** The proxy binds to the `docker0` bridge IP by default. If that interface doesn't exist (e.g. rootless Docker), set `CREDENTIAL_PROXY_HOST=0.0.0.0` as an environment variable.
-
-**OAuth token expired (401 errors):** Re-run `claude setup-token` in a terminal and update the token in `.env`.
-
-## Removal
-
-To revert to OneCLI gateway:
-
-1. Find the merge commit: `git log --oneline --merges -5`
-2. Revert it: `git revert <merge-commit> -m 1` (undoes the skill branch merge, keeps your other changes)
-3. `pnpm install` (re-adds `@onecli-sh/sdk`)
-4. `pnpm run build`
-5. Follow `/setup` step 4 to configure OneCLI credentials
-6. Remove `ANTHROPIC_API_KEY` / `CLAUDE_CODE_OAUTH_TOKEN` from `.env`