For creatorsMake videos about AI coding? Earn 50% for life.Earn 50% for life.Become a Morphy creatorJoin →
morphy
Download

Flow template · Development

New product

Concept, docs, prototype, validation, build and QA, and you decide at every turn before the next one starts.

7 chats1 cardYou decide 3 timesWorks on a repositoryAny AI Morphy connects

Download dev-large.flow.jsonUse it in Morphy

Shared by MrApers · 25 October 2026

New product: the flow's shapeStart hands what you type to Concept. Concept's answer waits for you before it goes to Docs writer: Keep, Send back with what to change, or Drop. Docs writer's answer waits for you before it goes to Prototyper: Keep, Send back with what to change, or Drop. Prototyper hands its answer to Validator. Validator's answer waits for you before it goes to Builder: Keep, Send back with what to change, or Drop. Builder hands its answer to Reviewer. Reviewer hands its answer to QA. QA's answer lands in Pull requests (a results card).StartConceptthe repositoryDocs writerown copyPrototyperown copyValidatorown copyBuilderown copyReviewerthe repositoryQAown copyPull requestsresults cardyou decideyou decideyou decide
Left to right, as Morphy lays it out on your canvas: the Start, then each step. The blue arrows wait for you: keep the answer, send it back with what to change, or drop it.

What it does

For something new or big. A concept first, then a design doc in your repository, a prototype that proves the riskiest part, a validation that says GO or NO-GO, the real build, a code review and QA. You look at the concept, the design doc and the validation before the flow goes on: keep it, send it back with what to change, or drop it. Each chat that changes code works in its own copy of your repository (a git worktree on its own branch) and opens a pull request; the pull requests land in a results card for you to merge. Needs git and GitHub CLI (gh), signed in.

Its brief, which every chat in it works to: Changes go through a branch and a pull request, and the user merges. Never push to the main branch, force-push or delete branches.

Each step

  1. Conceptin the repository: Write the concept for what you are asked: the problem, who it is for, what success looks like, two or three ways to do it and the one you recommend, and what is out of scope. Keep it to a page.
  2. Docs writerin its own copy of the repository: Turn the approved concept into a design doc in the repository (docs/design/<topic>.md): architecture, data, interfaces, risks and a test plan. Commit it on your branch, push, open a pull request with only the doc (`gh pr create --fill`), and answer with its link and a summary.
  3. Prototyperin its own copy of the repository: From the design doc you get, build the smallest prototype that proves its riskiest part, on your own branch. Open a draft pull request (`gh pr create --draft --fill`) and answer with its link, what it proves and what it doesn’t.
  4. Validatorin its own copy of the repository: You get a prototype’s draft pull request. Check it out in your copy (`gh pr checkout <link>`), run it and try it against the concept and the design. Answer GO or NO-GO first, then what holds, what doesn’t and what the build must change.
  5. Builderin its own copy of the repository: Build the real thing from the design doc and what validation found, on your own branch, with tests. Commit, `git push -u origin HEAD`, `gh pr create --fill`, and answer with the link and a summary.
  6. Reviewerin the repository: You get a pull request’s link. Read it with `gh pr view <link>` and `gh pr diff <link>` and leave your review on GitHub (`gh pr review <link> --comment -b "…"`, or `--request-changes`). Answer with the link and APPROVED, or the changes to make.
  7. QAin its own copy of the repository: You get a reviewed pull request. `gh pr checkout <link>` in your copy, run the tests and try the change the way a user would. Leave the result on GitHub (`gh pr review <link> --comment -b "…"`). Answer with the link and PASS, or what failed and how to see it.
  8. Pull requests: A results card: everything that reaches it, in a list you can mark.

How the work moves

  • Start hands what you type to Concept.
  • Concept's answer waits for you before it goes to Docs writer: Keep, Send back with what to change, or Drop.
  • Docs writer's answer waits for you before it goes to Prototyper: Keep, Send back with what to change, or Drop.
  • Prototyper hands its answer to Validator.
  • Validator's answer waits for you before it goes to Builder: Keep, Send back with what to change, or Drop.
  • Builder hands its answer to Reviewer.
  • Reviewer hands its answer to QA.
  • QA's answer lands in Pull requests (a results card).

What you need

  • A git repository on your computer, with at least one commit
  • Git, and GitHub’s command line (gh), signed in with gh auth login
  • Any AI Morphy connects: Claude Code, Codex and the rest

Every change goes through a branch and a pull request, and you merge. Morphy gives each chat that changes code its own copy of your repository, next to it (a git worktree on a branch of its own).

Use it

  1. In Morphy: Settings → Community → Playground → Flow templates, pick New product and click Use this flow. Morphy asks which repository it works on, then builds it.
  2. Or from the file: download dev-large.flow.json and, on the same page, click Import a file…. It's yours to change, too.
  3. Start it: click Start on the flow and say what it should do.

More development templates

Every flow template
Download MorphyShare a flow of your own