Browse Project in Browser Before You Send a Clone Link

A teammate asks what you meant in the design doc. A client wants to see progress. A reviewer needs to check one decision before a meeting. The reflex is to send them the repository and tell them to set up the toolchain — and then spend twenty minutes on Node versions and missing environment variables before anyone reads a line.

Most of the time they do not need a working copy. They need to look. Being able to browse a project in the browser — files, instructions, memory, and the sessions you kept — turns a half-day of setup into a link someone opens on a phone between meetings.

This article is about the other handoff path. You will get a way to decide when a link is enough and when someone genuinely needs a clone, what to prepare before you send the link, and how to move from read-only viewing to a real local copy when the work starts.

Why cloning is not always the first step

Cloning is the default advice because it is the only thing version control was built to do well. But a clone is a commitment. It asks the other person to have the runtime installed, to have credentials, to have disk space, and — most of all — to have decided that this project is now their problem.

Think about who actually asks you for access in a given month:

• A teammate who owns a different service and needs to know how yours handles retries.
• A designer checking whether the copy in the UI matches what was agreed.
• A contractor deciding whether to take the job, before any contract exists.
• Your future self, on a tablet, trying to remember why the cache layer is written that way.
• A new hire in week one, reading before writing.

Exactly one of these people will run the code this week. The rest want to read. When you hand all five of them a clone command, four of them either do nothing or spend an hour on setup that produces no value.

There is a second cost that is easy to miss. A clone is a copy that drifts. The moment someone pulls the project onto their laptop, they have a snapshot that ages, and every question they ask you afterwards is about a version you may have moved past. A link always points at the current state, or at a specific version you chose deliberately.

What you see when you browse a project in the browser

A browser view is only useful if it shows the things that answer questions. Source files alone rarely do. The four layers that matter, and what each one settles:

Files. The obvious layer. Someone reads the module they were asked about, in context, with the neighbouring files one click away. No checkout, no editor.

Project instructions. CLAUDE.md, AGENTS.md, or whatever rules file you keep. This is the fastest possible answer to "how do you work in this repo?" — test commands, naming conventions, the directories that are off limits. A reader who skims this file before asking a question usually does not need to ask it. If your instructions file is thin, writing project instructions your assistant follows is the place to start.

Project memory. Decisions, notes, open questions. This is the layer that makes a read-only link genuinely useful instead of merely convenient. Code shows what happens; memory shows why that and not the obvious alternative. A reviewer who can open a decision note answers half their own questions before they reach you.

Sessions. The AI coding conversations you chose to keep. More on these below.

A useful mental model: the files answer what, the instructions answer how, the memory answers why, and the sessions answer how did we get here. A link that only exposes the first layer sends people back to you for the other three. The piece on what belongs beside your code goes deeper on choosing what travels with a project.

One more thing a browser view gives you that a fresh clone does not: history you can read without commands. Versions listed in order, with the changes each one brought and a line diff between any two. "What changed since I last looked?" becomes a click rather than a git log incantation someone has to remember.

Reading a saved session without opening a tool

Saved sessions are the layer people underuse, because opening one usually means finding the right tool, the right machine, and the right project directory.

In a browser they are just text you can read like anything else. That matters in three recurring situations.

The "why is it done this way" question. You wrote a decision note, and it says Chose polling over websockets; the proxy drops idle connections. Good note. But the teammate wants the detail — did you test it, at what interval, what broke? The session where you worked it out has all of that. The note gives the conclusion; the session gives the evidence. Link one to the other and the reader chooses their own depth.

Onboarding. A new contributor reading two or three well-chosen sessions learns more about how the project actually gets built than from any document you could write on purpose. They see the dead ends. They see what you asked the assistant to stop doing. Onboarding a new contributor with project context covers how to sequence that reading.

Your own recall. Six weeks later you do not need to re-run the session. You need to find the paragraph where you decided the thing.

The catch is that a session is only readable if you picked it deliberately. A transcript of you fixing a typo for forty turns helps nobody. Keep the ones where a real alternative was weighed, a non-obvious bug was traced, or a piece of architecture was designed — the criteria in which AI coding sessions are worth keeping apply just as much to reading as to saving.

And one caution before you share: sessions are the layer most likely to contain something you would not paste into a public channel. Pasted config, a staging URL, a customer name mentioned in passing. Read what you kept before you send the link — sharing AI coding context without leaking secrets has the full checklist.

When a link is enough, and when someone needs a real clone

The question is not how senior the person is. It is whether they are going to change something or run something.

That last row is worth pausing on. If the point is for someone else's AI assistant to work with the project, a link does not do it — the assistant needs the instructions, memory and files on disk where it can read them. That is a clone, every time.

A practical rule: start everyone with a link. Escalate to a clone the moment the person says "I'll take a look at fixing that." The escalation is cheap; the premature setup is not.

Sharing outside your team: a client, a reviewer, a future hire

Outside your team, a read-only link does something a clone cannot: it keeps the boundary obvious. Nobody has to trust a promise about what the other side will do with the copy, because there is no copy yet.

Three patterns worth having ready.

The client update. Rather than writing a status email that paraphrases the work, point at the version list. The changes are there, the diffs are there, and the decision notes explain the trade-offs in your own words rather than in a summary you rewrite every Friday. Write the memory entries as if a non-author will read them, because one will.

The external reviewer. A security reviewer or an architect brought in for two days does not want your build. They want the instructions file, the decision records, and the three modules that matter. Send those, with a short note naming where to start. Reviewer time spent on npm install is reviewer time you paid for and did not get.

The candidate or future contributor. Before anyone signs anything, they can see what the project actually looks like: the state of the code, the standards, the reasoning. This is the fairest possible preview, and it costs you a link.

In all three, prepare before you send. Open the project the way they will see it. Read the memory entries and the sessions with an outsider's eyes. Remove or rewrite anything that was fine as a private note and is not fine as a shared one — an unflattering remark about a vendor, an internal hostname, a half-finished thought that reads as a commitment. Five minutes of review, once.

Moving from browser view to a working clone

At some point reading turns into doing. Make that transition one step, not a project of its own.

What the person needs at that moment: the files, the instructions their assistant will read, and the memory that stops them from re-litigating decisions. If they get the files alone, they start from zero context and their first session re-suggests the approach you rejected in March.

Three things make the handover clean:

1. Give access at the right level. Reader for people who will keep reading, writer for people who will push. Start narrow; widen when someone asks.
2. Name the entry point. One sentence — "read the instructions file, then the three decision notes from August, then sync/" — saves more time than any tooling.
3. Make sure the context comes with the code. A clone that arrives without instructions and memory is a downgrade from the browser view they just had.

Once the project is local, the usual advice about continuing work applies, including continuing on another machine without losing context.

How PrjLab handles this

We built PrjLab so that the browser view and the clone are the same project, not two representations you have to keep in sync.

• A repository holds your files plus three kinds of context — .prjcontext/instructions/, .prjcontext/memory/ and .prjcontext/sessions/ — and all of it is readable in the browser, including saved sessions.
• Every prj push creates an immutable version you can open in the browser, with a list of changes and a line diff between versions. A repository or a single version can be downloaded as a .zip.
• Repositories are private by default. You share by handle as a reader (view and clone) or a writer (also push), and removing someone takes effect immediately.
• A repository can be made public, readable and clonable by anyone at prjlab.com/handle/name and listed on Explore — including its memory and sessions, so review them first.
• When reading turns into working, prj clone brings the whole picture down to a machine: files, instructions, memory and sessions together.
• Files are encrypted at rest and served only to current members, and hosting is in the EU. PrjLab can read private content to render previews and serve clones, so this is not end-to-end encryption — treat it accordingly for anything sensitive.

Frequently asked questions

Does the person I share with need an account to browse the project? For a private repository, yes — you share by handle with a specific person, and access can be removed at any time. A public repository can be read and cloned by anyone at its URL.

Can someone reading in the browser change anything? Not unless you gave them writer access. Readers can view and clone; writers can also push. If you are unsure, share as a reader and widen later.

Is PrjLab replacing git in this workflow? No. PrjLab sits beside git. Git keeps your commit history; PrjLab keeps the project together with the instructions, memory and sessions that git was never meant to hold.

What if I only want to share one version, not the current state? Each push creates a version you can open on its own, and any repository or version can be downloaded as a .zip if the other person prefers a file.

If you want to see what a shareable project looks like end to end, start with the getting-started guide or the walkthrough on pushing your first project with its context.