Filing feedback · bug reports, feature requests, and improvements

How to file a bug, request a feature, or propose an improvement; vote on what matters; and choose between workspace-only and public visibility.

Updated 2026-04-26 · By Jonathan Lasley

Feedback is how you tell the team what's broken, what's missing, or what's awkward. Every entry shows up on a triage board, gets voted on, accumulates discussion in comments, and moves through a public status workflow as the team picks it up. You can keep an entry private to your workspace, or surface it to every Prompt Assay customer to build a community signal.

What you can file

Bug · something is broken or behaving incorrectly. Include steps to reproduce, what you expected, and what actually happened.
Feature · something Prompt Assay doesn't do yet that you'd like it to do.
Improvement · something that already works but is awkward, slow, or rough around the edges.

Three ways to submit

From the Feedback page
Click 'Feedback' in the sidebar to open the board. Hit 'Submit feedback' in the top-right to open the submission form.
From the help bubble
The floating help button in the bottom-right of every page has a 'Send product feedback' link in its footer. Clicking it opens the submission form with the current page automatically attached as context (so the team knows where you were when you ran into the issue).
From an open help article
If you opened a help article via the bubble and the answer didn't fit your situation, the same 'Send product feedback' footer link will pre-fill the article id alongside the page route, so the team can see exactly which doc was inadequate.

Workspace only or public

Every entry has a visibility setting. You choose it when you submit; you can change it while the entry is still 'New' (before triage starts).

Setting	Who can see it	When to choose it
Workspace only (default)	Members of your workspace only.	Internal-only feedback. Bug reports tied to your specific data, sensitive information, or anything you don't want surfaced beyond your team.
Public	Every logged-in Prompt Assay customer, across all workspaces.	Bug reports anyone could hit, feature requests that benefit the whole user base, and anything where you want to rally other customers' votes.

Why public matters

Public entries accumulate votes and comments from every customer who can see them. If 50 people independently want the same feature, having one public entry with 50 votes is far more useful to the team than 50 separate workspace-only entries with one vote each.

What public actually exposes

Public entries show your title, description, and the email address that filed it to every other Prompt Assay customer. Don't include workspace-specific identifiers, customer data, or secrets. If you submit something workspace-only and later promote it to public, the title and description visible at promotion time become visible to other customers · review the entry before promoting.

The four-column workflow

Bugs and Features each have their own board with the same four columns. Entries move left to right as the team picks them up.

Column	What it means
Future Requests	Filed but not yet evaluated. Anyone can vote and comment to shape priority.
Planned	Reviewed and committed to a future release. The team will work on it; specific timing is not promised.
In Progress	Active development. Status updates may show up as admin comments on the entry.
Shipped	Released to production. Comments are closed; the entry stands as a record.

There's a fifth state, Declined, that doesn't get its own column. Entries land here when the team decides not to pursue them. You can still reach a declined entry via its direct URL or via the link on the entry's notification email; comments are closed.

Voting

Each entry has a single upvote button. Click to vote; click again to remove your vote. You can vote on your own entries (it doesn't auto-apply at submission · upvoting your own is a deliberate signal that you want to amplify it). On public entries, votes accumulate from every Prompt Assay customer who can see it; on workspace-only entries, votes accumulate from your workspace members only.

Comments

Anyone who can see an entry can post comments on it. Workspace-only entries get workspace-internal discussion; public entries get cross-customer discussion.
Comments stay open through New, Under Review, Planned, and In Progress. They close automatically once the entry is Shipped or Declined.
You can delete your own comment within five minutes of posting it (the typo-retraction window). After that, comments are immutable.

Editing or deleting your own entry

While your entry is still in 'New' status (before the team has triaged it), you can edit its title, description, or visibility yourself. Open the entry's detail page and use the 'Edit entry' button below the description; a 'Delete' button sits next to it for removing the entry entirely (this also removes any votes and comments on it).

Once the team moves the entry to Under Review or any later status, the Edit and Delete buttons disappear so the triage thread stays coherent. If you need to walk back an entry after triage has started, email support and an admin can adjust or demote it on your behalf.

Internal admin notes

Admins can post 'internal notes' on any entry. These are admin-only · they're stored alongside the entry's public comments but isolated by row-level security. You will never see internal notes on any entry, regardless of who filed it or whether the entry is public. They're used for triage discussion that shouldn't leak into the customer conversation thread.

Privacy summary

Workspace-only entries never leave your workspace · admins read them via the Admin Console for triage but they never appear on any other customer's board. Public entries are visible to all logged-in Prompt Assay customers but not to logged-out visitors or search engines · feedback is not yet a public roadmap surface. Internal admin notes are admin-only on every entry, regardless of visibility.

Email notifications

Submitting an entry triggers a one-shot email to the Prompt Assay team so they see it on the same day it lands. Status changes, votes, and comments do not trigger additional emails to you · check the board to see how an entry has moved.

What to include in a good bug report

Steps to reproduce · the exact sequence of clicks, the URL, and any input. The team's first move is to try to reproduce; the easier you make it, the faster you get a fix.
Expected vs actual · what you expected to happen and what actually happened. 'Broken' alone is rarely enough.
Browser and OS if the bug looks UI-related.
Prompt content if a specific prompt triggers the bug · paste it inside triple-backtick code fences so formatting survives.
Workspace name if you think the bug is data-specific (admins can look up the row from the workspace name).

← All docs Open the editor →