feat(marius-mode): resolve PR or MR per forge

skills/marius-mode/playbooks/multi-phase-plan.md

@@ -54,8 +54,8 @@ Tests alone are not sufficient verification. A PR is verified only when its unit
 
 ### PR mechanics, for every PR
 
-- [ ] Resolve the forge once. Default to `gh`; if `command -v origin` succeeds and Origin can resolve the repository, use `origin pr` for every PR operation. Record any fallback to `gh`. Never require `gt`.
-- [ ] Open the PR ready, never draft, with `origin pr create --status open --base <base-branch>` or `gh pr create --base <base-branch>` according to the resolved forge. A stack child targets its parent branch.
+- [ ] Resolve the forge once per `<skills>/marius-mode/references/forge.md` and use its noun (PR or MR) and CLI for every operation.
+- [ ] Open the PR ready, never draft, with the forge's create-ready command and `<base-branch>` as the base. A stack child targets its parent branch.
 - [ ] Run the repo's lint and typecheck once before the PR-facing push. Push with hooks on.
 - [ ] Reread each diff against the **laziness-protocol** principle skill before each commit, and run `/no-comments` before review.
 - [ ] Triage every Bugbot and security-reviewer comment per `../references/bugbot-triage.md`.

skills/marius-mode/playbooks/opening-a-pr.md

@@ -1,16 +1,16 @@
 ### Opening a PR
 
-Invoked at the end of every other playbook.
+Invoked at the end of every other playbook. "PR" means the resolved forge's review request: a pull request on GitHub or Origin, a merge request (MR) on GitLab. Say the forge's noun in chat, titles, and descriptions.
 
 **Worktree.** Work from a git worktree off main. Subagents inherit it. Multiple subagents on the same branch each get their own worktree, or `git fetch && git reset --hard origin/<branch>` between them. Dirty branch with unrelated work: patch out, fresh worktree, apply. Snarled worktree: reset from main, redo minimally.
 
 **Commits.** Commit liberally. Rebase into small, ordered commits before opening PRs. Each commit is a future PR: landable, ordered to tell the story. Amend when the fix belongs in a just-made commit. New commit when separable.
 
-**PRs.** Before commit, reread the diff against the **laziness-protocol** principle skill and delete what does not earn its place. Run `/no-comments` before review. Write every PR title, PR description, and commit body with `/technical-writing`, then apply `/unslop`. Apply every technical-writing layer except Diátaxis. Use one word for each action, keep articles, and avoid `-ing` when a plain verb works.
+**PRs.** Before commit, reread the diff against the **laziness-protocol** principle skill and delete what does not earn its place. Run `/no-comments` before review. Write every title, description, and commit body with `/technical-writing`, then apply `/unslop`. Apply every technical-writing layer except Diátaxis. Use one word for each action, keep articles, and avoid `-ing` when a plain verb works.
 
 **Titles.** Use Conventional Commits in the form `type(scope): subject`. Use `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, or `perf` as the type. Use the changed area, such as `pstack` or `marius-mode`, as the scope. Keep the subject short and imperative. Name a real symbol when one carries the change. For example, `fix(pstack): retarget opening-a-pr babysit trigger`. Do not add a trailing period.
 
-**Descriptions.** The PR body is a briefing, not the lab notebook. A reviewer who has the diff should learn why the change exists, what is out of scope, and how you proved the change works. The squash commit body is the PR body. If the body would make the squash commit longer than about 40 lines, cut the body.
+**Descriptions.** The description is a briefing, not the lab notebook. A reviewer who has the diff should learn why the change exists, what is out of scope, and how you proved the change works. A merge or squash commit can carry the description, so keep the description under about 40 lines.
 
 Use these sections in order. Drop a section when it has nothing to say.
 
@@ -22,11 +22,11 @@ Use these sections in order. Drop a section when it has nothing to say.
 
 After these sections, attach videos or screenshots when they prove a claim. Do not paste full SHAs, swarm or arena lane recitals, lever-correction essays, file-by-file checklists, or "CLEAN" verdicts. Put these details in a linked artifact. Do not use `## Summary` or `## Test plan` boilerplate. A commit body does not restate its subject.
 
-**Forge.** Resolve the forge before the first PR operation and keep that choice for create, edit, view, watch, and merge. GitHub CLI (`gh`) is the default. If `command -v origin` succeeds and Origin can resolve the repository, prefer `origin pr ...`. If Origin is absent or cannot resolve the repository, stay on `gh` and record the fallback. Do not require Graphite (`gt`).
+**Forge.** Resolve the forge per [the forge reference](../references/forge.md) before the first PR operation. It detects Origin, GitHub, or GitLab from the repository, sets the noun, and maps each command below to `origin`, `gh`, or `glab`.
 
-**Size and stacks.** Prefer five narrow PRs to one large PR. A stack is a base-branch chain. The root PR targets trunk. Each child branch rebases onto its parent's exact tip and its PR targets the parent branch. Create a child with `origin pr create --status open --base <parent-branch>` or `gh pr create --base <parent-branch>` according to the resolved forge. Retarget an existing child with `origin pr edit <pr> --base <parent-branch>` or `gh pr edit <pr> --base <parent-branch>`. Branch from trunk only for independent work. Rebase on trunk before substantial stack work.
+**Size and stacks.** Prefer five narrow PRs to one large PR. A stack is a base-branch chain. The root PR targets trunk. Each child branch rebases onto its parent's exact tip and its PR targets the parent branch. Create a child with the forge's create command and `<parent-branch>` as the base. Retarget an existing child with the forge's retarget command. Branch from trunk only for independent work. Rebase on trunk before substantial stack work.
 
-**Readiness.** Open every PR ready, never as a draft. With Origin, pass `--status open`. With `gh`, omit `--draft`. Cloud-agent PR tools default to draft, so set `draft: false` on every PR creation call. If a PR still opens as a draft, run `origin pr ready <number>` or `gh pr ready <number>` according to the resolved forge. Run `origin pr view <number>` or `gh pr view <number>` before you refer to PR status.
+**Readiness.** Open every PR ready, never as a draft. Use the forge's create-ready command. Cloud-agent PR tools default to draft, so set `draft: false` on every PR creation call. If a PR still opens as a draft, or a GitLab title starts with `Draft:`, run the forge's mark-ready command. Run the forge's view command before you refer to PR status.
 
 **Babysit.** Opening a PR does not start a babysit. Post the URL and keep building. Finish the phase or stack first. Run a separate babysit pass only when the user asks for one after the whole stack exists. A babysit for each new PR stalls the build and spends checks on commits that later waves restart. Push back when feedback drifts from intent.
 

skills/marius-mode/references/forge.md

@@ -0,0 +1,37 @@
+# Forge
+
+Resolve the forge once, before the first review-request operation. Use that forge for create, edit, view, watch, and merge. Record the choice and any fallback. Do not require Graphite (`gt`).
+
+## Resolve
+
+Check these in order and stop at the first match.
+
+1. **Origin.** `command -v origin` succeeds and Origin can resolve the repository.
+2. **GitHub.** The host of `git remote get-url origin` is `github.com`, or `gh repo view` succeeds for a GitHub Enterprise host.
+3. **GitLab.** The remote host is `gitlab.com` or contains `gitlab`, or `glab auth status --hostname <host>` succeeds for a self-hosted instance.
+
+If nothing matches, ask the user which forge the repository uses. If the forge's CLI is missing, tell the user which one to install. Do not fall back to another forge's CLI.
+
+## Name
+
+The forge sets the noun. Use it in chat, titles, and descriptions.
+
+| Forge | Noun | Base branch | CI |
+| --- | --- | --- | --- |
+| GitHub, Origin | pull request (PR) | base | checks |
+| GitLab | merge request (MR) | target branch | pipeline |
+
+The playbooks say "PR" and `<pr>`. On GitLab, read those as MR and `<mr>`.
+
+## Commands
+
+| Operation | Origin | GitHub | GitLab |
+| --- | --- | --- | --- |
+| Create ready | `origin pr create --status open --base <base>` | `gh pr create --base <base>` | `glab mr create --target-branch <base> --yes` |
+| Retarget | `origin pr edit <pr> --base <base>` | `gh pr edit <pr> --base <base>` | `glab mr update <mr> --target-branch <base>` |
+| Mark ready | `origin pr ready <pr>` | `gh pr ready <pr>` | `glab mr update <mr> --ready` |
+| View | `origin pr view <pr>` | `gh pr view <pr>` | `glab mr view <mr>` |
+
+Pass the description from a file: `--body-file` on `gh`, `--description-file` on `glab`. Never pass `--draft` or `--wip`.
+
+GitLab stacks work the same way as GitHub stacks. A child MR targets its parent's branch. When the parent merges, retarget the child to trunk yourself unless the project retargets it automatically.