Users praise the ProductSpec open standard and GitHub-native editor because specs living directly in GitHub let agents execute intent without guessing while preventing docs from rotting in silos.
Based on 10 visible X reactions from 15 accounts; directional sample.
Ask a question below.
Published answers will appear here.
@gokulr This is the right direction for agentic work. A spec that only humans can interpret becomes a bottleneck; a spec that agents can execute but humans cannot trust becomes dangerous. The durable artifact has to serve both audiences
@keyur19198 Thank you! I think GStack can (and hopefully will) support ProductSpec as a format. ProductSpec is an open format to communicate intent to both humans and AI.
@gokulr Used ProductSpec today at work to build a high fidelity prototype! Looking forward to engg input soon!
@OguzSerdar Thank you! Will work on it.
PRODUCTSPEC IS READY FOR EARLY ADOPTERS A few weeks ago, I started with a simple question: What should replace the classic PRD? The answer became ProductSpec: an open standard for software intent before implementation. A Product Spec captures the things that need to survive handoff: • Problem • Hypothesis • Scope • Acceptance Criteria • Success Metrics • AI evals, when the product has model behavior • Decision Trace, when intent changes during implementation It is Markdown. It can live in Git. It has a validator, schema, GitHub Action, examples, starter kit, and agent skills. At this point, I don’t think the next step is adding more fields. The next step is usage. A standard gets better when real teams try it on real work. Not theoretical work. Actual specs. Actual PRDs. Actual docs that have to make it through product, design, engineering, agents, and launch. So I opened a set of good first issues for contributors. You can help by: • Adding ProductSpec examples for mobile app features, internal admin tools, or data products • Adding a Decision Trace example for implementation drift • Improving AI eval examples around model behavior • Mapping ProductSpec to Jira or Linear tickets • Trying ProductSpec on one existing PRD and reporting what feels awkward You don’t need to write parser code. A real example is enough. A critique from your team’s workflow is enough. A “this section doesn’t map to how we actually make decisions” issue is enough. The goal is not for ProductSpec to be my preferred spec format. The goal is for ProductSpec to become a broadly adopted standard for software intent: owned by builders, PMs, engineers, designers, founders, and teams using AI agents to build. If you work on consequential software, try converting one real PRD into ProductSpec this week. The standard gets stronger when real product work hits it.
FREE GITHUB-NATIVE PRODUCT SPEC EDITOR tl;dr ProductSpec dot IO is a free, privacy-friendly, GitHub-native editor for Product Specs. A few weeks ago, I started pulling on a thread: PRDs were built for a different era of software. They were mostly read by humans. They were often written once, debated in meetings, and then slowly drifted away from what actually shipped. AI agents change the job of the spec. A product spec now has to do 2 things at once: • Be readable by humans • Be executable by AI agents That realization led to the open source ProductSpec standard. (linked below) And it led to the next obvious need: PMs and builders need an editor that makes Product Specs easy to create. So today I’m sharing ProductSpec dot io. It’s a free, privacy-friendly, GitHub-native editor for Product Specs. You can draft a Product Spec in a clean editor, validate it against the open ProductSpec standard, and publish clean Markdown to GitHub when it’s ready for review. A few principles shaped it: 1. Product intent should live close to code 2. Specs shouldn’t disappear into a doc tool that engineers never open. ProductSpec dot io publishes Markdown into GitHub, where implementation already happens. 3. Drafts should stay private by default. We do not save drafts on our servers. Drafts stay in your browser until you choose to publish to GitHub. 4. PMs should not need to write raw Markdown. Markdown is the durable artifact. The editor is there because humans deserve a better writing surface. The Product Spec has sections for: • Problem • Hypothesis • Scope • Acceptance Criteria • AI Evals • Success Metrics • Optional sections like User Experience, Customer Truth, Risks, Rollout, and Open Questions The goal is simple: move from classic PRDs to Product Specs that humans can trust and agents can execute. If you’re a PM, founder, designer, engineer, or builder: take one existing PRD or new prodcut idea and convert it into a Product Spec this week. If you care about this becoming a broadly adopted standard, star the repo and contribute examples, schema feedback, parser improvements, or section vocabulary. PRDs had a good run. The enduring format will be ProductSpec: open, structured, human-readable, and agent executable.
Repo: https://github.com/gokulrajaram/ProductSpec Good first issues: https://github.com/gokulrajaram/ProductSpec/issues
Users praise the ProductSpec open standard and GitHub-native editor because specs living directly in GitHub let agents execute intent without guessing while preventing docs from rotting in silos.
Based on 10 visible X reactions from 15 accounts; directional sample.
Ask a question below.
Published answers will appear here.