Product
Specs, tickets and the decisions behind them, searchable by every agent.
Who it's for
Product managers, designers and product leads. Also anyone who needs to know why the product works the way it does.
What Workstate does for you
Workstate keeps the answer to "why did we choose X?" findable. Specs live in Confluence, work lives in Jira, and research lives in documents you upload. The decisions that connect them live in the ledger. Each decision records the question it answered, the choice made and the options rejected.
Your agent checks that record before it drafts a spec, so a settled debate doesn't reopen by accident. When a decision changes, the new topic shows which one it replaced.
The prompts below are illustrative. Change the names to your own.
Answer "why did we choose X?"
text
Why did we choose usage-based pricing for the API tier? Search the ledger and Confluence. Give me the decision, who recorded it and when, what we rejected, and cite each source.The ledger records the person behind every topic and every entry, so you can see who recorded a decision and when.
Draft a spec grounded in earlier decisions
text
Draft a one-page spec for bulk invitations. First search our specs and the ledger for related decisions, and list any that constrain the design, with citations.Summarise what customers are asking for
text
Summarise open Jira issues about onboarding friction, grouped by theme, with issue keys.Record a decision when you make it
text
Record a decision in project "product", status accepted: we ship CSV export before the public API. The question was which enterprise request to do first. Include the reasons and the options we rejected.Sources to connect
Available now
- Confluence, for product requirements, specs and meeting notes.
- Jira, for epics, issues and their comments.
- Upload files, for research reports and interview notes (PDF, Word), roadmap decks (PowerPoint) and spreadsheets (Excel).
- GitHub, when you need to check what's actually built.
Coming soon
- Google Drive Coming soon
- Notion Coming soon
- Linear Coming soon
- Slack Coming soon
Instructions to give your agents
Add these rules to the shared agent instructions:
md
- Before proposing a feature, pricing change or scope cut, search the ledger for earlier decisions on the same question. Quote any accepted decision, and ask before contradicting it.
- Cite the spec, issue or ledger topic behind every claim.
- When a decision is made, record it as its own topic in project "product": the question as the summary, the choice and reasons as the current state.
- When a decision changes, record the new one and supersede the old one.Ledger habits
- One decision per topic. "Ship CSV export first" and "price the API by usage" are two topics, not one roadmap topic.
- Write the summary as the question. The summary never changes after the topic opens, so it should frame the question, not the answer.
- Supersede, don't edit. The old decision stays in the history, marked superseded, so "we tried that" has evidence.
- Investigation for research findings, such as why customers skip a feature.
An illustrative example
Illustrative
A new product manager asks their agent why there's no free tier. The agent finds product-0031, a decision to drop the free tier because of support load, now marked superseded. It also finds product-0044, which replaced it with a 14-day trial after the support tooling improved.
The agent cites both. The manager sees the current position and why it changed, without having to ask around.
Limits to know
- The ledger holds only what someone recorded. A decision made in a meeting and never recorded isn't there.
- For PDF and Office files, Workstate indexes the extracted text only. Charts and images in a deck aren't searchable, and a scanned PDF with no text layer has no text to index.
- Uploaded files change only when someone uploads a new version, so an old roadmap deck can look current. Ask an admin to replace or delete files that are out of date.
- Everyone with access to the namespace sees everything in it.