|

feat: add mercurial-finishing-a-branch skill

Author: Chris Tusa <chris.tusa@leafscale.com>
Date: May 03, 2026 16:04
Changeset: 387bb6102e842d77cfd0b06cab4a5c80c473f3af
Branch: default

Diff

diff -r 48ca9ffea549 -r 387bb6102e84 skills/mercurial-finishing-a-branch/SKILL.md
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/skills/mercurial-finishing-a-branch/SKILL.md	Sun May 03 16:04:17 2026 -0500
@@ -0,0 +1,124 @@
+---
+name: mercurial-finishing-a-branch
+description: Use when an implementation is complete and ready to be proposed as a pull request — runs the pre-PR checklist (build, vet, format, test) and walks through pushing the bookmark and opening a PR. The Mercurial counterpart to superpowers' `finishing-a-development-branch`.
+---
+
+# Mercurial: finishing a development branch
+
+## When this applies
+
+Use when:
+- Implementation is complete and the user is ready to propose a PR.
+- The user says "let's ship this" / "this is done" / "let's open a PR" in an hg repo.
+
+Do not use for:
+- Mid-development commits → see `mercurial-basics`.
+- Recovering from a bad commit → see `mercurial-history-rewriting`.
+
+## The flow
+
+Six steps. Do them in order; do not skip.
+
+### 1. Verify the working directory is clean
+
+```sh
+hg status
+```
+
+Expected: empty output. If anything is shown:
+- New files you intended to include → `hg add` and amend the tip commit.
+- New files you didn't mean to track → add to `.hgignore` and commit that change separately.
+- Modified files → either amend or commit them as a separate change.
+
+Do not push with uncommitted changes lingering.
+
+### 2. Verify you're on the right bookmark
+
+```sh
+hg bookmarks
+```
+
+The active bookmark is marked with `*`. Confirm it's the feature bookmark, not e.g. an accidental commit on no bookmark.
+
+If a feature bookmark exists but isn't active:
+
+```sh
+hg update <bookmark-name>
+```
+
+If commits were made without an active bookmark (anonymous head):
+
+```sh
+hg bookmark <feature-name> -r .
+```
+
+(See `mercurial-bookmarks-and-prs` for the bookmark mechanics.)
+
+### 3. Verify history is clean
+
+```sh
+hg log -l 10 --template '{node|short} {phase} {desc|firstline}\n'
+```
+
+Look for:
+- All commits should be `draft` (in non-publishing repos like Isurus).
+- Commit messages follow the convention (imperative summary, <72 chars, "category: summary" prefix where the project uses one).
+- No "wip", "fix typo", "address review" debris — squash via `hg amend` / `hg uncommit`.
+
+If cleanup is needed → see `mercurial-history-rewriting`. The non-publishing repo means amend is safe even on already-pushed changesets.
+
+### 4. Run the project's pre-PR checks
+
+Detect the project's check command:
+
+```sh
+ls Makefile 2>/dev/null && grep -E '^(check|test|fmt|vet|lint):' Makefile
+```
+
+Common patterns:
+- **Has `Makefile` with `check` target:** `make check` (full test suite). Then run `make fmt` and `make vet` if those exist.
+- **Go project, no Makefile:** `go test ./...`, `go vet ./...`, `gofmt -l .` (anything output = unformatted).
+- **Other languages:** match the project's documented test/lint commands.
+
+For the Isurus repository specifically, see `isurus-conventions` — it documents the exact `make` targets used.
+
+If checks fail, **fix or surface** before continuing. Do not push code that fails the project's own gate.
+
+### 5. Push the bookmark
+
+```sh
+hg push -B <bookmark-name>
+```
+
+The `-B <bookmark-name>` is critical — without it the changesets push but the remote doesn't know to associate them with a bookmark/PR.
+
+If the push is rejected because the bookmark was previously pushed and has since been amended:
+
+```sh
+hg push -B <bookmark-name> -f
+```
+
+`-f` is the expected workflow in non-publishing repos after `hg amend`. See `mercurial-bookmarks-and-prs` for context.
+
+### 6. Open the pull request
+
+In the forge web UI:
+1. Navigate to the repository.
+2. The forge typically shows a banner offering to open a PR for the just-pushed bookmark — click it.
+3. Title the PR using the same format as the commit message summary.
+4. PR description: explain *why*, link any related issues. The diff shows *what*; don't repeat it in the description.
+
+For Isurus-specific URL patterns and PR conventions → see `isurus-conventions`.
+
+## After the PR is open
+
+When reviewer feedback comes in:
+- Make the requested changes locally.
+- `hg amend` to fold the fix into the existing changeset (in non-publishing repos).
+- `hg push -B <bookmark-name> -f`.
+- Reply to the review comments confirming the fix is pushed.
+
+When the PR is merged:
+- `hg pull -u` to bring the merged changes locally.
+- `hg bookmark -d <bookmark-name>` to delete the local bookmark.
+- Optionally `hg push --delete <bookmark-name>` if the forge doesn't auto-delete on merge.