| name | inc-os:save-system |
| description | Save your work to the system. Review local changes, walk the user through any merge conflicts, then push to origin/main. |
/inc-os:save-system
Review local changes against main, flag anything risky, then sync with origin/main and push.
Arguments
Optional argument shortcuts:
| Argument | Effect |
|---|
everything | Save all pending work, skip the scope question in Step 1.5 |
chat | Save only this chat's work, skip the scope question |
quick | Save everything AND skip the per-file risky review in Step 3 (still show the summary) |
No argument → run the full flow.
When to use
- After making changes you want to ship.
- Before ending a session where you've modified skills, wiki, or other tracked content.
Resolve the knowledge layout
Check the repo layout before any path work:
- If
knowledge/wiki/ exists → knowledge layout: WIKI = knowledge/wiki/, RAW = knowledge/raw/.
- Otherwise → flat layout:
WIKI = wiki/. There is no raw layer.
clients/ exists only in some repos. Run client-routing steps only when the clients/ folder exists; otherwise skip them and route everything through WIKI.
Every WIKI/... path below means the resolved folder (e.g. knowledge/wiki/offers/ in knowledge layout, wiki/offers/ in flat layout).
What counts as "risky"
| Area | Path patterns | Why it's risky |
|---|
| Website (auto-deploys to production) | app/**, public/** | Pushes go live on Vercel on merge to main |
| Brand voice (foundation) | WIKI/brand-voice/** | Every downstream draft reads from this |
| Offers (foundation) | WIKI/offers/** | Every proposal and report reads from this |
| Audience (foundation) | WIKI/audience/** | Every buyer-facing draft reads from this |
| Frameworks | WIKI/frameworks/** | Core methodology patterns |
| Proposal templates | WIKI/proposals/** | Templates feed every client proposal |
| Report templates | WIKI/reports/** | Templates feed every client report |
| Consultants | WIKI/consultants/** | Changes advisor panel feedback |
| Skills | .claude/skills/** | Core workflows |
| Shared settings | .claude/settings.json | Affects Claude Code behavior |
Docs (docs/**) are not risky; client folders (clients/**, when present) likewise, since they churn constantly with working data.
knowledge/raw/** is not risky (immutable additions), but deletions or modifications of existing raw files MUST be flagged. Raw is append-only.
Everything else is not risky and can be pushed without review.
When a risky file matches a foundation path (WIKI/brand-voice/**, WIKI/offers/**, WIKI/audience/**), label it in the summary as (foundation).
Instructions
Step 1: Gather the diff
Run in parallel:
git status --shortgit diff HEAD (unstaged + staged changes)git log --oneline -5 (recent commits for message style)git rev-list --count origin/main..HEAD (unpushed commits)
If there are no changes (clean working tree AND no unpushed commits), tell the user there's nothing to push and stop.
Step 1.5: Choose scope
The diff above includes every uncommitted change in the working tree, not just what this chat touched. Default to saving everything. Never ask the user to pick individual files.
Always show a summary of what's been worked on — describe the work, not the files. Group changes into short bullets like "what was being worked on", inferred from the diff (file purpose, commit-style verbs). Skip file paths in this summary.
Work pending save:
This chat:
• Added scope prompt to save-system skill
Earlier, unpushed:
• Tax return email tweaks
• Hogan 360 framework edits
• Stale build artifact
Rules:
- One bullet per coherent piece of work, not per file. Several files in the same feature collapse into one bullet.
- Files Claude edited in this conversation go under "This chat".
- Everything else goes under "Earlier, unpushed".
- If you cannot confidently split this-chat vs earlier (long compacted session, no tool trace), drop the split. Show one flat "Work pending save" list and skip the scope prompt entirely — default to saving everything.
Then ask (only if the split is known, and no scope argument was given) with the AskUserQuestion tool:
"Save everything, or only this chat's work?"
- Everything (Recommended) — save all pending work
- Just this chat — earlier unpushed work stays local for now
Everything → proceed to Step 2 with all changes.
Just this chat → narrow the change set to files Claude edited this conversation. At Step 4 stage only those paths (git add <paths>), not git add -A. Earlier unpushed changes stay in the working tree. Mention this in Step 7's confirmation.
Step 2: Classify changes
Use the risky-path table above. Split every changed file into two buckets:
- Risky - matches any path pattern in the table
- Safe - everything else
Present a summary:
Changes to push:
SAFE (N files)
• clients/acme/sessions/2026-05-12.md — new session log
• docs/playbooks/intake-call.md — playbook tweak
RISKY (N files)
• knowledge/wiki/audience/icp.md — (foundation)
• knowledge/wiki/brand-voice/voice.md — (foundation)
• knowledge/wiki/frameworks/hogan-360/scoring.md — modified framework
• .claude/skills/ingest-source/SKILL.md — changed ingest workflow
• app/page.tsx — website change, auto-deploys on merge
Step 3: Handle risky changes
If there are no risky files, skip to Step 4.
If the quick argument was given, show the risky summary but skip the per-file review and proceed to Step 4.
Otherwise, for each risky file:
- Show the diff for that file
- Explain what changed and why it matters (e.g., "This removes the 'Johnny' persona from ICP, which means future scripts won't reference that audience segment")
- Ask with the AskUserQuestion tool: "Keep this change, modify it, or revert it?"
- Keep — proceed as-is
- Modify — work with the user to adjust the change, then re-diff
- Revert —
git checkout -- <file> to undo that specific file
After resolving all risky files, re-run git status to confirm the final state.
Step 4: Commit (if needed)
If there are uncommitted changes:
- Stage files based on the scope chosen in Step 1.5:
- Everything: stage all remaining files
- Just this chat's changes: stage only the files in the session-scoped list (
git add <paths>), leave the rest alone
- Write a concise commit message following the repo's style (look at recent
git log)
- Commit
Step 5: Pre-push sync check
Before pushing, check if origin/main has moved ahead:
git fetch origin main --quiet
BEHIND=$(git rev-list --count HEAD..origin/main)
If BEHIND = 0, proceed directly to Step 6.
If BEHIND > 0, origin is ahead — walk through the divergence interactively:
-
Show the user what's on origin that we don't have:
git log HEAD..origin/main --oneline
-
Offer to rebase:
"Origin/main has N commit(s) we don't have locally. I'll rebase your local commits on top of origin/main. Want to proceed?"
-
On confirmation, run:
git pull --rebase --autostash origin main
-
If rebase succeeds cleanly, proceed to Step 6.
-
If rebase hits conflicts, stop immediately. Show the conflict state:
git status
git diff --diff-filter=U
Then walk through each conflicted file one at a time:
- Show the conflict markers for the file
- Explain what each side (ours vs theirs) is trying to do
- Suggest the most likely resolution and ask with the AskUserQuestion tool: "Accept ours, accept theirs, merge manually, or skip this file for now?" (put the suggested resolution first, marked Recommended)
- For accepted resolutions:
git add <file> and move to the next conflict
- After all conflicts are resolved:
git rebase --continue
- If a conflict cannot be resolved in chat (e.g., complex code merge), surface the file path, show both versions, and pause:
"This conflict in <file> needs manual resolution. Open it in your editor, fix the conflict markers, then run git add <file> && git rebase --continue. Let me know when you're done and I'll resume."
-
NEVER use git push --force or git push --force-with-lease. If the push would require a force, stop and explain why, then help the user understand what diverged.
Step 6: Push
git push origin main
If push is denied by a permission rule (e.g., "Direct push to main"):
- If auto mode is active, tell the user:
"Push got denied by a permission rule. Auto mode is on, so I can't get an interactive approval. Switch off auto mode (shift+tab), then say 'retry' and I'll push again."
- Then stop and wait. Do not retry the push until the user confirms.
- If push is denied and auto mode is not active, the user already denied it manually. Do not retry. Ask what they want to do instead (e.g., open a PR, keep the commit local).
- If the denial reason mentions "permission denied" from the remote itself (not a local Claude Code rule), the PAT may have been revoked. Tell the user to contact Austin for a fresh install URL.
Step 7: Confirm
Pushed to main (N commits).
Changes:
• <grouped summary of what shipped>
Edge cases
- Push fails (auth, network): Show the error. Suggest
git push origin main again after checking credentials.
- Push denied by Claude Code permission rule + auto mode on: See Step 6. Tell the user to turn off auto mode and retry. Do not silently re-attempt.
- Rebase aborted by user: Run
git rebase --abort to restore the pre-rebase state. Nothing is lost.
- Mixed risky + safe: Only the risky files get interactive review. Safe files flow through automatically.
- User wants to override all risk warnings: That's fine. If they say "just push it" or "skip review", respect that and proceed to Step 4.
What this skill does NOT do
- Does not pull from main without committing first. Use
/inc-os:update-system for a pure sync.
- Does not run tests or builds.
- Does not force-push or rewrite history.
