Does Projan create GitHub issues?

No. Projan reads GitHub issues and pull requests as context for planning; it does not create or modify anything in GitHub. The agreed plan is exported to your issue tracker, such as Jira, Linear or ClickUp.

What can Projan actually pull in from a GitHub URL?

An issue or a pull request, by its URL. Projan reads the title, the description and the surrounding detail and brings it into the session as grounding context, so the discussion is anchored to the actual item rather than someone's memory of it. It reads; it doesn't write back.

Can it read a draft PR, or only ones that are ready for review?

A draft pull request works the same as any other — paste its URL and Projan pulls it in as context. That's often the point: the half-built thing in a draft PR is exactly the work the team needs to plan around, and it's usually the work that gets forgotten in a planning meeting.

If the plan doesn't go back to GitHub, where do the agreed tasks end up?

In your issue tracker. Once the team agrees the milestone, Projan exports the work to Jira, Linear, ClickUp or Asana — wherever your delivery actually lives. GitHub stays as it was; nothing is written into it.

Does Projan need write access to our repositories?

No. The integration reads the issues and pull requests you point it at by URL. It doesn't open issues, comment, change labels or push anything into the repo, so it doesn't need permission to.

Do we have to run the planning session inside Projan's own app?

No. Projan's Slack and Microsoft Teams bots run the session in the channel your team already uses. You paste the GitHub URLs into the thread, Projan reads them in as context, and the session happens where you already talk.

We use GitHub Issues as our tracker, not Jira. Can Projan export there?

No — the GitHub integration is read-only, so Projan won't create or update issues in GitHub even when that's where you track work. It exports the agreed plan to Jira, Linear, ClickUp or Asana. If GitHub Issues is your only tracker, Projan grounds the planning in your GitHub context but the agreed output lands in one of those connected tools.

Our real context lives in GitHub issues and pull requests — can Projan plan from what's actually being built?

Planning that ignores the codebase produces plans engineers quietly route around. Projan keeps the two honest. It pulls real GitHub issues and pull requests into a planning session by URL, as context — so when the team debates what to build next, the half-finished invite flow in an open PR and the bug everyone forgot is filed are actually in the room. Projan reads from GitHub; it doesn't write to it. The agreed plan is then exported to your issue tracker — Jira, Linear, ClickUp or Asana — leaving GitHub as the source of engineering truth it already is.

A milestone planning meeting, half an hour in. Someone proposes building a teams-invite flow as the headline of the next release. Nobody mentions that there’s already an open pull request with two-thirds of an invite flow in it, sitting in draft for three weeks because the original author got pulled onto something else. So the room plans to build a thing that half exists, and an engineer will discover the overlap a sprint later, sigh, and quietly reconcile the plan against the code on their own. The plan was never wrong on purpose. It just never looked at the repo.

Plans that ignore the code get ignored by the coders

There’s a gap between the plan a team agrees and the codebase that plan is supposed to act on. The plan lives in a meeting and a tracker; the truth lives in issues and pull requests. When the two drift, engineers trust the code, because the code is what’s real — and the agreed plan becomes something they route around rather than follow. The half-finished feature in a draft PR, the bug that’s been filed for a month, the issue that captures a constraint nobody in the room remembers: these are the things that decide whether a plan is buildable, and they’re exactly the things a planning meeting forgets to bring.

Projan closes that gap from the GitHub side. It brings the actual state of the work into the conversation, so the plan is argued against what exists rather than what people half-remember.

Bringing the actual work into the room

Take that milestone session, run with Projan instead. Before the team commits to anything, someone drops in the URLs that matter: the open issue describing the rate-limiting bug, the issue capturing a customer’s SSO requirement, and the draft PR with the unfinished invite flow.

Projan reads all three in as context. Now the invite flow isn’t a fresh idea — it’s two-thirds done, and the discussion turns to finishing and reviewing it rather than rebuilding it. The rate-limiting bug, which someone was about to wave off as minor, turns out from the issue to block the very API work the milestone depends on, so it gets pulled forward. The SSO requirement, sitting quietly in an issue nobody had reopened, reshapes the auth task before it’s even written down.

The team still decides the milestone. But they decide it with the open PR and the two issues actually in the room, so the plan they agree is one the codebase can support — not one an engineer has to silently correct later.

What Projan reads from GitHub

Projan reads GitHub issues and pull requests by URL and pulls them into a planning session as grounding context. Paste the link to an issue or a PR — including a draft PR — and Projan brings its title, description and detail into the conversation, so the debate is anchored to the real item. That’s the whole of the GitHub integration: it’s a way to get the true state of the work into the room while the team is still deciding what to do next.

What Projan does not do with GitHub

Projan does not write to GitHub. It does not create issues, edit them, comment on them, change labels, open or update pull requests, or push anything into your repositories. The integration is read-only by design — context in, nothing out. GitHub stays exactly as your engineers left it, the unchanged source of engineering truth, and Projan simply reads from it.

Where the agreed work actually goes

The plan the team agrees has to land somewhere it can be tracked — and that somewhere is your issue tracker, not GitHub. Once the milestone is settled, Projan exports the agreed work to Jira, Linear, ClickUp or Asana, with acceptance criteria written in and dependencies marked. So the flow is one-directional and clean: GitHub provides the grounding context going in, the team does the deciding, and the resulting work goes out to the tracker your delivery runs on. Nothing is created in GitHub at any point.

Plan in Slack or Teams, grounded in GitHub

None of this requires a new place to work. Projan’s Slack and Microsoft Teams bots run the facilitated session in the channel your team already lives in. You paste the GitHub issue and PR URLs straight into the thread, Projan reads them in as context, and the milestone gets argued out where the team already talks — then exported to your tracker from there. The grounding comes from GitHub; the conversation stays where you are.

Setting it up

Connect GitHub once under Integrations → GitHub, then, in any session, paste the URL of an issue or pull request you want the team to plan around. Projan reads it in as context for that conversation — it asks for no write access and creates nothing in your repositories. Run the session in Slack, Teams or the web workspace, agree the milestone, and export the work to Jira, Linear, ClickUp or Asana. GitHub stays your engineering source of truth; Projan just makes sure the plan respects it.