push-memory

name	push-memory
description	Push memory from external repo.
user-invocable	true
allowed-tools	["Read","Write","Edit","Bash"]

push-memory

Persist a general-purpose memory to the ai-config repo from a session whose working repo is something else (a product repo, gha, a data-analysis repo). This is the cross-repo companion to memorize: same routing and voice rules, different delivery.

memorize's commit/push step assumes ai-config is your primary checkout, symlinked into ~/.claude/ by bootstrap.sh, with direct push to main. That breaks when you're elsewhere:

• A session scoped to another repo may not have ai-config checked out at all — the ~/.claude/memories symlink can be absent or dangling.
• Remote/web sessions can often push only to their assigned branch, so a direct push to ai-config's main is rejected (HTTP 403).
• The current git context is the other repo, so a naive commit tangles the memory into that repo's branch and working tree.

So this skill locates (or sidesteps) an ai-config checkout and delivers the memory on its own branch + PR, never touching the repo you're working in.

When this fires

• "push this to ai-config", "add this to ai-config's memory / CLAUDE.md", "remember this globally from here", "record this in ai-config even though we're in <other repo>", "/push-memory".
• Any time you have a standing rule or reference fact worth keeping, the lesson is general (not tied to the repo you're in), and ai-config is not your working repo.

If ai-config is your working repo (you're on its main, symlinked, with push access), use memorize — it's the shorter path. This skill is for the cross-repo case.

First: is it actually a general-purpose memory for ai-config?

Two things route elsewhere before you go further:

• Project-specific fact — a convention or gotcha tied to ONE repo ("this repo renders with renv via R_LIBS_USER"). That belongs not in shared ai-config, but routed by ownership (see memorize); don't push it here: if we own the repo, commit it to that repo's own agent docs (CLAUDE.md, .github/copilot-instructions.md, or whatever it already has) via a PR, falling back to its local Claude project memory (~/.claude/projects/<project-path>/memory/) as short-lived staging only when it has no agent-doc infrastructure yet — in that case, update MEMORY.md in that directory as an index entry, and hand off that a PR adding agent-doc infrastructure to that repo (plus migrating the staged memory there) is still needed. If it's an external repo we don't own, never open a direct PR autonomously — follow upstream-issues (policy check, draft, explicit user approval) and stage in local project memory until approved, updating that directory's MEMORY.md as an index entry too.
• Automated every-time action ("after each commit run X"). Memory can't execute it — that's a hook in settings.json (use update-config). Say so and route it there.

What stays: a general standing rule ("always link PRs in tables") → CLAUDE.md, or a general reference fact ("gh opens a pager — pipe to cat") → a topical file in memories/ (e.g. github.md, git.md, debugging.md -- see memories/MEMORY.md for the full set). These are exactly memorize's two "general" scopes.

Procedure

1. Route + choose the target file using memorize's rules: standing rule → CLAUDE.md; reference fact → the fitting memories/<topic>.md. When you add a new file under memories/, also add a row for it to memories/MEMORY.md (the index). Don't duplicate — if the point is already recorded, update it in place rather than stacking a second copy.

2. Get the current content of the target file(s) so you append in the right place and match the file's voice — and decide your delivery path now, since reading and writing both follow it. In a web/remote session, or with no usable local ai-config checkout, use the GitHub file API (Path A, step 4): read with mcp__github__get_file_contents (owner: the repository owner, repo: ai-config). With a clean local checkout you can branch in, use a local worktree (Path B, step 4): read the file there.

3. Write a concise bullet (one line preferred), matching the file's voice; include the why if it isn't obvious. Never edit files in the repo you're working in — only the ai-config target file(s).

4. Deliver on a dedicated branch + PR. Never push straight to ai-config's main, and never entangle the change with the current repo's branch. Pick the path that fits the session:

   Path A — GitHub file API (remote/web; no local ai-config checkout). The robust default when you're in a web session or lack a clean checkout — it touches no working tree.

   1. Branch off main: mcp__github__create_branch (owner: the repository owner, repo: ai-config, from_branch: main, branch: memory/<slug>). In a web session pinned to its assigned branch, use that assigned branch name instead.
   2. Read each target with mcp__github__get_file_contents (keep the returned sha), edit locally, then write the updated file(s) on the branch — mcp__github__create_or_update_file per file, or mcp__github__push_files for several files in one commit (needed when you also touch memories/MEMORY.md).

Don't

• Don't push a project-specific fact here — it belongs committed to that repo's own agent docs via a PR (its local project memory is short-lived staging only, when it has no agent-doc infrastructure yet), not shared ai-config.
• For the general-memory-to-ai-config path (the case this skill exists for): don't edit or commit anything in the repo you're working in — only the ai-config target file(s). This doesn't apply to the project-specific-fact case above, which commits to the owned repo on purpose — including when that owned repo happens to be the one you're currently working in.
• Don't push straight to ai-config's main, and don't git add -A — stage only the file(s) you wrote.
• Don't run a full session review or touch skill files (that's ums).
• Don't store secrets, tokens, or passwords.

Relationship to other skills

• memorize (remember / always) — the same routing and voice rules for the normal case: ai-config is your working repo, symlinked, and you push to its current branch directly. Reach for memorize there; reach for push-memory when ai-config is not the repo you're in.
• ums — reviews the whole session and may also update skill definitions. push-memory stores exactly one memory the user names; it never scans or edits skills.
• update-config — where an "every-time action" belongs (a hook), since a memory can't execute.
• config-ai — the broader router across skills/agents/memory/hooks/gha capabilities; its Step 3 fallback ladder (issue on target repo, then issue on the current repo for transfer) covers the case one rung past this skill's Path A/B — when the session has no API/branch access to ai-config at all, not just a different working repo.