You finish the spec in Draftlytic. You've answered the questions, refined a few features, and the PRD looks good. Then comes the part nobody talks about in the tutorial: getting the file into your codebase.
You download PRD.md. You open your terminal, navigate to the repo, drop the file in, commit it, push it. Fine. But then you revise the spec a week later because the auth flow changed. Download again. Navigate again. Overwrite. Commit. Push.
It works. It's just friction that compounds every time the spec moves.
Draftlytic's GitHub integration removes that step. You push your spec directly from the app into a new or existing GitHub repo. The file lands at the root as PRD.md. When you revise the spec and push again, it updates in place. No download, no manual commit.
The copy-paste gap between planning and building
The problem isn't that the file is hard to move. It's that the spec and the code live in different places by default, so they drift apart without anyone deciding to let them drift.
Your code is in version control. Every change is tracked, dated, attributable. Your spec is on your computer as a downloaded file, or maybe in a Notion doc, or in your email. Nobody planned it that way; it just happened because the tool that made the spec (Draftlytic) and the tool that builds the code (Cursor, Lovable, Claude Code, GitHub Copilot) don't know about each other.
The simplest fix is to close the gap structurally: put the spec in the repo.
When PRD.md lives in your repository, it's in the same place as everything else. It gets committed when it changes. You can see exactly when the navigation pattern was updated, or when the auth requirements changed. And your AI coding tool can read it without you pasting it in every session.
How the Draftlytic GitHub integration works
When you open a project in Draftlytic, there's a new option in the Export menu: Push to GitHub.
Click it, connect your GitHub account, and you'll see two paths:
- Existing repo: pick any repo the Draftlytic GitHub App is installed on, and push
PRD.mdto its default branch (as a direct commit) or open a pull request. - New repo: not supported in this iteration. The cleaner flow is to create the repo on GitHub, install the App on it, then push the spec in. Takes about 90 seconds.
The file always lands at the root as PRD.md. No configuration, no path override. PRD.md in the root is the most discoverable location for both humans and AI coding tools.
Push again after you refine the spec. Draftlytic reads the current PRD.md SHA, updates the file in a new commit, and the history follows. Each push gets a commit authored by Draftlytic[bot] with a Co-authored-by: trailer crediting you on the commit.
For teams or careful solo workflows, the pull request option is useful: Draftlytic creates a new branch named something like draftlytic/update-20260526-143200 and opens a PR. You review the spec diff before it lands.
Setting it up: one install, any project
The integration uses a GitHub App, which means you install it once per GitHub account and choose which repos it can access. You're not granting Draftlytic access to all your repositories by default.
From Settings → Integrations in Draftlytic, click Install GitHub App. GitHub shows you the install screen. Pick "Only select repositories" and choose the repo or repos you want Draftlytic to push to. Confirm.
That's the setup. From then on, any Draftlytic project can push to any repo in that list. You can add more repos to the install later from your GitHub settings, and the picker in Draftlytic will reflect the update the next time you open the push modal.
The integration is available on any paid Draftlytic plan. Free accounts can see the option but can't push until they upgrade — if you're considering it, the Draftlytic pricing page has the breakdown.
What your AI coding tool gets from a PRD.md in the repo
The immediate practical gain: when you open Cursor, Claude Code, or GitHub Copilot on a project that has a PRD.md, you can reference it by file path instead of pasting. Something like:
Read the spec in PRD.md, then build the auth flow described there.
No copy-paste. The tool reads from disk. If you updated the spec since you last opened the project, it reads the latest version. If you've added features or revised acceptance criteria, those changes are already in the file the tool will read.
For tools like Lovable or v0 that work through a web interface, the gain is slightly different: you can reference the GitHub URL of PRD.md in your prompts, or download it from the repo when you need it. It's not automatic context, but it's in a known, stable location you can always point to.
The longer-term benefit is version history. If you look at your repo six months from now and wonder why the data model works the way it does, the commit history on PRD.md tells that story. "Switched to per-user workspaces after user feedback" shows up as a commit dated the week you made the call, not as lost context in a Notion page that nobody updates.
What goes into the PRD that gets pushed is the same content as the download export: features, acceptance criteria, data model, tech stack, design style, and the rest. Nothing gets stripped because it's going to GitHub instead of your desktop.
Why it's a per-repo install
GitHub Apps (unlike older OAuth integrations) let users control exactly which repositories the app can access. When you install Draftlytic, you pick the repos. That list is specific to your install.
This matters for two reasons.
First, it means Draftlytic only has write access to repos you explicitly chose. If you have 200 repos, Draftlytic can only push to the three you installed it on.
Second, if Draftlytic can't see the repo you want, it's because the App isn't installed on that repo yet. The push modal shows a "Don't see your repo?" link that opens your installation settings on GitHub, where you can add more repos in about ten seconds. The picker in Draftlytic will show the new repo the next time you open it.
This install model is intentional, not a limitation. It's the same pattern Vercel, Linear, and GitHub Actions use, and it's the right tradeoff between access and trust.
Getting started
If you already have a Draftlytic project, open it, click Export, and look for Push to GitHub. If you haven't connected GitHub yet, the modal will walk you through the install. The whole setup takes under two minutes.
If you're new to Draftlytic, how to use Draftlytic to plan an app covers the creation flow end-to-end. The GitHub push is the last step, not the first, and it's optional — the export download still works the same way it always did.
The spec belongs in the repo. Now it's one click to put it there.