From b6eaf31b0a0eea7d10b8900b015ad01375737e67 Mon Sep 17 00:00:00 2001 From: Gregory Linscheid Date: Mon, 3 Aug 2026 23:47:04 -0700 Subject: [PATCH 1/4] :sparkles: Use C-Space tmux prefix in ssh/mosh sessions In nested tmux (local C-b outer, remote inner), the remote prefix becomes C-Space so hotkeys need no doubled C-b. Detection keys on SSH_CONNECTION, which mosh sessions inherit from the bootstrap ssh. Co-Authored-By: Claude Fable 5 --- tmux/.tmux.conf | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/tmux/.tmux.conf b/tmux/.tmux.conf index 58e70f7..888215c 100644 --- a/tmux/.tmux.conf +++ b/tmux/.tmux.conf @@ -1,3 +1,11 @@ +# Remote (ssh/mosh) sessions use C-Space as prefix, so the local C-b doesn't +# need doubling to reach nested tmux; mosh sets SSH_CONNECTION but not SSH_TTY +if-shell 'test -n "$SSH_CONNECTION" || test -n "$SSH_TTY"' { + unbind C-b + set -g prefix C-Space + bind C-Space send-prefix +} + # Address vim mode switching delay set -sg escape-time 0 From f517a9aeb5fdcfb3b98fc54ebda4aeaf88ecfbc8 Mon Sep 17 00:00:00 2001 From: Gregory Linscheid Date: Mon, 3 Aug 2026 23:47:04 -0700 Subject: [PATCH 2/4] :memo: Always use native GitHub stacked PRs for branch chains MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Global agent instructions for the gh-stack workflow: when PRs would chain (A->main, B->A), use native stacks — covers commands, merge and rebase semantics, and preview limits. Co-Authored-By: Claude Fable 5 --- claude-md/.claude/CLAUDE.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/claude-md/.claude/CLAUDE.md b/claude-md/.claude/CLAUDE.md index 5f18100..293f2d7 100644 --- a/claude-md/.claude/CLAUDE.md +++ b/claude-md/.claude/CLAUDE.md @@ -122,6 +122,42 @@ Don't ask for trivial one-offs, quick lookups, or single-file edits. --- +## GitHub stacked PRs (use the native feature) + +**The rule:** whenever work forms a chain of dependent branches — branch A targeting `main`, branch B targeting A, C targeting B — **always use GitHub's native stacked pull requests**, never ad-hoc chained PRs or manual base-branch juggling. The trigger is simple: if you're about to open a PR whose base is another open PR's branch, make it a native stack instead. Independent changes are not a stack — keep those as separate PRs against `main`. + +**Tooling:** the official `gh-stack` extension (needs GitHub CLI ≥ 2.90.0, Git ≥ 2.20): + +```sh +gh extension install github/gh-stack # one-time setup +gh skill install github/gh-stack # agent skill: install when doing heavy stack work +``` + +**Core workflow:** + +```sh +gh stack init # start a stack; names the bottom branch +gh stack add # new branch on top of the current layer (-Am "msg" stages + commits too) +gh stack submit # push all branches and create/update PRs with correct bases + stack link +gh stack view # branches, PR links, statuses across the stack +gh stack sync # fetch, cascading rebase, push, sync PR state — one command +gh stack merge # merge one or multiple layers +gh stack link # adopt existing branches/PR chains into a native stack +``` + +**Semantics to respect (don't fight them manually):** + +- Stacks merge **bottom-to-top**. Merging a mid-stack PR also merges everything below it in one operation. The PRs above stay open, **auto-retarget** to the trunk, and GitHub **automatically rebases** the next unmerged PR server-side — never hand-edit the base branch of a stacked PR. Your **local** branches don't follow along, though: run `gh stack sync` after a merge to pull down the rewritten branches and prune merged ones. +- **Other drift is NOT auto-rebased.** If the trunk moves ahead or you push changes to a lower layer, the stack goes non-linear and merging is blocked until you explicitly rebase: the **Rebase stack** button in the merge box (server-side), or locally `gh stack rebase --upstack` after amending a lower layer / `gh stack rebase` for trunk drift. Don't hand-`git rebase` each branch in the chain. +- Branch protection and CI requirements come from the **bottom PR's base branch** and apply to every layer. +- Public-preview limits: all branches must live in the **same repository** (no cross-fork stacks), and programmatic merges must go through `gh stack merge` / the new merge API — not the classic merge endpoint. + +**Adopting an existing chain:** if a traditional stack already exists (PRs manually chained by base branch), convert it with `gh stack link` instead of continuing to manage it by hand. + +**Fallback:** if `gh-stack` truly isn't available (old `gh`, extensions blocked), note that briefly, then fall back to manually chained PRs with explicit bases and a "depends on #N" note in each PR description — but treat this as the exception, not a preference. + +--- + ## Checking Woodpecker CI failures (greg-zone) Greg's personal repos — those under the **`Vilos92`** GitHub user (e.g. `Vilos92/dotfiles`, `Vilos92/scriptlancer`) — run CI on a self-hosted **Woodpecker** instance at **`http://greg-zone:9011`** (Tailscale-only). GitHub shows a single status per pipeline (e.g. **`ci/woodpecker/pr/woodpecker`**) with **no logs behind it**—the per-step results and logs live in Woodpecker. When a PR's Woodpecker check fails, fetch the failure yourself instead of asking for a paste. From cc2a40fca4df5a82c6bcce4da5ed71dcf7bee432 Mon Sep 17 00:00:00 2001 From: Gregory Linscheid Date: Mon, 3 Aug 2026 23:51:52 -0700 Subject: [PATCH 3/4] :wrench: Turn off CodeRabbit auto-reviews Match scriptlancer: reviews on request only, no auto-review per PR. Co-Authored-By: Claude Fable 5 --- .coderabbit.yaml | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/.coderabbit.yaml b/.coderabbit.yaml index a4db035..92eca8b 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -7,10 +7,7 @@ reviews: review_status: true review_details: false auto_review: - # Unlike scriptlancer, dotfiles keeps automatic reviews on — CodeRabbit - # already reviews every PR here and that behavior should survive adopting - # this config. - enabled: true + enabled: false drafts: false chat: auto_reply: true From aa9367737962e4a936299b76b88d418b0cbe0e77 Mon Sep 17 00:00:00 2001 From: Gregory Linscheid Date: Mon, 3 Aug 2026 23:56:40 -0700 Subject: [PATCH 4/4] :memo: Correct gh-stack prerequisites, link semantics, and sync pruning Per the gh-stack README: gh CLI v2.0+ (no git minimum), gh stack link is remote-only linking with no local tracking, and sync prompts before pruning unless --prune is passed. Co-Authored-By: Claude Fable 5 --- claude-md/.claude/CLAUDE.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/claude-md/.claude/CLAUDE.md b/claude-md/.claude/CLAUDE.md index 293f2d7..a9de59a 100644 --- a/claude-md/.claude/CLAUDE.md +++ b/claude-md/.claude/CLAUDE.md @@ -126,7 +126,7 @@ Don't ask for trivial one-offs, quick lookups, or single-file edits. **The rule:** whenever work forms a chain of dependent branches — branch A targeting `main`, branch B targeting A, C targeting B — **always use GitHub's native stacked pull requests**, never ad-hoc chained PRs or manual base-branch juggling. The trigger is simple: if you're about to open a PR whose base is another open PR's branch, make it a native stack instead. Independent changes are not a stack — keep those as separate PRs against `main`. -**Tooling:** the official `gh-stack` extension (needs GitHub CLI ≥ 2.90.0, Git ≥ 2.20): +**Tooling:** the official `gh-stack` extension (requires GitHub CLI v2.0+): ```sh gh extension install github/gh-stack # one-time setup @@ -147,12 +147,12 @@ gh stack link # adopt existing branches/PR chains into a native stack **Semantics to respect (don't fight them manually):** -- Stacks merge **bottom-to-top**. Merging a mid-stack PR also merges everything below it in one operation. The PRs above stay open, **auto-retarget** to the trunk, and GitHub **automatically rebases** the next unmerged PR server-side — never hand-edit the base branch of a stacked PR. Your **local** branches don't follow along, though: run `gh stack sync` after a merge to pull down the rewritten branches and prune merged ones. +- Stacks merge **bottom-to-top**. Merging a mid-stack PR also merges everything below it in one operation. The PRs above stay open, **auto-retarget** to the trunk, and GitHub **automatically rebases** the next unmerged PR server-side — never hand-edit the base branch of a stacked PR. Your **local** branches don't follow along, though: run `gh stack sync` after a merge to pull down the rewritten branches — with `--prune` to delete local branches for merged PRs, since the default prompts interactively. - **Other drift is NOT auto-rebased.** If the trunk moves ahead or you push changes to a lower layer, the stack goes non-linear and merging is blocked until you explicitly rebase: the **Rebase stack** button in the merge box (server-side), or locally `gh stack rebase --upstack` after amending a lower layer / `gh stack rebase` for trunk drift. Don't hand-`git rebase` each branch in the chain. - Branch protection and CI requirements come from the **bottom PR's base branch** and apply to every layer. - Public-preview limits: all branches must live in the **same repository** (no cross-fork stacks), and programmatic merges must go through `gh stack merge` / the new merge API — not the classic merge endpoint. -**Adopting an existing chain:** if a traditional stack already exists (PRs manually chained by base branch), convert it with `gh stack link` instead of continuing to manage it by hand. +**Adopting an existing chain:** if a traditional stack already exists (PRs manually chained by base branch), `gh stack link` creates or updates the stack on GitHub from branch names or PR numbers — remote linking only; it stores no local tracking state. To also manage the chain locally (`rebase`, `sync`), set up tracking with `gh stack init` / `gh stack checkout`. **Fallback:** if `gh-stack` truly isn't available (old `gh`, extensions blocked), note that briefly, then fall back to manually chained PRs with explicit bases and a "depends on #N" note in each PR description — but treat this as the exception, not a preference.