The review flow

Hi Vy. Here is where your work goes.

You will never touch a server. You build a page, you publish it to your playground, YT reads it and marks it up on the page itself, and YT ships it. This walks you through the three places your work can live, the one tool you will learn, and a short check at the end.

The three places

Every page you make lives in one of three places. Only the first one is yours to publish to.

Yours

The playground

rme-review.vercel.app

A private space on Vercel. You publish drafts here yourself, as many as you like, all hidden from Google. Every quiz, calculator, and page starts its life here for review.

You publish here
YT only

Staging

preview.reviewmyemails.com

A private copy of the real site, so YT can see a page exactly as it will look once it is live. It runs on our own server, which you cannot reach.

Only YT publishes here
YT only

Live

reviewmyemails.com

The real website the whole world sees. Putting a page here is the last step, and it is always YT's hand on the button.

Only YT publishes here

Why the playground is yours

Staging and live both run on our own server, and you do not have a key to it. That is on purpose, not a slight. The playground on Vercel needs no key. You publish to it straight from your work, it costs nothing, and every page is hidden from search.

So the playground is where you make and test things. YT carries the approved page across to the real site. You focus on the making, she handles the shipping.

The one tool you will learn: Hypothesis

Hypothesis is a comment layer that sits on top of a live page. Instead of describing a change in Slack, like "make the third line shorter", YT highlights the exact words on the page and leaves a note right there. You open the same page, see her note beside the line she means, and fix it. No guessing which line.

Everyone reviewing works in one shared group, so you both see the same notes and the same replies on the page. That is the point: a reply you leave is a reply YT sees, right under her comment, not something lost in a separate view. You join the group once, from an invite link YT sends you, and stay logged in to Hypothesis while you review.

  1. Open the playground page. The Hypothesis panel sits on the right edge of the screen.
  2. YT selects any text and writes a note. It pins to that exact spot on the page.
  3. You see every note in place, and you reply to each one (more on that below), then revise the page.

Reply to every comment, so nothing is left on read

The shared group only helps if the replies come back. So the rule is simple: every comment YT leaves gets a visible reply from you, so she always knows where each one stands. Two kinds of reply, and both take seconds.

  1. You handled it? Reply with a short done mark. Something like "Resolved, shortened that line" or just "Done". Now she can see at a glance the note is closed, without opening the page to check.
  2. It needs a chat, or you are keeping it as is? Reply for real. Answer the point, or say why it is staying, right there under her note. A comment left with no reply looks ignored, even when you did think about it.

Hypothesis has no "resolved" button, so the reply is the signal. This is what saves the back-and-forth in Slack: YT reads your reply under her own comment and knows it is either done or being talked about. Nothing sits unanswered.

💬

One comment, one reply

Before you say a review round is done, every comment on the page has a reply under it. A done mark when you fixed it, a real answer when it needs discussion or is staying. Never leave one on read.


The flow, start to finish

  1. You build the page.
  2. You publish it to the playground on Vercel, hidden from Google, with Hypothesis switched on.
  3. You share the link so YT knows it is ready to look at.
  4. YT reads the real page and leaves notes on the lines with Hypothesis.
  5. You revise and republish to the playground. Repeat until she is happy with it.
  6. YT copies the approved page into the right place and ships it to staging, then live.
  7. You never push to staging or live. That step stays with YT, every time.
🔒

The one hard rule

Only YT publishes to reviewmyemails.com. Not you, not anyone else. If a page is going live, it goes through her.

Before you build: claim the ticket

One ticket, one owner at a time. The claim comes before the work, not after it.

Here is why this rule is here. One night, two of us built the very same holiday banners at the same time, neither knowing the other was on them. Both of us finished. One finished set went straight in the bin. Hours of good work gone, only because nobody knew it was already taken.

A claim is what stops that. The moment a ticket says doing with a name against it, everyone else can see it is spoken for and leaves it alone.

  1. The ticket is claimed before you build. When you pick it up, its row on the Ops Board moves to doing with your name and your branch, first, before any work. You do not edit the board yourself, the Tickets chat is the one that writes it, so you tell it you are starting and it registers the claim.
  2. Your runner watches for a clash. Every sweep, about every fifteen minutes, it checks who is working on what against the tickets already marked doing. If a second session looks like it is starting on a ticket that is already claimed, it flags that to you and in Slack, before the double work happens.
  3. A flag is a nudge, not a wall. The runner points it out, it does not stop you, because one big ticket can be split into smaller pills that share an ID on purpose. When the clash is really just that, you carry on. When it is a real collision, one of you steps off before either has built the wrong thing.
🚩

Claim first, build second

Before you start a ticket, check that its row says doing with your name on it. If it is already claimed by someone else, do not build it alongside them, check with them first.

The same discipline closes the loop at the other end. When your ticket's PR is merged and the work is done, your runner nudges this chat to wrap up, capture anything worth keeping, hand the board update to the Tickets chat, then archive the chat so a finished task never lingers open. Claim it to start, archive it to finish.

Quick check

Seven questions. Tap an answer to see if it is right and why. Nothing is saved, this is just for you.