Scriptonia is an AI-native product management workspace that turns rough ideas into production-ready PRDs, architecture blueprints, and engineering tickets in under 30 seconds. It is often described as the 'Cursor for Product Managers.' It is designed for product managers, founders, engineering leads, and startup teams.

How fast does Scriptonia generate a PRD?

Scriptonia generates a complete PRD — including objective, problem statement, user stories, success metrics, technical requirements, and timeline — in under 30 seconds using frontier AI models.

Does Scriptonia integrate with Linear, Notion, and Jira?

Yes. Scriptonia exports directly to Linear, Notion, GitHub Issues, Jira, Confluence, and Slack. It can also export to Markdown for use with any other tool.

Is there a free plan?

Yes. Scriptonia's free plan includes 30 credits per month, unlimited PRDs, Markdown export, and a public share link. No credit card required. You can also try it without creating an account at scriptonia.dev/try.

What AI models does Scriptonia use?

Scriptonia Pro and Team plans give access to multiple frontier AI models including Claude Sonnet (Anthropic), Gemini 2.5 Flash (Google), Grok 4 (xAI), DeepSeek R1, and Kimi K2. The free plan uses Grok 4 Fast.

Who is Scriptonia for?

Scriptonia is built for product managers, founders, engineering leads, and startup teams who need to move from idea to specification quickly. It removes the hours of manual writing that traditionally goes into a PRD.

A PRD (Product Requirements Document) is a specification that describes the purpose, features, functionality, and behavior of a product to be built. Scriptonia automatically generates structured PRDs from plain-language product ideas.

What are acceptance criteria in a PRD?

Acceptance criteria are testable statements that define when a user story is done. They are written in Given/When/Then format: Given [precondition], When [action], Then [expected result]. Each criterion maps to a test case. A user story without acceptance criteria cannot be verified by QA and is a common source of mid-sprint clarification requests.

How many acceptance criteria should a user story have?

3–5 per story. Fewer than 3 usually means the story is underspecified. More than 7 usually means the story should be split into two. The most commonly forgotten criteria are negative paths (what happens when it fails) and edge cases (empty state, permission denied, timeout).

What's the difference between acceptance criteria and definition of done?

Acceptance criteria are specific to a single user story — they define what that story must do to be accepted. Definition of done (DoD) is a team-level standard that applies to all stories — it typically includes code review, passing tests, documentation, and deployment to staging. A story passes acceptance criteria when the feature behaves correctly; it's done when it also meets the DoD.

How do you write acceptance criteria for non-functional requirements?

Use the same Given/When/Then format with measurable thresholds: 'Given 1,000 concurrent users, When they all make a search request simultaneously, Then 95% of responses return within 2 seconds.' For availability: 'Given the service is in production, When measured over any 30-day period, Then uptime is ≥99.5%.' Measurability is the key — avoid vague non-functional criteria like 'the system should be fast.'

Can AI write acceptance criteria?

Yes. AI tools like Scriptonia generate acceptance criteria from user stories automatically. AI is particularly good at generating negative path criteria (error states, permission failures, edge cases) that PMs often forget. Always review AI-generated criteria against your QA process — some may be too generic for your specific system's error handling.

Acceptance criteria examples: 25 real patterns from production PRDs

Acceptance criteria are the most important and most commonly miswritten section of any PRD. 68% of engineering re-requests trace back to missing or vague acceptance criteria (Scriptonia, 2026). These 25 examples show the difference between criteria that eliminate ambiguity and criteria that create it.

"Good acceptance criteria read like test cases. If a QA engineer can write an automated test from reading your criterion, it's specific enough. If they have to ask a question, it's not."
— Tomas R., QA Lead at a SaaS platform company

The Given/When/Then format: why it works

Given [precondition], When [action], Then [expected result].

This format works because it forces three things: context specificity (Given), action precision (When), and verifiable outcome (Then). Each criterion maps directly to a test case.

Authentication and access control examples

Given a user has not completed email verification, When they attempt to access the dashboard, Then they are redirected to the email verification screen with a "Resend email" option.
Given an admin attempts to downgrade a co-admin's role, When they submit the role change, Then the system shows an error: "You cannot change the role of another admin without owner permission."
Given a session token has been inactive for 30 minutes, When the user attempts any authenticated action, Then the session is invalidated and the user is redirected to the login screen with the message "Your session has expired."

Form validation examples

Given a required field is left empty, When the user submits the form, Then the field is highlighted in red and the error message "[Field name] is required" appears below it. The form is not submitted.
Given an email address is entered without an "@" symbol, When the user moves focus away from the field, Then an inline error appears: "Please enter a valid email address."
Given a password field requires 8+ characters, When the user submits a 7-character password, Then the submission is blocked and the error reads: "Password must be at least 8 characters."

Data export examples

Given an admin requests a CSV export of team activity, When the export is complete, Then a CSV file downloads with columns: User, Action, Timestamp, IP Address — one row per event.
Given the export date range spans more than 90 days, When the admin clicks Export, Then the export is blocked with the message: "Export range is limited to 90 days."
Given no activity exists in the selected date range, When the admin exports, Then a CSV downloads with headers only and a notification: "No activity found for this period."

Notification examples

Given a user has email notifications enabled for comments, When another user comments on their document, Then an email is sent to the document owner within 2 minutes containing the commenter's name and the first 100 characters of the comment.
Given a user has turned off all notifications, When any event occurs, Then no email or in-app notification is sent.

Performance and scale examples

Given a list view contains more than 1,000 rows, When the page loads, Then only the first 50 rows are rendered. Pagination controls allow navigation to subsequent pages.
Given an API request to /search is made with a query string, When the response time exceeds 2 seconds, Then the response includes a 408 status code and the error: "Request timeout — please try a more specific search."

Error and empty state examples

Given a user navigates to a URL for a deleted resource, When the page loads, Then a 404 page is shown with the message "This page doesn't exist" and a link to the dashboard.
Given a user's connected integration returns an auth error, When they view the integration settings page, Then a red "Reconnect required" badge appears next to the integration name.

The 5 acceptance criteria anti-patterns

Anti-pattern	Example	Problem
Too vague	"The feature works as expected"	Cannot be tested
Business language, not system language	"Users should have a great experience"	No testable condition
Ambiguous "should"	"The button should be visible"	Visible to whom? Under what conditions?
Missing precondition	"When user clicks submit, form submits"	Missing: what state is the form in?
Compound criteria	"Field validates AND submits AND redirects"	Three criteria, not one — untestable as a unit