Why it matters
Issues ↔ PRs that talk gives ForkMesh a concrete mechanism for linked issues and pull requests updating each other as work lands. Merge a pull request and its linked issue closes itself. One checkbox syncs the merge straight to main.
Planning loses force when it drifts away from the code history and pull requests it is supposed to guide. In ForkMesh, issues ↔ PRs that talk addresses that need at the feature level, keeping the behavior close to the repository instead of buried in a detached hosted layer.
How ForkMesh handles it
ForkMesh handles issues ↔ PRs that talk through the same split it uses across the product: issues are repository-linked records surfaced in desktop and web views beside branches, pull requests, milestones, and agent sessions.
The behavior is intentionally narrow: Merge a pull request and its linked issue closes itself. One checkbox syncs the merge straight to main. State changes stay portable because the planning layer follows the repository instead of one private dashboard.
Where it fits
Use issues ↔ PRs that talk when triage and progress tracking should live beside the repository and remain portable.
It pairs with the rest of Issues & planning because Issues ↔ PRs that talk keeps linked issues and pull requests updating each other as work lands connected to the repository, its signatures, and the nodes that serve it.