القائمة
Sync your private fork with public fork(s). Push sanitized changes to a public fork, or pull community contributions back. Triggers on "sync forks", "sync fork", "push to fork", "pull from fork".
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Run Nanoclaw GWS-EA setup. Use when the user wants to install, re-run setup, or import v1 data. Triggers on "setup", "setup gws-ea", "install gws-ea", "import v1", or first-time setup requests on this fork.
Pull community contributions from the nanoclaw-gws-ea public fork back into this private fork, with preview, selective cherry-pick, and low token usage.
Create and edit Google Docs cleanly. Use before any Docs creation or modification — covers the markdown-draft-then-import workflow, structural editing tools, and verification that formatting renders natively (not as literal characters).
OneCLI Gateway: transparent HTTPS proxy that injects stored credentials into outbound calls. You MUST use this skill when the user asks you to read emails, check calendar, access GitHub repos, create issues, check Stripe payments, or interact with ANY external service or API. Do NOT use browser extensions or OAuth CLI tools. Make HTTP requests directly; the gateway injects credentials automatically.
Look up and manage who people are and how to engage them. Use before any substantive interaction (scheduling, email, meetings, outreach). Covers Google Contacts as CRM, tier definitions (1–5), and contact-management thresholds.
Triage and compose email — sender-tier judgment, decision-packet escalation, HTML formatting, and post-send matter updates. Use before sending any email.
| name | sync-forks |
| description | Sync your private fork with public fork(s). Push sanitized changes to a public fork, or pull community contributions back. Triggers on "sync forks", "sync fork", "push to fork", "pull from fork". |
You maintain a private fork (origin) where you work day-to-day, and one or more public forks that the community uses. This skill keeps them in sync — pushing sanitized improvements out, or pulling community contributions back.
The chain is: upstream (community) → your private fork → public fork(s) → end users
Run /sync-forks in Claude Code.
Fork discovery: any git remote that isn't origin (private fork) or upstream (community upstream) is a public fork candidate. One fork skips selection; multiple forks prompts a choice.
Push flow: creates a staging branch from the public fork. Merges upstream individually (preserves community attribution), squashes private fork commits (no private history leaks), runs a privacy scan (hard gate), validates the build, surfaces any upstream breaking changes in the PR description, then opens a PR or pushes directly.
Pull flow: merges the public fork's latest into your private fork. No privacy scanning needed — public → private is safe. Prompts for container rebuild if container files changed. Useful when someone else contributes to your public fork.
Privacy: private files are restored to public fork templates before committing. A grep scan runs as a safety net for anything the manifest doesn't cover. Both happen before the commit, so personal data never enters the public fork's history.
Push is always on a disposable staging branch — your private fork's main is never touched:
git checkout main && git branch -D sync-forks/<fork>/<slug>
Pull creates a backup before merging:
git reset --hard <backup-tag>
Only opens files to apply section restores or fix scan failures. Uses git log, git diff, git status, and git checkout for everything else. Does not scan or refactor unrelated code.
These identifiers drive the safety scan during push.
Push will not proceed if any of these appear in the diff. Auto-fix, re-scan until clean.
# Add your identifiers, one per line. Examples:
# assistant@example.com
# principal@example.com
# sk-ant-XXXXX
# GOCSXX-
# 123456789
# 555-123-4567
# 123 Main St
When scanning, join all uncommented lines into a single grep regex with |.
Flag for review. Fix clear references, ask user about ambiguous ones.
# Add your identifiers, one per line. Examples:
# Assistant Name
# Principal Name
# example\.com
# my-private-fork
When fixing leaks: emails → {ASSISTANT_EMAIL} / {PRINCIPAL_EMAIL}, names → {ASSISTANT_NAME} / {PRINCIPAL_NAME}, tokens/secrets/IDs/phone/address → remove entirely.
Files where your private fork has personal data but the public fork has templates. During push, these are restored BEFORE committing.
Full restore (entire file reverted to public fork's version via git checkout <fork>/<branch> -- <path>):
Section restore (personal sections replaced with public fork's template; generic improvements pass through):
path — ## Start Heading through ## End Heading)Exclude (private-fork-only, unstaged before commit):
.claude/skills/sync-forks/When the safety scan fires on a file not in this list, fix it and add the file here so it's automatic next time.
Safely sync your private fork with public fork(s) — push sanitized improvements out, pull community contributions back — with zero tolerance for personal data leakage on push.
git status, git log, git diff, and open only files that need manifest rules or scan fixes.Run:
git status --porcelain
If output is non-empty:Confirm upstream remote:
git remote -v
If upstream is missing:https://github.com/qwibitai/nanoclaw.git).git remote add upstream <url>Fetch upstream:
git fetch upstream --pruneList all remotes:
git remote -vIdentify public fork candidates: any remote that is NOT origin and NOT upstream. Store the list as FORKS.
If no candidates found:
git remote add <name> <url>If exactly one candidate:
If multiple candidates:
Fetch the selected fork(s):
git fetch <fork> --pruneDetect the fork's default branch:
<fork>/main or <fork>/master.<fork>/main should use <fork>/$FORK_BRANCH instead.Derive the GitHub owner/repo from the remote URL for gh commands:
https://github.com/<owner>/<repo>.git or git@github.com:<owner>/<repo>.gitowner/repo).Show divergence in both directions:
git log --oneline HEAD..<fork>/$FORK_BRANCH (what the fork has that you don't)git log --oneline <fork>/$FORK_BRANCH..HEAD (what you have that the fork doesn't)Ask the user to choose a direction using AskUserQuestion:
<fork><fork> into your private forkIf Abort: stop here. If Pull: jump to Step P1. If Push: continue to Step 3.
Ask the user using AskUserQuestion:
If A: offer to run the appropriate update skill (e.g., /update-nanoclaw), or do a manual git merge upstream/main. After it completes, re-fetch:
git fetch <fork> --prunegit fetch upstream --pruneShow upstream commits not yet in the public fork:
git log --oneline <fork>/$FORK_BRANCH..upstream/mainShow changed files vs the public fork (commit divergence ≠ content divergence — always check the actual diff):
git diff --name-only <fork>/$FORK_BRANCH HEADgit diff --stat <fork>/$FORK_BRANCH HEAD (shows magnitude of changes per file)Categorize each changed file using the Private Files lists from the Privacy Manifest:
src/): core code changescontainer/): Dockerfile, agent-runner changes.claude/skills/): new or updated skillsgroups/): procedure docs, CLAUDE.md filespackage.json, .github/): review neededPresent the categorization to the user and ask them to choose one path using AskUserQuestion:
If Abort: stop here.
Create a staging branch with a descriptive name based on the changes from Step 4:
STAGING=sync-forks/<fork-name>/<short-slug> — e.g., sync-forks/gws-ea/calendar-fixes. Keep to 3-5 words, kebab-case. This becomes the PR branch name.git checkout -b $STAGING <fork>/$FORK_BRANCHThis branch is disposable. All work happens here. Your private fork's main is never modified.
If upstream has no new commits (git log --oneline <fork>/$FORK_BRANCH..upstream/main is empty):
Skip this step.
Dry-run merge to preview conflicts. Run as a single chained command so the abort always executes:
git merge --no-commit --no-ff upstream/main; 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.
Run:
git merge upstream/main --no-editIf conflicts occur:
git status and identify conflicted files.git add <file>git commit --no-editgit merge --no-commit --no-ff main; git diff --name-only --diff-filter=U; git merge --abort
Run:
git merge --squash mainIf conflicts occur:
git status and identify conflicted files.git add <file>.DO NOT commit yet — proceed to Step 8.
All of this runs on the staged but uncommitted squash merge. No commit is created until everything is clean.
Restore private files: For each file in the Private Files lists from the Privacy Manifest:
git checkout <fork>/$FORK_BRANCH -- <path> then git add <path>git show <fork>/$FORK_BRANCH:<path>), extract the section between the two headings, replace that section in the working copy, git add <path>git checkout <fork>/$FORK_BRANCH -- <path>. If not: git rm --cached <path> 2>/dev/nullAlso apply any one-time exclusions from Step 4.
Safety scan (hard gate):
Run on git diff --cached. If the private files list is current, this finds nothing.
Build the hard identifier regex from the Privacy Manifest (all lines in the Hard Identifiers block, joined with |):
git diff --cached | grep -inE '<hard_identifier_regex>'
Build the soft identifier regex from the Privacy Manifest:
git diff --cached | grep -inE '<soft_identifier_regex>'
Hard identifiers: auto-fix, re-scan until clean, suggest adding the file to the private files list. Soft identifiers: fix clear references, ask user about ambiguous ones.
Apply the Replacements rules from the Privacy Manifest when fixing.
DO NOT commit until both scans pass.
Commit: Once the staged diff is clean:
git commit -m "sync: <concise summary>" — draft the message from the actual file changes, not from the private fork's commit log.Also scan commit messages:
git log --format='%s%n%b' <fork>/$FORK_BRANCH..HEAD | grep -inE '<hard_identifier_regex>|<soft_identifier_regex>'
If matches: git reset --soft <fork>/$FORK_BRANCH and recommit with a clean message.
Run:
pnpm run buildpnpm test (do not fail the flow if tests are not configured)If build fails:
Show summary:
git log --oneline <fork>/$FORK_BRANCH..upstream/maingit diff --stat of that commitAsk the user to choose using AskUserQuestion:
git diff <fork>/$FORK_BRANCH..HEAD one more timeIf Abort:
git checkout main && git branch -D $STAGINGIf Create PR:
git diff <fork>/$FORK_BRANCH..upstream/main -- CHANGELOG.md | grep -i '^\+.*\[BREAKING\]'
If any found, include them in the PR body under a Breaking Changes section so end users know what they're getting.git push <fork> $STAGINGgh pr create --repo $FORK_REPO --base $FORK_BRANCH --head $STAGING with a summary of changes. Do NOT include privacy/scan details in the PR body — that's internal workflow, not public information.If Push directly:
git push <fork> HEAD:$FORK_BRANCHSwitch back to main:
git checkout mainIf pushed directly (not PR), delete staging branch:
git branch -d $STAGINGIf PR was created, keep the staging branch alive. Tell the user to delete it after the PR is merged:
git branch -d $STAGING (run after PR is merged)Update local tracking:
git fetch <fork> --pruneShow:
Tell the user:
Capture current state:
HASH=$(git rev-parse --short HEAD)TIMESTAMP=$(date +%Y%m%d-%H%M%S)Create backup branch and tag:
git branch backup/pre-pull-$HASH-$TIMESTAMPgit tag pre-pull-$HASH-$TIMESTAMPSave the tag name for rollback instructions in the summary.
Show what the public fork has that your private fork doesn't:
git log --oneline HEAD..<fork>/$FORK_BRANCHIf the public fork has no new commits:
Tell the user there's nothing to pull. Stop.
Dry-run merge to show what would actually change in your tree. Run as a single chained command so the abort always executes:
git merge --no-commit --no-ff <fork>/$FORK_BRANCH; git diff --stat HEAD; git merge --abort
If the dry-run shows zero or near-zero file changes:
If the diff shows real changes, ask the user to choose one path using AskUserQuestion:
If Abort: stop here.
If Merge all:
git merge <fork>/$FORK_BRANCH --no-editIf Cherry-pick:
git log --oneline HEAD..<fork>/$FORK_BRANCHgit cherry-pick <commits>Run:
pnpm run buildpnpm test (do not fail the flow if tests are not configured)If build fails:
Check if container files changed in the pulled commits:
git diff --name-only <backup-tag-from-step-P1>..HEAD -- container/If changes found:
./container/build.shShow:
Tell the user:
git reset --hard <backup-tag-from-step-P1>backup/pre-pull-<HASH>-<TIMESTAMP>launchctl kickstart -k "gui/$(id -u)/$(source setup/lib/install-slug.sh && launchd_label)"systemctl --user restart "$(source setup/lib/install-slug.sh && systemd_unit)"pnpm run devIf user selected "all" forks in Step 1 (multi-fork pull):