devintern
For product managers Self-hosted

Specs engineering accepts. Small items that actually ship.

@devintern/pm turns a rough idea, a customer log, or a Figma frame into a ticket grounded in your codebase, so engineering can act on it without a clarification round-trip. And when a small item is specified that well, @devintern/code can ship it as a self-reviewed PR without competing for sprint capacity.

Get started See pricing Free for interactive use · no signup · first ticket in minutes
To your first ticket
Minutes
free · no signup

rough idea in, posted story out

Input types
3
prompt · log · Figma

same review-and-edit step every time

Trackers supported
7
direct post

Jira · Linear · Asana · more

In your codebase
Grounded
real files · real APIs

specs engineering can act on

The clarification round-trip

The spec was clear to you. The questions still came.

The gap between what you write and what engineering needs is where your week goes. A missing edge case, an ambiguous scope, a file the spec never named: each one becomes a Slack thread, a standup detour, and a day of waiting while the ticket sits half-started.

@devintern/pm closes that gap before you post. Drop in rough input; it scans your codebase and drafts the story with acceptance criteria, affected files, and real product behavior. You edit what it missed, which is the judgment call PMs are actually good at, and your first well-specified ticket is posted in minutes.

The small items that never make a sprint get a second path. Hand a well-specified ticket to @devintern/code and it comes back as a self-reviewed pull request; if the spec is vague, it gets flagged back to the tracker with questions instead of becoming a wrong guess.

Same ticket, two mornings

What a ticket looks like before and after.

Left: the ticket engineering will have questions about. Right: a draft grounded in the repo, edited by you before anyone picks it up.

Before · blank template
by hand

Title

Description

Acceptance criteria

Affected files

Parent story

cursor blinking, slack pinging, day evaporating

After · AI draft · you edited
drafted for you

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/pm compresses planning into a reviewed story; @devintern/code or your engineer compresses development from that story to shipped work.

Idea
To do
In progress
In review
Done
  1. 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.

  2. 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 one pass instead of starting from a blank template.

  3. 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.

  4. 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.

  5. 05
    Done

    A small item shipped without competing for sprint capacity.

    Planning went from a Slack note to a reviewed story in minutes; the story became a PR without a clarification round-trip. You confirm the shipped product matches your acceptance criteria.

Your job · draft the story

@devintern/pm 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.

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/code works the detailed implementation spec and can run the ticket end to end. Same story, less reinterpretation either way.

Send this to your tech lead

You can start today for free. The buying decision belongs to engineering.

Interactive use of @devintern/pm is free forever, so you don't need anyone's approval to post your first ticket. Unattended automation is the paid part, and that call sits with your tech lead. Here are the four answers they will want first.

Credentials stay local

Tracker tokens and repo access live on your team's machines and go only to their own vendors' APIs. Nothing except license checks touches DevIntern's servers, and the source is available to verify that.

Their agent, their keys

Works with the coding agent the team already uses: Claude Code, Codex, Cursor, or OpenCode, on the model contract they already pay for. No new vendor, no token markup.

30-day money-back on subscriptions

Team is $99 a month for up to 10 developers, less than a single engineer-hour a month. Business is $299 for up to 30. Both carry a 30-day money-back guarantee, and early pricing is locked in for as long as they stay subscribed.

Source-available under the FSL

They can read the code before pointing it at the repo, and each release converts to Apache-2.0 after two years. The worst case is "stops improving", never "stops working".

Next step

Post your first well-specified ticket before your next sync.

Install @devintern/pm, run it on an idea already in flight, and edit the draft before you post: minutes, not an afternoon. If the item is small and well specified, @devintern/code can turn it into a self-reviewed PR within the hour. Team and Business subscriptions carry a 30-day money-back guarantee.

Get started See pricing

Free for interactive use · no signup · credentials stay on your machines

Getting started
  1. Today Install devpm · connect your tracker · post your first well-specified ticket in minutes
  2. This week Run your real intake through it: prompts, customer logs, Figma URLs · send this page to your tech lead
  3. Next sprint Count the clarification threads that didn't happen · decide with your team

Also evaluating DevIntern for another role in your org?

Engineers Engineering managers Founders Consultants