docs(contributing): require issues before bug and feature PRs

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -7,6 +7,10 @@ body:
     attributes:
       value: |
         ## Before you submit...
+
+        Search existing issues and pull requests first. Reuse an issue that
+        already tracks the same bug. If you plan to contribute a fix, open this
+        issue before your PR and comment with your intended approach.
 
         Please ensure you have:
         - Read the [installation guide](https://ifbars.github.io/S1API/docs/getting-started.html#installation-guide)

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -8,6 +8,11 @@ body:
       value: |
         ## Feature Request
 
+        Search existing issues and pull requests first. Reuse an issue that
+        already tracks the same request. If you plan to implement it, open this
+        issue before your PR and comment with your intended approach. Discuss
+        substantial API or behavior changes with a maintainer before implementation.
+
         Keep this short if you want.
 
         You do **not** need to know how the API should be implemented. If you're not technical, just describe:

.github/pull_request_template.md

@@ -1,3 +1,21 @@
+## Linked issue
+
+<!--
+Bug fixes, features, and API improvements require a GitHub issue opened before
+this PR. Reuse an existing issue when possible.
+Use "Fixes #123" for a complete resolution or "Refs #123" for partial work.
+For an issue-free typo, formatting, or documentation-only change that does not
+alter API behavior, explain the exception here. Otherwise, link the maintainer's
+explicit approval of an exception.
+See CONTRIBUTING.md for the issue-first workflow.
+-->
+
+## Contributor checklist
+
+- [ ] I linked an issue opened before this PR, or explained an allowed exception above.
+- [ ] I checked existing issues and PRs for duplicate or overlapping work.
+- [ ] This PR addresses one focused problem or request.
+
 ## Summary
 
 <!-- Explain the modder-facing outcome and the native/runtime seam used. -->

AGENTS.md

@@ -53,7 +53,17 @@ and document the migration impact in the PR.
 `S1API.Tests/` is the only test implementation that should be committed to this repository. Keep runtime and in-game smoke mods, launchers, harnesses, disposable saves or installs, logs, screenshots, and generated evidence local and ignored, including everything under `tests/Smoke/`. Do not add `.gitignore` exceptions for smoke-test sources. Record the scenario, commands, runtime matrix, and observed pass/fail evidence in the PR description without committing the smoke implementation or game-derived artifacts.
 
 ## Commit & Pull Request Guidelines
-Write imperative, single-purpose commits; lightweight prefixes such as `fix:` or `feat:` appear in history and are encouraged. Target regular-game PRs at `stable` and beta-game PRs at `beta`. Include a short change narrative, reproduction or validation notes, and link any external issue. Screenshots or logs are helpful for UI or networking work. Never modify CI workflows without prior discussion.
+Write imperative, single-purpose commits; lightweight prefixes such as `fix:` or `feat:` appear in history and are encouraged. Target regular-game PRs at `stable` and beta-game PRs at `beta`. Include a short change narrative, reproduction or validation notes, and link the tracking GitHub issue. Screenshots or logs are helpful for UI or networking work. Never modify CI workflows without prior discussion.
+
+Follow the issue-first workflow in `CONTRIBUTING.md`: search existing issues and
+PRs, reuse or open a GitHub issue before a bug-fix, feature, or API-improvement
+PR, and record the intended approach on the issue before implementation. Discuss
+substantial API or behavior changes with a maintainer first. Use `Fixes #123`
+for complete resolutions and `Refs #123` for partial work. A PR description is
+not a substitute for the issue. Keep unrelated problems in separate issues and
+focused PRs. Typo, formatting, and documentation-only changes that do not alter
+API behavior may omit an issue with an explanation in the PR; other exceptions
+require explicit maintainer approval.
 
 ## Release & Versioning Workflow
 Always follow [`VERSIONING.md`](VERSIONING.md) for any release, hotfix, tagging, branch-planning, or version-bump work. Treat it as the authoritative release policy.

CONTRIBUTING.md

@@ -8,6 +8,35 @@ Please read over the below in full to help you get started and set expectations
 - Do **NOT** alter my GitHub actions unless you have a good reason. 
   I will close your PR and ban you from the project if malicious intent is found.
 
+## Before Opening a Pull Request
+
+Bug fixes, feature requests, and API improvements must have a GitHub issue
+opened **before** the pull request, even if you already have a fix ready. The
+issue records the problem or request independently of the proposed implementation.
+
+1. Search [existing issues](https://github.com/ifBars/S1API/issues) and open pull
+   requests first. Reuse an issue that already tracks the same problem rather
+   than opening a duplicate.
+2. If there is no matching issue, open a
+   [bug report](https://github.com/ifBars/S1API/issues/new?template=bug_report.yml)
+   or [feature request](https://github.com/ifBars/S1API/issues/new?template=feature_request.yml).
+   For bugs, include reproduction steps, expected and actual behavior, affected
+   versions, and the Mono or IL2CPP runtime. For requests, explain the use case
+   and what is missing today.
+3. Comment on the issue with your intended approach before starting work so
+   contributors can coordinate. Discuss substantial API or behavior changes
+   with a maintainer before implementing them.
+4. Link the issue in the PR description. Use `Fixes #123` when the PR fully
+   resolves it, or `Refs #123` when it only addresses part of the work.
+
+A PR description does not replace an issue. Bug-fix and feature PRs without a
+linked issue will be asked to add one before review proceeds. Keep unrelated
+bugs or requests in separate issues and focused PRs.
+
+Typo corrections, formatting, and documentation-only changes that do not alter
+API behavior may be submitted without an issue; explain that exception in the
+PR's linked issue section. Maintainers may approve other exceptions explicitly.
+
 ## Prerequisites
 S1API is available to mod developers of all experience levels, but contributing
 game-facing changes assumes working familiarity with Schedule I mod development
@@ -60,10 +89,10 @@ Ultimately, this just saves you time and gets your changes into the API faster.
 | MonoMelon     | MelonLoader for Mono (alternate branch) builds |
 
 ## Proper Contributing Channels
-All pull requests **must** go into `bleeding-edge` before `stable`.
-If you make a pull request for `stable`, I **will** be changing it to verify build.
+Target regular-game pull requests at `stable` and game-beta pull requests at
+`beta`. For release and hotfix preparation, follow [VERSIONING.md](VERSIONING.md).
 
 ## Tracking Work & Issues
-We maintain a [Trello board](https://trello.com/b/yuRuBpIg/s1api) where known issues and tasks that need to be done are tracked. 
-While the board is not always perfectly up to date, it should typically show the known issues in the project. 
-GitHub issues opened with us will typically be added to the Trello board and then archived once closed.
+[GitHub issues](https://github.com/ifBars/S1API/issues) are the source of truth
+for bugs and requests. Keep reproduction details, scope decisions, and related
+PR links on the issue so the work remains easy to track across releases.

README.md

@@ -70,4 +70,7 @@ If you want to do custom content specific to Mono or Il2Cpp, S1API can still ass
 ## Want to Contribute?
 This is a massive project with so many different areas to specialize in.
 If you're interested in contributing, please do!
+For bug fixes, features, and API improvements, reuse or open a
+[GitHub issue](https://github.com/ifBars/S1API/issues) before opening a pull
+request, and link that issue in the PR description.
 Look over the [CONTRIBUTING.md](CONTRIBUTING.md) for guidance on code standards and the process.