Start here
Command surface
Watch it run
ProductAbout
Use cases
Examples
Who is for
Beyond delivery
Accelerators
Memory
Docs
Consulting
Install PureinnGitHub
Use cases

The mess you're dreading? One command.

Legacy chaos. A spec you have no time to write. An investor about to grill you. One command each - and what lands is a domain model, a sequence diagram, a reconciliation report. Not a pep talk, not a summary.

The Rebuild

You inherited a codebase nobody documented - and it ships to production tomorrow.

Something real got built and shipped - then the people who understood it moved on. But the truth didn't leave with them. It's still in the code: the state machines, the rules, the edge cases, all there, just unread and scattered across files nobody has mapped. The docs you have describe a version from two rewrites ago. What you're missing isn't the logic. It's someone to read it back out.

❯ /pm-reverse-extract# pull the feature inventory straight from the code
❯ /pm-reconcile# reconcile code against whatever docs exist, any format
You walk out with
  • A clean domain model and entity registry, with the state machines read back out of the code
  • A business rules library, de-duplicated and given stable IDs
  • A scored, phased feature backlog
  • A reconciliation report: every conflict between code and docs surfaced, never silently merged - you decide how to resolve each one
  • A coverage check that proves whether the legacy docs are safe to archive
Code is structural truth. Docs are business logic. Where they conflict, you decide - nothing is silently picked or averaged.
Read the full reconciliation path →
The Feature Sprint

Payment gateway. Starts tomorrow. No spec, no time to write one.

The app already ships. This one is gnarly enough to deserve a spec - idempotency, retries, webhook races, partial refunds - but a full PRD up front is waste. Half of it rots before a line ships; the other half you rethink the moment you see the real API. So most teams skip the spec and pay for it in the code.

❯ /pm-feature-design FEAT-PAY-001
You walk out with
  • The business constraints and rules that govern just this one feature
  • Acceptance criteria a developer, or an AI builder, can execute against
  • A Mermaid sequence diagram of the flow, edge cases included
  • The UX context the feature touches
  • A Feature Card moved to Ready to Build
The discipline of a real spec, scoped to one feature, written the day before you build it. An hour later you are coding - against a diagram, not a hunch.
How just-in-time design works →
The Stress Test

You pitch angels tomorrow. Guess which question you haven't rehearsed.

You have rehearsed the story you want to tell. You have not rehearsed the one your weakest assumption is hiding behind - the unit economics, the churn math, the part of the architecture that doesn't survive scale. That question should not get asked for the first time in the room with the check on the table.

❯ /pm-stress-test
You walk out with
  • The framework role-plays a hostile investor, CFO, or CTO
  • Multiple rounds of adversarial pushback on your business model and your tech stack
  • Your weakest points surfaced and pressure-tested while it is still cheap to fix them
Survive the toughest room before you are in it - while a wrong answer still costs nothing.
The stress-test engine →

Your situation isn't here? It's still one command.

These are three of many. You don't pick the path up front - the orchestrator detects where you are and routes you to the right skill.

Install PureinnBrowse every command