feat(land): merge on gitea, stop at the button on github

The never-merge rule only holds for GitHub. Gitea repos here are the
user's own, so land squash-merges once CI is green, threads are
resolved and the branch is current. A gitea PR with no reviewer ever
requested counts as approved, otherwise it waits forever.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

skills/land/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: land
-description: "Drive a PR you authored to ready-to-merge: fix CI failures, address every review comment, resolve conflicts, push, until green + approved. Never merges. Event-driven — the PR daemon wakes it. Forge-agnostic (GitHub or Gitea)."
+description: "Drive a PR you authored to ready-to-merge: fix CI failures, address every review comment, resolve conflicts, push, until green + approved. Merges it on Gitea; on GitHub it stops and leaves the click to the user. Event-driven — the PR daemon wakes it. Forge-agnostic (GitHub or Gitea)."
 user-invocable: true
 args:
   - name: target
@@ -10,8 +10,8 @@ args:
 
 # Land — drive your own PR to ready-to-merge
 
-Takes a PR **you authored** and shepherds it to the merge button: green
-CI, every review thread addressed, approved, branch up to date. For PRs
+Takes a PR **you authored** and shepherds it to the merge: green CI,
+every review thread addressed, approved, branch up to date. For PRs
 someone else authored, use `review-pr` instead — it reads and comments
 and never pushes.
 
@@ -19,8 +19,10 @@ Read `pr-common/COMMON.md` (sibling skill, same skills root) first. It
 defines hints, the seen file, the state file, and forge resolution. This
 document only covers what to *do*.
 
-**Never merge.** The final click is the user's — every repo, every
-forge. No `gh pr merge`, no merge API call, no `--auto`.
+**Merging is forge-scoped.** On **GitHub**, never merge — the final
+click is the user's. No `gh pr merge`, no `--auto`. On **Gitea**, merge
+the PR yourself once section 3's conditions all hold; those are the
+user's own self-hosted repos and the click adds nothing.
 
 **Spend nothing while idle.** You do not wait, poll, or arm watchers.
 The daemon wakes you with a hint when something changes. Do the work the
@@ -183,20 +185,43 @@ return silently.
 All of these must hold: CI green, every thread resolved, approved with
 no pending review requests, branch not behind the base.
 
+On gitea, a PR with no reviewer ever requested and no review posted
+counts as approved — otherwise a solo PR waits forever for a review
+that is never coming. A requested or posted review still has to land.
+
 Update the branch if the base moved (above), let CI re-run, and wait for
-the resulting hint. The user's click should be the only step left.
+the resulting hint.
+
+**On GitHub**, that is where you stop — the user's click is the only
+step left.
+
+**On Gitea**, merge it. Squash, server-side so the PR reads "merged"
+and not "closed":
+
+```bash
+curl -sS -X POST -H "Authorization: token $GITEA_TOKEN" \
+  -H "Content-Type: application/json" \
+  "$BASE/api/v1/repos/$REPO/pulls/$N/merge" -d '{"Do":"squash"}'
+```
+
+Do not delete the branch or remove the worktree — the user handles
+cleanup.
 
 ## 4. Close out
 
-Report: PR ready to merge with its link, CI green, approved, threads
-resolved, and one line on what feedback was addressed. The merge, the
-branch delete, and the tracking-issue close are the user's.
+**Merged (gitea):** report the merge with the PR link, CI green,
+threads resolved, and one line on what feedback was addressed.
+
+**Ready but not merged (github):** report PR ready to merge with the
+same detail. The merge, the branch delete, and the tracking-issue close
+are the user's.
 
 The review window is often hours and the user may be away. Push a
 notification so the click can happen from a phone —
 `mcp__ha-mcp__ha_call_service`, `domain: "notify"`, service
 `mobile_app_pixel_7_naps` (or `blitz.notifyService` from config),
-message "PR #<N> ready to merge" plus the URL.
+message "PR #<N> ready to merge" plus the URL. On gitea, the same
+notification instead says the PR merged.
 
 `Closes <REF>` in the PR body closes a GitHub or Gitea tracking issue on
 merge. Only Linear needs follow-up: tell the user to move the issue to

skills/work/SKILL.md

@@ -72,7 +72,7 @@ Advisory, not a hard gate: for a trivial diff (typo, one-liner, config bump) ski
 
 ### 5. Hand off to `/land`
 
-The PR is open — now drive it to ready-to-merge. **Invoke `/land <N>`** (the `land` skill). It owns the whole review/CI iteration loop: waits for CI + reviews without idling, fixes failures, resolves every comment (including bot reviewers), pushes, re-arms, and once green + approved it updates the branch and hands the merge click to the user — it never merges.
+The PR is open — now drive it to ready-to-merge. **Invoke `/land <N>`** (the `land` skill). It owns the whole review/CI iteration loop: waits for CI + reviews without idling, fixes failures, resolves every comment (including bot reviewers), pushes, re-arms, and once green + approved it updates the branch, then merges on gitea or hands the merge click to the user on GitHub.
 
 Do not re-implement that loop here — `/land` is the single source of truth for it, and it reads the same `remoteHost` / tracker config. `/land` derives the tracking issue from the PR body's `Closes <REF>`, so no extra hand-off state is needed.
 

skills/yolo/SKILL.md

@@ -57,4 +57,4 @@ Follow the implementation guidelines from COMMON.md. Move fast — this is yolo
 
 This stays true to yolo: fire-and-forget, model idle, surfaces only a broken build.
 
-**If a PR does exist and you want it driven to green + ready-to-merge** (CI waited on, review comments resolved, iterated until done; the merge click stays with the user) — don't hand-roll it here. Hand off to **`/land <N>`** (the `land` skill), the same loop `/work` uses. That's the escape hatch when a "yolo" task turns out to need real review follow-through.
+**If a PR does exist and you want it driven to green + ready-to-merge** (CI waited on, review comments resolved, iterated until done; it merges on gitea, and on GitHub the merge click stays with the user) — don't hand-roll it here. Hand off to **`/land <N>`** (the `land` skill), the same loop `/work` uses. That's the escape hatch when a "yolo" task turns out to need real review follow-through.