User insights belong in the repo

It's a Product repo, not a Code repo

As a recovering product manager, I spent countless hours making PowerPoints and documents that lived in shared drives or a company-wide permissioned document share, never even thinking about how engineers stored and managed their code. We'd collaborate in document editors and deal with the almost weekly 'save conflict' or 'version conflict' issues that even the best office suites experience. Maybe if I just rename the file xxxx-final.docx people will realize it really is the final version.

Expand outward from PMs to designers and UX researchers, and they had their own assets in their own systems or document shares. What a mess. All the while our engineering friends have an amazing system in place that ensures one true source of truth, lets everyone work on their own copy, and brings the changes back together cleanly. They've been doing it for years.

AI-enabled coding turned me into a builder PM, and I've fallen in love with Git and pull requests: the system engineers use to track every change, and the way they review it. It's actually magic, and I'm surprised the other product roles haven't caught on sooner.

All product context belongs in the repo

If this is not how your team works yet, it is usually because the spec and the research still live in a different tool from the code. When engineers build a feature, they pull up a spec, break it into tasks in a work item tracker (which likely also lives away from the code), and then hunt those external resources while writing code. That is a missed opportunity. No one would intentionally put silos between the implementation and the requirements for it. We just ended up here because the world we came from was siloed. But that world is dead. If you were designing a process from the ground up, you'd want every "context contributor" (product, UXR, design, support, data science, and so on) to contribute to engineering at the highest fidelity, and vice versa. A solution could be built for that. But what if one already exists and we just aren't using it?

That's the repo. You might lack access or experience with it today, which is the first hurdle. The second is what specgit was made for: Git hosts like GitHub are underwhelming for context contributors.

Put the research where the code already is

1. Sign in with a GitHub account and pick the repo. Empty is fine. You need write access to save; reading and commenting do not consume a seat.

2. Install the specgit GitHub App on that repo. Open a file that is already there, start from a template, or import Word or PDF. Put research notes, decision logs, and specs in a docs folder a human can actually find.

3. Point coding agents at that folder. In the instructions file your agents read (usually AGENTS.md), say where the docs live and that they are the source of truth for product intent, so an agent building the feature has the condition in context instead of only the ticket.

4. Collaborate in the repo the same way engineering does, but without worrying about the mechanics thanks to specgit.

The editor at /try runs without an account. Connect a repo (empty is fine), and the free tier is one repository and five publishes a month, unlimited collaborators, no card. Seats count editors only; reading and commenting never consume a seat. Pricing has the rest.

specgit never keeps a copy of your documents or comments. That's our Zero Content Retention promise. The model providers never train models on the inputs or outputs of AI requests. The exceptions are narrow and written out on privacy and security.