docs: keep one PR checklist and retire the bot-era issue fields (#568)

The PR checklist existed twice, in .github/pull_request_template.md and in
CONTRIBUTING's "PR Checklist" section. Both were written in #381 and had
already drifted: four items against five, different wording for the same
four concepts, and "The PR links a relevant issue when one exists" present
only in CONTRIBUTING. Keep the checklist in the template, where the work
happens, add the missing fifth item, and leave CONTRIBUTING pointing at it.

The template also carried no outbound link of any kind, including on the
line that referred to "the package ownership boundaries documented in
CONTRIBUTING". Relative links do not resolve inside a PR body, so the added
links are absolute.

Neither file stated the PR title convention, although every merged PR
follows it. squash_merge_commit_title is COMMIT_OR_PR_TITLE, so on a
multi-commit PR the title becomes the commit subject, and RELEASING.md
reads a conventional-commits `!` marker on a merged commit as a
breaking-change signal. Say it once, at the top of the template.

The issue templates asked reporters for Acceptance criteria, Target paths,
Out of scope, Open decisions, and Blockers. Those are machine-readable
fields added in 098371c for the maintainer issue-to-PR bot; #520 removed
the bot but left the fields, so outside reporters were still asked for
exact repository-relative paths with no globs. Both templates now match
098371c^ byte for byte, which also drops the dangling "Maintainer Bot will
route the issue to manual handling" comment.

.github/CONTRIBUTING.md

@@ -55,15 +55,9 @@ CI is the source of truth for the full pre-merge matrix. It runs lint, unit test
 2. Make your changes
 3. Add or update tests and user-facing documentation when behavior changes
 4. Run the checks relevant to your change and note any skipped checks with a reason
-5. Open a PR against `main`
+5. Open a PR against `main`, titled as a conventional commit such as `fix(core): reject empty tool names`
 
-### PR Checklist
-
-- [ ] Tests cover changed behavior, or the PR explains why tests are not needed
-- [ ] User-facing documentation and examples are updated, or marked not applicable
-- [ ] Compatibility, breaking changes, and migration requirements are documented, or marked not applicable
-- [ ] Dependency changes are justified and follow the package-specific rules below
-- [ ] The PR links a relevant issue when one exists
+Opening a PR prefills the [pull request template](pull_request_template.md), which carries the review checklist. Fill in the sections it asks for instead of deleting them, and write "None" or "Not applicable" where a category does not apply.
 
 ## Code Style
 

.github/ISSUE_TEMPLATE/bug_report.md

@@ -18,37 +18,10 @@ Steps to reproduce the behavior:
 2. Call `runTeam(...)` with '...'
 3. See error
 
-## Current behavior
-
-Describe the observed behavior or the deterministic failing-test procedure.
-
 ## Expected behavior
 
 A clear description of what you expected to happen.
 
-## Acceptance criteria
-
-- State each objectively verifiable result as a separate bullet.
-- Include the focused test or command outcome when one is known.
-
-## Target paths
-
-- `path/to/exact-file.test.ts`
-
-Use normalized repository-relative files or directories. Do not use globs.
-
-## Out of scope
-
-- List code, behavior, public APIs, dependencies, or workspaces that must not change.
-
-## Open decisions
-
-None.
-
-## Blockers
-
-None.
-
 ## Error output
 
 ```

.github/ISSUE_TEMPLATE/feature_request.md

@@ -21,40 +21,6 @@ assignees: ''
 
 A clear description of the problem or limitation you're experiencing.
 
-## Current behavior
-
-Describe what the repository does today and why that is insufficient.
-
-## Expected behavior
-
-Describe the bounded behavior that should exist after this issue is complete.
-
-## Acceptance criteria
-
-- State each objectively verifiable result as a separate bullet.
-- Include the focused test or command outcome when one is known.
-
-## Target paths
-
-- `path/to/exact-file.ts`
-
-Use normalized repository-relative files or directories. Do not use globs.
-
-## Out of scope
-
-- List code, behavior, public APIs, dependencies, or workspaces that must not change.
-
-## Open decisions
-
-None.
-
-<!-- If a product or architecture decision remains open, describe it here. The
-Maintainer Bot will route the issue to manual handling. -->
-
-## Blockers
-
-None.
-
 ## Proposed Solution
 
 Describe what you'd like to happen.

.github/pull_request_template.md

@@ -1,3 +1,12 @@
+<!--
+Title this PR as a conventional commit, for example `fix(core): reject empty tool names`.
+A squash merge can take the title as the commit subject, and the release process reads
+those subjects, so a `feat`/`fix`/`!` marker on the title carries through to the changelog.
+
+Contribution guide:
+https://github.com/open-multi-agent/open-multi-agent/blob/main/.github/CONTRIBUTING.md
+-->
+
 ## Summary
 
 <!-- What changed? Focus on behavior and outcomes rather than implementation details. -->
@@ -24,6 +33,10 @@ that was not run. Common checks include:
 - npm test
 - npm run build
 - npm run test:scaffold (for create-oma-app scaffolding or template changes)
+
+Scope a check to one workspace when that is faster, for example
+`npm test -w @open-multi-agent/core`. The full list of commands is in
+https://github.com/open-multi-agent/open-multi-agent/blob/main/.github/CONTRIBUTING.md#running-tests
 -->
 
 ## Checklist
@@ -31,4 +44,5 @@ that was not run. Common checks include:
 - [ ] Tests were added or updated for changed behavior, or a rationale is provided
 - [ ] User-facing documentation and examples were updated, or this is not applicable
 - [ ] Compatibility, breaking changes, and migration requirements are documented, or this is not applicable
-- [ ] Dependency changes are justified and preserve the package ownership boundaries documented in CONTRIBUTING
+- [ ] Dependency changes are justified and preserve the [package ownership boundaries](https://github.com/open-multi-agent/open-multi-agent/blob/main/.github/CONTRIBUTING.md#code-style)
+- [ ] A relevant issue is linked when one exists