12 April 2026

GitHub issues for Designers

Most design teams manage their work in one tool and do their work in another. The gap between them is where context goes to die.

Main point: Designers should keep their tasks in GitHub Issues, next to the code, so the link between task, PR and decision is automatic and AI agents can use it.

The gap

When tasks live in Notion and code in GitHub, the link between them lives in someone's head. The reasoning, constraints and rejected options don't travel. In GitHub, an Issue links to the PR that closes it, the PR to the branch, and the whole chain stays in one place.

What AI can do with it

An agent that sees Issues, Projects and the repo together can answer in seconds:- Is anyone building something that overlaps with what I'm starting?- Which Issues are blocked, and does the blocker exist yet?- What was decided in this area before?- Is someone already building this component on another branch?

A richer briefing

Unplanned Studio already briefs designers on what changed on main when they start a branch. Add Issues and Projects and it also covers what colleagues are doing and why things were built the way they were. (Related: [The informed branch: How AI changes what it means to start a piece of work])

"But GitHub is for engineers"

Fair, so separate the interface from the data. Designers can manage Issues through boards or the AI assistant. The value is having tasks next to code. The real question is what it costs to keep them apart.

Start small

  • Use Issues for work tied to code: features, component proposals, bugs
  • Link each PR with "Closes #123"
  • Use GitHub Projects as a simple board for the current sprint

That's enough for an agent to be useful. (Related: [What happens when an AI can see every designer's PR?])