diff --git a/AGENTS.md b/AGENTS.md
index 1fa5062..3280da6 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -52,5 +52,7 @@ This repository is a TypeScript monorepo for `nproxy`, a crypto-subscription ima
 - Treat the remote Gitea repository as the source of truth for task tracking when the user refers to `issues`.
 - Before starting implementation, open the relevant Gitea issue and read its full problem statement and acceptance criteria instead of guessing from local notes.
 - If the user asks to "continue work" or pick the next task, inspect the open Gitea issues and choose the first one that is logically ready to implement.
-- After finishing the task, push the branch and create a Gitea PR linked to the issue, usually with `Closes #<issue-number>` in the PR body.
+- After finishing the task, push the branch and create a Gitea PR linked to the issue.
+- Every task PR must include an issue reference in the PR body, usually `Closes #<issue-number>` (or `Refs #<issue-number>` when it should not auto-close on merge).
+- If the issue-to-PR link is not clearly visible in Gitea, add an explicit comment in the issue with the PR number and URL.
 - If Gitea access requires credentials or network escalation, use the configured repository environment and approved escalation flow instead of skipping the issue lookup.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 1f5728e..22981d9 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -8,12 +8,15 @@
 ## Standard Flow
 1. Update local `master`.
 2. Create a task branch from `master`.
-3. Implement the change in that branch.
-4. Run the relevant verification for the change.
-5. Commit the work in that branch.
-6. Push the branch to Gitea.
-7. Open a merge request into `master`.
-8. Merge only after review or explicit approval.
+3. Pick or confirm the target issue in Gitea before implementation.
+4. Implement the change in that branch.
+5. Run the relevant verification for the change.
+6. Commit the work in that branch.
+7. Push the branch to Gitea.
+8. Open a merge request into `master`.
+9. Link the merge request to the issue in the MR body using `Closes #<issue-number>` or `Refs #<issue-number>`.
+10. If the Gitea UI does not show the link clearly, add an explicit comment in the issue with the MR number and URL.
+11. Merge only after review or explicit approval.
 
 ## Branch Naming
 Use short, purpose-driven names, for example:
@@ -31,3 +34,4 @@ Use short, purpose-driven names, for example:
 ## Agent Workflow
 - Codex or any other coding agent must create and use a dedicated branch per task.
 - After task completion, the agent should push that branch and prepare it for a merge request instead of pushing directly to `master`.
+- The agent must ensure the issue is explicitly linked to the merge request before handing off for merge.