Menu
Efficiently bring upstream NanoClaw updates into a customized install, with preview, selective cherry-pick, and low token usage.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Redactar escritos jurídicos mexicanos largos (recursos de apelación, demandas, contestaciones, amparos) a partir de varios documentos de un expediente (demanda, contestación, pericial, confesional, sentencia), entregados como .docx editable. Úsalo cuando el usuario pida "recurso de apelación", "redacta el escrito", "haz la demanda/contestación en Word", o cualquier pieza procesal larga que deba correlacionar agravios/hechos con documentos fuente y jurisprudencia verificada.
Sintetizar o redactar un entregable a partir de varios documentos fuente (o pocos muy grandes) que juntos NO caben en la ventana de contexto — reportes multi-fuente, due diligence, análisis/comparación de contratos, resúmenes de expediente, investigación. Úsalo cuando debas correlacionar información entre múltiples documentos y producir un documento nuevo, y leerlos todos completos reventaría el contexto ("Prompt is too long"). NO es para leer un solo documento corto.
Busca y descarga assets de diseño (iconos, ilustraciones, 3D, animaciones Lottie, imágenes AI) desde IconScout. Dispara cuando el user pida un icono/ilustración/animación para un diseño, mockup, presentación o web, o mencione IconScout. 13.8M+ assets con licencia royalty-free.
Text-to-speech with Spanish voices (Kokoro, local & free) and OpenAI fallback
Transcribe a texto el HABLA de un audio largo o pesado (reuniones, notas de voz reenviadas, grabaciones de 10–60+ min). Trocea con ffmpeg y transcribe cada parte con Whisper, sin toparse con el límite de 25MB de la API. Úsala cuando llegue un [Audio file: ...] y el usuario pida "transcribe", "qué dice", "analiza el audio", o para resumir/analizar una grabación de voz.
Haz una versión nueva/ejecutiva/más limpia de un documento institucional (PDFs tipo "orden del día", agendas, hojas de evento, programas) MINANDO sus assets reales (logos, fotos de ponentes, texto, fuentes) y RECONSTRUYENDO en HTML — nunca re-difundiendo la página como imagen. Úsala ante "haz una nueva versión", "versión ejecutiva", "rehazlo más limpio", "adáptalo" de un PDF.
| name | update-nanoclaw |
| description | Efficiently bring upstream NanoClaw updates into a customized install, with preview, selective cherry-pick, and low token usage. |
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.
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:
.claude/skills/): unlikely to conflict unless you edited an upstream skillsrc/): may conflict if you modified the same filespackage.json, tsconfig*.json, container/): review neededUpdate 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 npm run build and npm 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.
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.
Only opens files with actual conflicts. Uses git log, git diff, and git status for everything else. Does not scan or refactor unrelated code.
Help a user with a customized NanoClaw install safely incorporate upstream changes without a fresh reinstall and without blowing tokens.
git status, git log, git diff, and open only conflicted files.Run:
git status --porcelain
If output is non-empty:Confirm remotes:
git remote -v
If upstream is missing:https://github.com/qwibitai/nanoclaw.git).git remote add upstream <user-provided-url>git fetch upstream --pruneDetermine the upstream branch name:
git branch -r | grep upstream/upstream/main exists, use main.upstream/master exists, use master.upstream/main should use upstream/$UPSTREAM_BRANCH instead.Fetch:
git fetch upstream --pruneCapture 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-$TIMESTAMPgit tag pre-update-$HASH-$TIMESTAMPSave the tag name for later reference in the summary and rollback instructions.
Compute common base:
BASE=$(git merge-base HEAD upstream/$UPSTREAM_BRANCH)Show upstream commits since BASE:
git log --oneline $BASE..upstream/$UPSTREAM_BRANCHShow local commits since BASE (custom drift):
git log --oneline $BASE..HEADShow file-level impact from upstream:
git diff --name-only $BASE..upstream/$UPSTREAM_BRANCHBucket the upstream changed files:
.claude/skills/): unlikely to conflict unless the user edited an upstream skillsrc/): may conflict if user modified the same filespackage.json, package-lock.json, tsconfig*.json, container/, launchd/): review neededBefore picking a strategy, measure how much the fork already diverges from upstream on the files upstream is about to touch. High divergence = high conflict risk.
For each file in the upstream changeset, compute line-count divergence:
git diff --shortstat upstream/$UPSTREAM_BRANCH...HEAD -- <file>Identify the top 5 most-diverged files and present them as hotspots to the user. Examples from real NanoClaw forks: src/channels/whatsapp.ts, src/index.ts, src/credential-proxy.ts, container/agent-runner/src/index.ts. Flag any hotspot that upstream commits touch — those are the likely-conflict commits.
Before recommending a strategy, check for two traps:
Duplicates — commits the fork already merged under a different SHA. Upstream subjects may be identical to local commits:
git log HEAD --oneline --since="6 months ago" | awk -F' ' '{$1=""; print $0}' | sort > /tmp/local-subjects.txtgit log $BASE..upstream/$UPSTREAM_BRANCH --oneline | awk -F' ' '{$1=""; print $0}' | sort > /tmp/upstream-subjects.txtcomm -12 /tmp/local-subjects.txt /tmp/upstream-subjects.txtFor each subject match, verify with a grep for a distinctive token from the commit (e.g., a new field name, a class name). If confirmed duplicate, exclude from the cherry-pick list and note it in the summary.
Architectural conflicts — upstream commits that rewrite a hotspot file end-to-end (50%+ of lines). These can't be safely cherry-picked without a separate design decision:
git show --shortstat <sha> → compute (insertions+deletions) / total-lines-in-target-file.Present these buckets to the user and ask them to choose one path using AskUserQuestion:
If Abort: stop here.
If Full update or Rebase:
git merge --no-commit --no-ff upstream/$UPSTREAM_BRANCH; git diff --name-only --diff-filter=U; git merge --abort
Run:
git merge upstream/$UPSTREAM_BRANCH --no-editIf conflicts occur:
git status and identify conflicted files.git add <file>git commit --no-editIf user chose Selective:
BASE=$(git merge-base HEAD upstream/$UPSTREAM_BRANCH)git log --oneline $BASE..upstream/$UPSTREAM_BRANCHgit log --no-merges). Merge commits fail without -m <parent>; almost always the feature commit from the PR branch is the one to pick, not the merge.git cherry-pick <hash1> <hash2> ...If conflicts during cherry-pick:
git add <file>git cherry-pick --continue
If user wants to stop:git cherry-pick --abortLockfile conflicts (package-lock.json, package-lock.json under subpackages):
git checkout --theirs package-lock.json && npm installgit add package-lock.json && git cherry-pick --continueBuild-config conflicts (Dockerfile, tsconfig.json):
docker build (if Dockerfile) or npx tsc --noEmit (if tsconfig) after resolving, before --continue.Type-chain cherry-picks (commits that add/move fields across files):
npx tsc --noEmit (host) AND (cd container/agent-runner && npx tsc --noEmit). Catches interface drift that npm run build at the end would bury under many errors.fix(types): ... commit rather than amending the cherry-pick. Keeps upstream SHAs cleanly traceable.Cascade conflicts (same file conflicts on 2+ consecutive commits):
git diff HEAD~..HEAD -- <file> to confirm the resolution applied cleanly.git cherry-pick <A>^..<B> which may auto-rebase them together.Run:
git rebase upstream/$UPSTREAM_BRANCHIf conflicts:
git add <file>git rebase --continue
If it gets messy (more than 3 rounds of conflicts):git rebase --abortRun:
npm run buildnpm test (do not fail the flow if tests are not configured)If build fails:
fix(types): ... commit (see Step 4B type-chain guidance). Don't amend a cherry-picked SHA.If the update introduced ESLint (or any lint tool the fork didn't previously have):
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.mdParse the diff output for lines starting with +[BREAKING]. Each such line is one breaking change entry. The format is:
[BREAKING] <description>. Run `/<skill-name>` to <action>.
If no [BREAKING] lines are found:
If one or more [BREAKING] lines are found:
/<skill-name> part).multiSelect: true so the user can pick multiple skills if there are several breaking changes.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:
/update-skills using the Skill tool.Show:
git rev-parse --short HEADgit rev-parse --short upstream/$UPSTREAM_BRANCHgit diff --name-only upstream/$UPSTREAM_BRANCH..HEADTell the user:
git reset --hard <backup-tag-from-step-1>backup/pre-update-<HASH>-<TIMESTAMP>launchctl unload ~/Library/LaunchAgents/com.nanoclaw.plist && launchctl load ~/Library/LaunchAgents/com.nanoclaw.plistnpm run devReal dolor points this protocol update addresses:
4 of 14 targeted commits were duplicates (already merged locally under different SHAs). Detected by commit-subject match: ee599b9 (reply context) matched local 8023342; db3440f/f77f9ce (SDK + threshold) matched package.json / agent-runner state; 67020f9 (session cleanup) matched existing src/session-cleanup.ts. Without Step 2.6, these would have wasted 20+ minutes of cherry-pick attempts.
Architectural conflict averted on OneCLI (e936961). Upstream replaced src/credential-proxy.ts wholesale; fork had 760 lines of custom OAuth + fallback + Vault logic. Categorized as "architectural" via Step 2.6's 50% rewrite heuristic, skipped, documented as debt in memory. Keeps the door open to evaluate OneCLI in a dedicated session rather than pretending it's a regular cherry-pick.
Lockfile conflict on ESLint (30ebcaa). Merge markers in package-lock.json are unresolvable by hand. Recipe: git checkout --theirs package-lock.json && npm install.
Merge commit in cherry-pick list (b2fa85b for channel-formatting). Failed with "is a merge but no -m option was given". The feature commit (7bba21a) was the right pick. Step 4B's --no-merges filter prevents this.
Type drift across a 4-commit chain (scheduled-task script field: 675acff → 42d098c → 0f283cb → 9f5aff9). Upstream commits passed script through the call chain assuming interfaces supported it; fork's ContainerInput (both host and agent-runner) didn't. Final npm run build caught it; intermediate tsc --noEmit would have caught it at the first commit. Fixed via a separate fix(types): commit rather than amending upstream SHAs.
Fork hotspots known upfront changed the whole strategy. Listing credential-proxy.ts (+713), whatsapp.ts (+1044), index.ts (+986), agent-runner/index.ts (+447) before picking a strategy made the user's decision about OneCLI obvious before any git operation ran.