Inside Rezee - planning that closes itself (Plan & Track)
The thinking behind Rezee's Plan & Track layer - issues with owners and workflows, projects and milestones, and pull requests that close issues automatically so the tracker stays truthful.
Jul 20, 2026 · 2 min read · Kash Gohil
Rezee is one workspace for everything a team ships, organized as five layers. This post covers Plan & Track - issues, projects, and workflow - and the conviction behind it: a tracker is only useful while it tells the truth, and trackers kept truthful by human discipline always eventually lie. The fix is structural: put planning on the same data model as the code, and let the merge update the status.
Why does planning belong next to the code?
Because status is born in git - branches opened, reviews finished, merges landed - and every meter of distance between where status happens and where it's recorded is maintained by someone remembering to copy it. That's the drift we dissected in spec to shipped: "In progress" for work that merged Tuesday isn't a discipline failure, it's the architecture working as designed. Planning beside code means the copy step doesn't exist.
What's actually in the layer?
Issues with states and owners. Every issue has one owner and a clear workflow state - the minimal structure that keeps "who's on it, where is it?" a lookup instead of a standup question.
Labels and filters. Workspace-wide labels, and a board you narrow to what's active, what's parked, or what's urgent - with the filter in the URL, so the slice you're looking at is a link you can send. Enough taxonomy to answer real questions; not enough to become a hobby.
Assignees and mentions. Mention a teammate to pull them in - or assign the issue to an agent, which turns a ping into background work.
Projects and milestones. Issues group into projects that can span repos, with milestones for the dates that matter. Status decks stop being written because the project view is the status.
Auto-linked pull requests. The load-bearing feature: the branch name links the whole chain, and issues are closed by the merge, not by hand. No stale issues after shipping, no magic-word rituals - the tracker's truthfulness stops depending on anyone's memory.
An activity feed that respects attention. One feed for the workspace, quiet hours honored - designed against the notification tax, not for engagement.
How does it connect to the other layers?
Issues are referenced live from the specs in Ideate & Design that argued for them; they close from merges in Code & Ship; their status unfurls in chat whenever mentioned; and an issue assigned to an agent gets a first-pass investigation, because the structure above makes one legible.
FAQ
What is Rezee's Plan & Track layer?
The planning layer of the Rezee workspace: issues with owners, states, and labels, grouped into projects and cycles, linked natively to branches and pull requests so merges update status automatically.
Does it support cycles or sprints?
Projects and milestones cover cadence for most small teams; if you run strict sprints, milestones per cycle is the working pattern. The layer is deliberately lighter than Jira - that's a feature, as we argue in Rezee vs the Atlassian stack.
Can I import issues from Linear or Jira?
Issues can be imported or recreated - straightforward for titles, descriptions, labels, and states; deep tool-specific history doesn't map one-to-one. The trade-offs are covered honestly in Rezee vs Linear + GitHub.