Users approve of ProductSpec's Open Intent Harness for AI coding agents because it integrates with Jira, Linear, Figma and similar tools teams already rely on.
Based on 1 visible X reactions from 4 accounts; directional sample.
Ask a question below.
Published answers will appear here.
@gokulr sweet that it works with jira linear figma and other tools teams use
EVIDENCE LOOP FOR PRODUCTSPEC A Product Spec should not stop at launch. The common failure mode with product docs is that they describe intent before the work, then disappear once the work starts. A PR ships, an eval runs, a dashboard moves, a customer complains. BUT the product doc stays frozen. Then 3 weeks later, nobody knows which acceptance criterion the PR satisfied, which eval run proved the model behavior, or which dashboard showed whether the product bet worked. To fix this, we just added evidence support to ProductSpec. The core idea is simple: ProductSpec defines intent. Evidence shows what happened. Decision Trace records what changed. Related Artifacts now let teams attach evidence directly to ProductSpec IDs: • AC-1 can link to the PR, test, release, or code that implemented it • EVAL-1 can link to the eval run or human review record that checked model behavior • SM-1 can link to the dashboard, analytics snapshot, or experiment that measured the post-launch outcome This matters more as agents write more code. An agent can claim it implemented something. A PR can look complete. A test suite can pass. But the useful question is: which piece of product intent did this evidence satisfy? That is where structured specs start to matter. If AC-2 says the user can export a dashboard with visible filters preserved, the implementation PR should point back to AC-2. If EVAL-1 checks whether an AI support triage model correctly identifies account-risk tickets, the eval run should point back to EVAL-1. If SM-1 measures median time to first human response, the dashboard or analytics snapshot should point back to SM-1. This turns a Product Spec from a planning document into a record of intent plus proof. A few important boundaries: ProductSpec does not run evals. ProductSpec does not collect production traces. ProductSpec does not replace Braintrust, Langfuse, Datadog, GitHub, Linear, or your analytics stack. ProductSpec gives all of those artifacts a stable place to attach. The latest validator now catches stale evidence links. If a Related Artifact points to AC-99 and no AC-99 exists, that is invalid. It also warns when the evidence type looks mismatched, like an eval run attached to a success metric instead of an eval. This is the direction I’m most excited about: Software intent that survives implementation. Evidence that connects back to intent. Decision traces that explain what changed when reality pushed back. Founders and builders: if your team is using AI agents to build software, start asking for evidence against the spec, not just code against the ticket.
PRODUCTSPEC: THE OPEN INTENT HARNESS FOR AI-NATIVE SOFTWARE WORK The hardest part of using coding agents is not getting them to write code. It is getting them to stay attached to intent. A model can read a Markdown file. That part is easy. The real question is whether it knows: (a) What are we trying to build? (b) What are we explicitly not building? (c) What counts as done? (d) What evidence proves it? (e) What changed while the agent was working? That is where ProductSpec has been heading. Over the last few weeks, we’ve moved ProductSpec from “open standard for product specs” toward something sharper: ProductSpec is the harness contract for AI-native software work. A Product Spec now gives agents a structured control file: • Problem: who is hurting and why it matters • Hypothesis: the product bet • Scope: in, out, and cut • Acceptance Criteria: launch correctness • AI Evals: model behavior checks • Success Metrics: post-launch outcomes • Related Artifacts: evidence linked back to intent Then the surrounding tooling makes that contract usable. We added an MCP server so Claude, Codex, Cursor, and other agents can read Product Specs as structured context, not just raw Markdown. We added spec sessions so an agent can pin the spec revision and content hash before it starts work, then check whether the spec changed before claiming done. We added spec graphs so a folder of Product Specs can answer: which specs are buildable now, which are blocked, and what order they should be built in. We added Related Artifacts and Evidence Loop docs so PRs, eval runs, dashboards, analytics snapshots, releases, and experiments can attach back to AC-, EVAL-, and SM- IDs. We added Decision Trace so teams can record when evidence changes intent. And now we added Agent Run: a receipt for one agent execution against a pinned Product Spec. The new command is simple: productspec init-run <spec.product-spec.md> <run.agent-run.json> It drafts a receipt with every AC (Acceptance Criterion), EVAL (AI Eval), and SM (Success Metric) marked not_checked. The agent then fills in what passed, what failed, what evidence was produced, whether drift was detected, and what it is claiming is complete. The last part matters. Agents should not just say “done.” They should say: -- I worked against this spec revision. -- I checked these acceptance criteria. -- I ran or reviewed these evals. -- I produced this evidence. -- I detected or did not detect drift. That is the difference between AI-generated code and AI-accountable work. ProductSpec is becoming the contract that keeps humans, agents, code, evals, and evidence tied to the same intent. That is the open standard we are building.
http://www.github.com/gokulrajaram/ProductSpec
@gokulr sweet that it works with jira linear figma and other tools teams use
EVIDENCE LOOP FOR PRODUCTSPEC A Product Spec should not stop at launch. The common failure mode with product docs is that they describe intent before the work, then disappear once the work starts. A PR ships, an eval runs, a dashboard moves, a customer complains. BUT the product doc stays frozen. Then 3 weeks later, nobody knows which acceptance criterion the PR satisfied, which eval run proved the model behavior, or which dashboard showed whether the product bet worked. To fix this, we just added evidence support to ProductSpec. The core idea is simple: ProductSpec defines intent. Evidence shows what happened. Decision Trace records what changed. Related Artifacts now let teams attach evidence directly to ProductSpec IDs: • AC-1 can link to the PR, test, release, or code that implemented it • EVAL-1 can link to the eval run or human review record that checked model behavior • SM-1 can link to the dashboard, analytics snapshot, or experiment that measured the post-launch outcome This matters more as agents write more code. An agent can claim it implemented something. A PR can look complete. A test suite can pass. But the useful question is: which piece of product intent did this evidence satisfy? That is where structured specs start to matter. If AC-2 says the user can export a dashboard with visible filters preserved, the implementation PR should point back to AC-2. If EVAL-1 checks whether an AI support triage model correctly identifies account-risk tickets, the eval run should point back to EVAL-1. If SM-1 measures median time to first human response, the dashboard or analytics snapshot should point back to SM-1. This turns a Product Spec from a planning document into a record of intent plus proof. A few important boundaries: ProductSpec does not run evals. ProductSpec does not collect production traces. ProductSpec does not replace Braintrust, Langfuse, Datadog, GitHub, Linear, or your analytics stack. ProductSpec gives all of those artifacts a stable place to attach. The latest validator now catches stale evidence links. If a Related Artifact points to AC-99 and no AC-99 exists, that is invalid. It also warns when the evidence type looks mismatched, like an eval run attached to a success metric instead of an eval. This is the direction I’m most excited about: Software intent that survives implementation. Evidence that connects back to intent. Decision traces that explain what changed when reality pushed back. Founders and builders: if your team is using AI agents to build software, start asking for evidence against the spec, not just code against the ticket.
PRODUCTSPEC: THE OPEN INTENT HARNESS FOR AI-NATIVE SOFTWARE WORK The hardest part of using coding agents is not getting them to write code. It is getting them to stay attached to intent. A model can read a Markdown file. That part is easy. The real question is whether it knows: (a) What are we trying to build? (b) What are we explicitly not building? (c) What counts as done? (d) What evidence proves it? (e) What changed while the agent was working? That is where ProductSpec has been heading. Over the last few weeks, we’ve moved ProductSpec from “open standard for product specs” toward something sharper: ProductSpec is the harness contract for AI-native software work. A Product Spec now gives agents a structured control file: • Problem: who is hurting and why it matters • Hypothesis: the product bet • Scope: in, out, and cut • Acceptance Criteria: launch correctness • AI Evals: model behavior checks • Success Metrics: post-launch outcomes • Related Artifacts: evidence linked back to intent Then the surrounding tooling makes that contract usable. We added an MCP server so Claude, Codex, Cursor, and other agents can read Product Specs as structured context, not just raw Markdown. We added spec sessions so an agent can pin the spec revision and content hash before it starts work, then check whether the spec changed before claiming done. We added spec graphs so a folder of Product Specs can answer: which specs are buildable now, which are blocked, and what order they should be built in. We added Related Artifacts and Evidence Loop docs so PRs, eval runs, dashboards, analytics snapshots, releases, and experiments can attach back to AC-, EVAL-, and SM- IDs. We added Decision Trace so teams can record when evidence changes intent. And now we added Agent Run: a receipt for one agent execution against a pinned Product Spec. The new command is simple: productspec init-run <spec.product-spec.md> <run.agent-run.json> It drafts a receipt with every AC (Acceptance Criterion), EVAL (AI Eval), and SM (Success Metric) marked not_checked. The agent then fills in what passed, what failed, what evidence was produced, whether drift was detected, and what it is claiming is complete. The last part matters. Agents should not just say “done.” They should say: -- I worked against this spec revision. -- I checked these acceptance criteria. -- I ran or reviewed these evals. -- I produced this evidence. -- I detected or did not detect drift. That is the difference between AI-generated code and AI-accountable work. ProductSpec is becoming the contract that keeps humans, agents, code, evals, and evidence tied to the same intent. That is the open standard we are building.
Users approve of ProductSpec's Open Intent Harness for AI coding agents because it integrates with Jira, Linear, Figma and similar tools teams already rely on.
Based on 1 visible X reactions from 4 accounts; directional sample.
Ask a question below.
Published answers will appear here.