Herewegoal

You describe a feature idea in natural language and Herewegoal drafts a product spec around it. The output is meant to include the structure and acceptance criteria you'd otherwise write by hand, so the first draft exists before you sit down to outline it. This is the core of the product and the reason it bills itself as an AI-first workspace.

Before anyone commits to building a feature, the tool generates sample behavior so you can preview how it would work. Seeing a concrete example is often easier to react to than reading a requirements list, and it gives a small team something specific to agree or disagree on. The examples come out of the same AI credits as the rest of the workspace.

Herewegoal treats a spec as something to test, not just to write. You validate the assumptions behind a feature through user feedback, metrics, and AI checks, then fold what you learn back into the spec. The goal is to catch a wrong idea while it's still cheap to change.

You can bind a GitHub repository to the workspace and get a GitHub repo summary of the code that's already there. That matters when you spec new features on a codebase that already exists, because the spec can build on what's real rather than on a guess. The trial limits how many repositories you can bind, and the paid plan removes that cap.

Every spec is meant to end in clear acceptance criteria, the conditions that tell you when a feature is actually done. Writing them down front is how the tool tries to head off scope creep, since a feature that drifts past its criteria is easier to spot. It's a plain idea, and it's the part that makes the spec usable to a developer or a tester.

The workspace lets you invite team members, so the spec lives where the whole team can read and update it. Task name suggestions are unlimited and free on both plans, while the heavier AI actions draw on the shared credit pool. For a team under ten people, that's usually enough to keep everyone looking at the same plan.