Anyone here using OpenSpec, SpecKit, etc? I wonder if we could create something that would make sense from a Product perspective
I've been building software with AI agents for a while and ended up developing my own workflow. I start by writing a thorough, product-focused document describing the desired changes, which I call a product brief. I then ask the AI to identify gaps and ask…
I've been building software with AI agents for a while and ended up developing my own workflow. I start by writing a thorough, product-focused document describing the desired changes, which I call a product brief. I then ask the AI to identify gaps and ask any necessary questions before producing a technical implementation plan. I recently tried a spec-driven framework because I wanted to follow a more standardized workflow instead of maintaining my own custom process. I chose OpenSpec because it doesn't add too much overhead. However, I miss having an explicit first step for creating a simple but thorough product-focused document before moving into specifications and implementation planning. Has anyone experienced something similar? Would anyone be interested in working on a spec-driven framework that starts from a product perspective? I think it could be a useful addition for product people who build software with AI agents.
已收录讨论
You should look at the contributors of those repos before reinventing the wheel. Do some discovery yourself.
Superpowers:brainstorming works good enough for me, along with Codex’s Product Designer plugin for thinking through designs and UX considerations.
Interesting. All my specs start as brainstorms in Claude chat (could be ChatGPT or any other agent). I have a "/spec-it" skill I built that essentially applies house style to a spec, and I save the resulting doc off to Google Drive where I collaborate with other stakeholder. Then I load it into tooling I built where it's broken into stories and made available to Claude Code (or ChatGPT or any other agent) via MCP. So, yeah, I'm using a spec-driven workflow, too, and my prototypes are all built from a production branch so there isn't any reverse-engineering, just QA and hardening.
The gap is less about the framework and more about which artifact is authoritative. A product brief works well when it is defined as the set of inputs the spec is not allowed to invent: the problem, who has it, the outcome that counts as success, explicit non-goals, and hard constraints. Keep it in the same repo and version as the specs, so a change in intent shows up in a diff rather than in chat history. Two checks make it earn its place. First, if the spec could be written without reading the brief, the brief is decoration. Second, require the agent to return open questions and contradictions against the brief before any implementation plan, and treat a silent plan as a red flag. Adding a stage before specs is usually simpler than forking a framework.
Exactly this. I've been in the same boat moving between custom processes and standard frameworks, and keeping hitting the same friction point: specs want to start technical, but product decisions upstream need to be locked in first. I ended up building a platform specifically around this workflow: Epic (your product brief layer, where you capture decisions and intent), Flow (AI-assisted gap-finding and question-asking), then Story (the actual implementation spec). It treats the product phase as a first-class citizen, not a preamble. It allows me to start with a prompt and iterate over requirements using AI, thus eliminating the need of reading and writing walls of markdown text. So as a human I continue using my framework of a visual map, epics, stories while my AI counterpart gets the spec. Feel free to DM me.
Yes, I am doing this. I often use superpowers:brainstorming to talk though what I am looking for with the goal of creating a PRD to describe it clearly. In here we talk it over and apply things like MoSCoW. Keep solutions on “how” out unless that’s a part. I structure one or a few docs like this to describe the system. I stay focused on “mental units” of related things Then I feed them into openspec and explore and it is much stronger on determining “how” by this point. Sometimes I go back and relax or change the requirement if it’s not feasible. The key to knowing when you need another requirement is if you’re designing the thing you want or things it needs to exist in the first place.