AI drafts the ticket. You edit what it gets wrong.
Hand @devintern a rough idea: a line of intent, a customer log, or a design link. It scans your codebase and generates a structured story with acceptance criteria. You review the draft, fix what it missed, and post to Jira, Linear, or wherever you already work. Faster than writing the ticket from scratch, and worth the extra pass: when /pm@devintern or your team picks it up, the spec carries enough context to act on, not a rushed template someone still has to interpret. Less back-and-forth for whoever implements it next.
/code
specs · triage · handoffs
preview before you post
Jira · Linear · Asana · more
fewer Slack threads · standup gaps
The blank-page trap
Writing a perfect ticket from scratch is slow. Finding out what you forgot is worse.
You already know the idea. You shouldn't have to sweat every field on a blank Jira template just to discover in standup that an edge case never made it in. That's the blank-page trap: writing the ticket from scratch feels like the job, but the real cost is finding out what you forgot after engineering has already started.
@devintern breaks that cycle. Drop in rough input; AI scans your codebase and drafts the structure, acceptance criteria, and context. You review what it got wrong and fix the gaps, faster than starting from zero and closer to the job PMs are actually good at.
/pm
Worth the extra pass before you post: when @devintern or your team picks up the ticket, the spec carries enough to act on, not a rushed template someone still has to interpret in Slack. Less back-and-forth for whoever implements it next.
/code
Same ticket, two mornings
What a ticket looks like before and after.
Left: starting from nothing. Right: an AI-generated draft you tweak before engineering picks it up, not a ticket you prayed was complete.
Title
Description
Acceptance criteria
Affected files
Parent story
cursor blinking, slack pinging, day evaporating
Title
Onboarding: persist invite source across signup redirect
Description
When a user follows an invite link and bounces through the OAuth provider, the invite token is dropped on return.
Persist the source so the post-signup screen credits the correct workspace. Include rollback if OAuth fails mid-flow and logging so support can trace invite attribution end to end.
Acceptance criteria
- Invite token stored in a short-lived cookie before redirect
- Token re-read on /auth/callback and attached to the new session
- Workspace assignment succeeds without a manual re-invite
Affected files
- src/auth/oauth-redirect.ts
- src/auth/callback-handler.ts
Parent story
ONB-410 · Onboarding polish
You fixed what the draft missed, not discovered it in standup.
Three ways in
Whatever you've got, the planning tool takes it.
Same workflow every time: rough input in, AI draft out, you edit before it ships. One muscle to learn, three flavors of input.
Plain prompt
One rough line of intent. AI drafts the story; you fix what it missed before anyone picks it up.
Error log
Paste a Sentry trace or customer report. AI structures the bug ticket; you adjust details if needed.
Figma URL
Drop a frame link. AI drafts a story to implement the design in full, including layout and functionality. Add context for what's on screen, then adjust anything it misread before you post.
The handoff, redrawn
One idea through your SDLC, from nothing in Jira to done.
Follow a simple request to turn off the weekly digest, before NOTIF-47 even exists. @devintern compresses planning into a reviewed story; /pm@devintern or your engineer compresses development from that story to shipped work.
/code
- 01 Idea
Nothing in the tracker yet.
Stakeholders want "Let users turn off the weekly digest email": a note in Slack, a line on the roadmap, not a ticket. You know what to build; you haven't written it up.
- 02 To do @devintern/pm
@devintern/pm drafts the product story.
Rough prompt in. @devintern/pm scans your product context, writes clear acceptance criteria, and links NOTIF-47 to the parent epic. You preview, edit what it missed, and post to Jira in ~2 minutes instead of a blank template.
- 03 In progress
An engineer or @devintern/code picks it up.
Your teammate pulls NOTIF-47 into the sprint, or runs @devintern/code on it. Either way, a reviewed product story beats a one-liner: the human isn't decoding intent from scratch, and the agent isn't guessing at scope.
- 04 In review @devintern/code
PR in review, built from a real spec.
@devintern/code worked the detailed implementation spec and opened a draft PR. A human on the same ticket would ship from the same acceptance criteria, with fewer "what did we mean by off?" threads either way.
- 05 Done
Review outcomes: planning and development, compressed.
Planning went from a Slack note to a reviewed story in minutes; build went from that story to a PR without the usual back-and-forth. You confirm the shipped product matches your acceptance criteria.
Your job · draft the story
@devintern gets you to a reviewed, tracker-ready story: clear acceptance criteria, user-facing behavior, parent links. The product spec PMs are actually good at writing, without starting from a blank Jira template.
/pm
Whoever builds it · human or AI
A clear product story helps both paths. Your engineer starts with acceptance criteria instead of a Slack thread; @devintern works the detailed implementation spec and can run the ticket end to end. Same story, less reinterpretation either way.
/code
Your week back
The five things that used to eat your day.
With @devintern/pm
Draft in minutes · ready for human or AI
- Drop a rough idea. AI drafts the story in ~2 minutes. You edit what it missed before anyone picks it up.
- Paste the log. A structured ticket comes back with stack-trace context and a clearer fix path.
- Acceptance criteria reflect real product behavior, not a generic template someone still has to decode.
- Link to the parent epic when you post, and the backlog stays organized without retyping context.
- Stories land detailed enough for your engineer or @devintern/code to implement, with less reinterpretation either way.
Your day without it
Blank templates · clarification threads
- Spend 45 minutes on a blank template, then hear in standup you forgot an edge case.
- Reshape a customer error report into a reproducible bug ticket.
- Re-explain acceptance criteria at standup because the spec missed how the product actually works.
- Write a story and forget to tie it back to the epic it belongs to.
- Hand off a thin ticket and spend the next day clarifying scope in Slack.
~10 hours saved
per PM, per week
Why IT and Procurement will say yes
100% self-hosted. No new vendor for security to review.
The reason this works inside enterprises: engineering already runs it, on infra you own, using the AI contract you already have. Four reasons your internal stakeholders won't push back.
Zero extra cloud bill
Engineering already runs it on infra you own. Procurement doesn't need to defend a new SaaS line item, and you don't need to wait three weeks for budget.
Native access to internal context
Your repo, internal tools, and team docs feed the draft. Tickets land grounded in how your product is actually built, not generic templates that miss the details engineering will ask about anyway.
Compliance, by default
Roadmap notes, customer logs, and error reports stay inside your perimeter. Security review becomes a paragraph instead of a quarter.
Reuses existing AI contracts
Plugs into the AI vendor your company already approved. No new procurement, no new vendor security review, no second invoice for tokens.
What's inside
Built for the way PMs already work.
No new system to learn. Plugs into the tracker and AI vendor your team already uses, with optional design handoffs when you need them.
-
AI drafts, you decide
The first version comes from AI, not a blank template. Preview the draft, revise what needs fixing, or edit in your tracker after it posts. You're still the PM; you just aren't starting from zero.
-
Reads your codebase first
Acceptance criteria written after scanning the repo, so the draft names real files and APIs, not guesses you'll fix later in Slack.
-
Three ways in, one tool
Free-form prompt, pasted log, or Figma URL: rough input in, structured draft out, same review-and-edit step every time.
-
PM voice by default
Product work drafts as user stories with acceptance criteria. Switch to technical voice when the ticket is engineering-facing: bugs, refactors, or tasks that need implementation detail.
-
Posts to 7 trackers
Jira, Linear, Trello, Asana, Azure DevOps, GitHub Issues, or Markdown, directly, no copy-paste.
-
Link parent stories
Attach new work to an existing story or epic, keeping the backlog organized without retyping context.
-
Extra context when you need it
Add edge cases, constraints, or notes that didn't fit in your initial prompt, so the draft reflects what you already know.
Next step
Generate your first draft before your next sync.
Install @devintern, run it on a real idea in flight, and edit the draft before you post. You'll know faster whether the ticket is ready, without spending an afternoon on a blank template.
/pm
14-day trial · runs on your laptop · no new vendor for IT
- Day 1 Install devpm · connect your tracker · run devpm --interactive once
- Days 2–4 Draft from a prompt, customer log, or Figma URL · preview · edit · post
- Days 5–9 Hand a reviewed story to @devintern/code · free up your engineer's time for harder work
- Days 10–14 Compare standup gaps and hours on specs · decide if it's worth keeping in your workflow
Also evaluating DevIntern for another role in your org?