MR

Every MR/PR you open for the user follows this flow. Never skip a step to save time.

1. Prepare (no forge writes yet)

• Branch is pushed or ready to push, never main; commits follow the repo's message convention.
• Find the repo's MR/PR template: .gitlab/merge_request_templates/Default.md (GitLab) or .github/pull_request_template.md (GitHub). Fill it in. Keep every heading; in checklists keep only the sections that apply, tick only what is actually true.
• Write the description in the language recent MRs of the repo use (glab mr list --merged -P 5 + glab mr view <n>). The template and past MRs win over generic language rules.
• Reference the ticket the way recent MRs do (e.g. Closes KEY-123).
• Title: match recent merged MRs (same convention as commits, one ticket key, short).
• Run the title and description through the "AI-writing tells" checklist in <hub>/local/owner-prefs.md (Writing) and fix every hit before the gate.

1b. Gate (before showing anything, and before every push of new commits)

Runs on its own: the user never has to ask for it. Same gate for a new MR, review fixes (review-threads) and any later push.

1. Repo context: read the repo's CLAUDE.md and its skills. Untracked .claude/ dirs exist only in the main checkout, not in worktrees: read <repo path>/.claude/skills/ and <hub>/local/skills/<project>/ from there.
2. Bug hunt: start the code-review skill on the branch diff against the target (it runs in the background).
3. Patterns: meanwhile run the review skill in self mode: bin/crow-review-check for the regex rules, then the repo checklist + every other ledger row, for real.
4. Triage every code-review finding: valid → fix on the branch; otherwise one line on why not (pre-existing, out of scope, wrong). If the code changed, re-check the new diff.
5. A finding neither the ledgers nor the checklist would have caught gets a ledger row (self-review source).

Report: Patterns: N checked, K hits, M n/a, the code-review findings with their verdict, and what was fixed. Hits that need a decision become questions.

2. Validate with the user

Show the gate result, then the title and the description, and wait for an explicit OK. Adjust and show again if asked.

3. Ask for the reviewer

Read the project's reviewers list in the hub registry (<hub>/local/projects.yaml; hub path from $CROW_HOME, else ask). Ask which one with AskUserQuestion. Personal repos with no reviewers: skip.

4. Create

• GitLab: glab mr create --source-branch <b> --target-branch main --title ... --description ... --assignee <user's forge username> --reviewer <chosen> --yes (add --draft if the user wants it or if pre-merge steps are pending).
• GitHub: gh pr create --title ... --body ... --assignee @me [--reviewer <chosen>].
• The user's forge username is the project's forge_user in the registry.
• Never merge a work MR. Never add AI attribution anywhere.

5. Update the tickets

For every ticket the MR closes, move it to the tracker's review status (e.g. Jira "Merge Review"). A ticket the MR only partly covers stays in progress. Do the same when an existing MR changes state (ready, merged → the post-merge status the team uses).

6. Report

Give the link, the reviewer and any pre-merge steps left.