dotfiles: claude: add ajay-handoff + ajay-resume handoff commands

Enable handing off in-progress work between machines (home/office/laptop):
- /ajay-handoff: write/update cross-machine handoff docs in .session-handoff/ (docs-only) before leaving a machine
- /ajay-resume: read + reconcile those docs on the destination machine, then continue
- /ajay-ship: place handoff docs in the same commit as WIP, or an isolated commit atop a diff stack
- CLAUDE.md: refresh the commands list (adds ajay-init/ajay-handoff/ajay-resume)

Author: ajay

CLAUDE.md

@@ -56,7 +56,7 @@ Steps can be skipped with `--except` flags (used by install-dev/lite/no-chef tar
 
 ## Dotfiles Layout
 
-Files under `dotfiles/` are symlinked to their home-directory locations by dotbot. The mapping is defined in `dotbot.conf.yaml` under the `link` section — only paths listed there are linked. `dotfiles/claude/settings.json` is symlinked to `~/.claude/settings.json` (the user-layer settings for Claude Code). `dotfiles/claude/commands/` is symlinked to `~/.claude/commands/` and contains custom slash commands (ajay-flockboss, ajay-inspect-commit, ajay-ship).
+Files under `dotfiles/` are symlinked to their home-directory locations by dotbot. The mapping is defined in `dotbot.conf.yaml` under the `link` section — only paths listed there are linked. `dotfiles/claude/settings.json` is symlinked to `~/.claude/settings.json` (the user-layer settings for Claude Code). `dotfiles/claude/commands/` is symlinked to `~/.claude/commands/` and contains custom slash commands: `ajay-init` (read-only session bootstrap), `ajay-inspect-commit` (inspect the current commit/stack), `ajay-ship` (generate a stage/commit/push script), `ajay-handoff` (write cross-machine handoff docs into `.session-handoff/`), `ajay-resume` (resume work from those handoff docs on another machine), and `ajay-flockboss` (flockboss project pointer).
 
 ## Identity split: git vs hg
 

dotfiles/claude/commands/ajay-handoff.md

@@ -0,0 +1,42 @@
+Generate or update cross-machine handoff docs in `.session-handoff/` so work in this repo can be resumed in a fresh Claude Code session on another machine (home, office, laptop, devserver). Captures the ground-truthed current state, the single most important next action, the session narrative, key context/gotchas, and open work. This command writes docs ONLY — it never commits or pushes; run `/ajay-ship` afterward to commit them (it knows where handoff docs belong in a commit/stack), and `/ajay-resume` on the destination machine to pick them up.
+
+**Be thorough and accurate.** A fresh session on another machine will have ONLY these docs (plus synced memories) — no transcript, no session context. Ground-truth every fact from the repo; do not write from memory.
+
+## Arguments
+
+`/ajay-handoff [<note>]`
+
+- No argument → infer the handoff from the current session + repo state.
+- Argument → a free-text steer: what to emphasize, the intended next focus, or which work is in flight. Weave it into the RESUME doc.
+
+## Steps
+
+1. **Detect the VCS + repo root** by walking upward: `.git` → git, `.sl` → sl, `.hg` → hg. The handoff dir is `<repo-root>/.session-handoff/`. Follow the repo's source-control rules (e.g. a Meta `sl`/`jf` repo: `--reason` on every `sl`, never push with `jf`).
+
+2. **Assess existing handoff docs.** If `.session-handoff/` exists, read its `README.md` + the current START-HERE doc to learn the structure, naming/numbering convention, and what is now stale. If it doesn't exist, you will create it (a `README.md` + the first RESUME doc) following the convention in step 6.
+
+3. **Ground-truth the current state — from the repo, not memory.** Capture real values:
+   - VCS: branch/bookmark, the commit/diff stack (`git log --oneline` + `git status`; or `sl ssl`), exact short hashes + diff numbers (e.g. D-numbers) + links to the in-flight diff(s)/PR(s), what is pushed vs local-only, the base/remote it sits on, and dirty/untracked files.
+   - Work in flight: the precise files/diffs being changed and why.
+   - Health: the latest build/test/CI/lint status you can verify — run a quick check or cite the last verified result; never assert "green" without basis.
+
+4. **Capture the session narrative** — the part only this session knows: what was done and why, decisions made, approaches ruled out (so the next session won't repeat them), and anything surprising.
+
+5. **Ask the user if the resume intent is ambiguous** (only if genuinely unclear): the single next action, what's in flight, any pending decisions, and anything that must NOT be redone. Skip the questions if the session already makes these obvious.
+
+6. **Write / update the docs** in `.session-handoff/`:
+   - **START-HERE RESUME doc** — a NEW dated, self-contained file (e.g. `NN-RESUME-<YYYY-MM-DD>-<slug>.md`, continuing any existing numbering). Lead with a one-line TL;DR + the **single next action**, then: current state (ground-truthed, with real hashes/D-numbers/branch + links to the in-flight diff(s)/PR(s)), what was done this session, key context/gotchas/decisions, build/run/test/flash commands **plus any machine-specific prerequisites that may differ across machines** (toolchain versions, `sl`/`--reason` setup, required hardware/device presence — e.g. an attached dev board), constraints + tooling rules, and open/deferred work. Make the doc **self-locating**: state the repo root and an explicit line such as `To continue: run /ajay-resume in <repo-root>` so a cold reader on another machine knows exactly how to pick up. Next-action-first and scannable.
+   - **`README.md` index** — repoint "START HERE" at the new RESUME doc; keep a short reverse-chronological pointer to recent docs + an index of the stable/reference docs. If creating it fresh, establish that layout.
+   - **Append-only** — never rewrite or delete prior docs; add a one-line `> ⚠️ SUPERSEDED (<date>) — see <doc>` banner to any the new doc overtakes.
+
+7. **Stop — do NOT commit or push.** The docs are working-copy changes. Tell the user to run **`/ajay-ship`** to commit them (it handles placement: folded into the current WIP commit, or an isolated commit on top of a diff stack). On the destination machine they run **`/ajay-resume`**.
+
+## Constraints
+
+- **Docs only.** Never commit, never push, never run SSH/remote-write ops (committing is `/ajay-ship`'s job; pushing is always the user's — see the `feedback_no_ssh_operations` memory).
+- **Ground-truth every fact** (hashes, D-numbers, branch, CI) from the live repo. Memories and prior docs reflect a past moment and may be stale — verify, then write.
+- **The RESUME doc must be self-contained** — assume the reader has zero prior context.
+- **Match the repo's existing `.session-handoff/` conventions** if present; otherwise create `README.md` + the first numbered RESUME doc.
+- **Append, don't overwrite** history; supersede with banners. Keep it lean — the README points to the current + recent docs, and the RESUME doc captures what's needed to resume (link out for the rest) rather than dumping unbounded narrative.
+- **Lead with the next action** — a resumer should know what to do within the first few lines.
+- Do not write auto-memory notes; the handoff travels via the committed docs.

dotfiles/claude/commands/ajay-resume.md

@@ -0,0 +1,25 @@
+Resume work in this repo on this machine from handoff docs left by `/ajay-handoff` — read `.session-handoff/` (README → the START-HERE RESUME doc), reconcile it against the live repo, and pick up exactly where the other machine left off. Use when you arrive at a machine (home, office, laptop, devserver) to continue work handed off from another. The counterpart to `/ajay-handoff`.
+
+**ULTRATHINK.** Load the full handoff context before acting. The RESUME doc is the source of *intent*; the live repo is the source of *truth* — reconcile both and flag any drift.
+
+## Steps
+
+1. **Detect the VCS + repo root** (`.git`/`.sl`/`.hg`, walking upward). Follow the repo's source-control rules (e.g. a Meta `sl` repo needs `--reason` on every command).
+
+2. **Make sure the handoff is present.** If `.session-handoff/` is missing — or looks older than the remote — the handoff commit may not be local yet. You cannot fetch it yourself (the agent has no SSH keys — see the `feedback_no_ssh_operations` memory): give the user the exact command to run (`git pull` / `sl pull`, per the repo) and wait for them, then re-check. If `.session-handoff/` still doesn't exist after that, fall back to `/ajay-init` (general bootstrap).
+
+3. **Read the handoff, in order:** `.session-handoff/README.md` → the doc its "START HERE" names (the RESUME doc) IN FULL → any recent docs it points to (skip ones carrying a `SUPERSEDED` banner unless you need the history). Also load the relevant auto-memory index for this repo.
+
+4. **Ground-truth + reconcile.** First sanity-check that the START-HERE doc belongs to THIS repo/branch lineage (not a doc for a different stack); if the README's "START HERE" pointer is dangling or points to a superseded doc, use the newest RESUME doc instead and flag it. Then compare the doc's claimed state against the LIVE repo (branch/stack/commits, real hashes/D-numbers, pushed vs local, dirty files, build/CI). Work may have advanced since the doc was written — **flag any drift; trust the repo over the doc on facts.**
+
+5. **Brief the user:** where things stand (one paragraph), the **decisive next action** (from the doc, validated against the repo), the key context/gotchas/decisions to honor, and the open/deferred work. Cite the RESUME doc + the real repo facts.
+
+6. **Confirm the next move** with `AskUserQuestion`: proceed with the doc's next action (recommended, restated concretely), or pick a different focus. Then begin the work.
+
+## Constraints
+
+- **Read-only orientation** — no edits, commits, or `/tmp` scripts during resume (like `/ajay-init`). Start the actual work only after the user confirms in step 6.
+- **The live repo overrides the doc** on any factual conflict; surface drift rather than trusting a possibly-stale doc.
+- **Don't re-derive what the handoff already settled** — ruled-out approaches, decisions, root causes. Trust them (verify cheaply), don't repeat the investigation.
+- **Never push, pull, or run any SSH/remote op yourself** (the agent has no SSH keys — `feedback_no_ssh_operations`); if a pull is needed to fetch the handoff, hand the command to the user and wait.
+- If there's no `.session-handoff/`, defer to `/ajay-init` (general bootstrap).

dotfiles/claude/commands/ajay-ship.md

@@ -18,6 +18,8 @@ Generate a `/tmp` shell script that will stage, commit, and (for git) push the u
 
 3. **Identify the intended files for this commit.** Default to every modified/added/deleted/untracked path. If the diff contains files that look unrelated to the dominant theme of the change (e.g. a stray edit in an unrelated subtree, or untracked scratch files), ask the user via `AskUserQuestion` which group(s) to include before continuing. Any file that's dirty in the working tree but NOT going into this commit must be listed under "Files NOT staged" in the script header so the user can spot drift.
 
+   **Handoff docs (`.session-handoff/`, written by `/ajay-handoff`):** place these deliberately. If there are other changes too, include `.session-handoff/` in the SAME commit as the work (one commit carries the change plus its handoff snapshot). If the handoff docs are the ONLY change and the repo has a diff/commit stack, put them in their OWN isolated commit on TOP of the stack — do not fold them into a mid-stack diff (the isolated commit's commit step targets only `.session-handoff/`; make sure the working copy is at the stack top so it lands on top rather than inserted mid-stack). When it's ambiguous which applies, ask the user via `AskUserQuestion`. Push: for git, the handoff docs follow the normal push confirmation (never push without it); for sl/hg there is no push step (review goes through `arc diff` separately).
+
 4. **Draft a commit message** that matches the repo's recent style. Read the last ~20 commits and copy the convention you see — for example, the dotfiles repo uses `<scope>: <short subject>` with an optional bulleted body explaining the *why* (not the *what*). Don't invent a style. The subject should be short (≤72 chars); the body is optional and used only when the change has non-obvious motivation worth recording. For large repos (such as a monorepo), inspect current changes in the relevant project or current directory; it will not be useful to look at overall last ~20 commits. Always use lowercase for the first word after the scope prefix — e.g. `[nrf54h20] add ...` not `[nrf54h20] Add ...`, `dotfiles: fish: add ...` not `dotfiles: fish: Add ...`.
 
    For repos that use a Test Plan field (e.g. fbsource/Phabricator), populate it with a minimal fenced code block listing the relevant commands (existing and new) that a reviewer can copy-paste to reproduce. No prose — just the commands. After the commands block, add a blank output block for the user to paste results into, with a tiny note like `<output of: `command`>`. If you can predict what the output will be, prepopulate it as expected output (clearly marked as "expected", not actual). If the change modifies behavior of an existing command, use before/after sections. Example: