Spec-driven project management
Turn specifications into
a living plan of work
Turn specs into tickets and sub-issues with AI. Each ticket comes with a description and acceptance criteria drawn from your context—and stays current as that context changes.
Book a demo
Not just a title.
A complete ticket.
AI fills in the description, acceptance criteria, and sub-issues. When a source artifact changes, the affected work is updated with it.
Implement organization SSO
Potpie populated this ticket and its 3 sub-issues from the specification.
Description
Let organizations connect their identity provider using SAML. Admins configure sign-in, and members authenticate through the organization’s login flow.
Acceptance criteria
- Admins can configure a SAML identity provider.
- Members sign in through SAML.
- Sign-in failures produce actionable error messages.
Sub-issues3
Populated by AIENG-209Configure identity providers
Add SAML provider configuration, including metadata, certificates, and validation.
Acceptance criteriaAdmins can save and validate a SAML configuration.
ENG-210Build organization sign-in
Route members through the organization’s SAML provider and handle the callback.
Acceptance criteriaA successful provider response creates a member session.
ENG-211Test SSO authentication
Cover successful and failed SAML sign-in, including expired certificates.
Acceptance criteriaRegression tests cover successful sign-in and recoverable errors.
Different artifacts.
One cohesive context.
Specs, tickets, code, PRs, and production share the same context across the software lifecycle. Tickets stay useful as the work evolves, instead of becoming a record of an outdated plan.
- Specifications
- Tickets & sub-issues
- Code
- Pull requests
- Production
A little more context.
How does a spec become tickets?
The specification is broken into actionable work, with scope and acceptance criteria drawn from the agreed requirements. Each ticket keeps a connection to the spec it came from, so it is more than a copied description.
What does AI populate in a ticket?
AI turns the requirements into a description, scope, acceptance criteria, and the sub-issues needed to implement the work. The parent ticket and its sub-issues retain their relationship to the source artifacts, so they can be updated together.
What happens when scope or a decision changes?
Potpie identifies the affected tickets and sub-issues, updates their descriptions and acceptance criteria, and adds work when the new scope requires it. The connection to the changed artifact stays visible, while earlier decisions remain part of the history.
Does editing a spec change production automatically?
No. Updating the specification and tickets does not bypass implementation, code review, or release. The connection makes it clear which work needs to change and which version has actually shipped. Your team retains control of review and deployment.
What stays connected after a ticket is closed?
The specification, its decisions, the ticket, the implementation, the pull request, and the release remain connected. A closed ticket can still explain what shipped and why—not just what someone planned at the start.