Try a pull request on the demo site

A good PR description and screenshots show what changed. Clicking through it yourself shows how it feels: the empty states, the odd input, the screen next door. This skill gets the branch running on the demo site with data in it, then gets out of the way.

It never changes code, commits, pushes, or comments on the PR.

Scope

• IN: one PR or branch, started on the project's demo site, with a click-through list.
• OUT: reviewing the code (pr-review for an outside PR, reviewer for your own task); fixing what you find (quick-fix, or the plan's feature-build); a project with no demo site (say so, and point at project-init).

Argument

$ARGUMENTS is a PR number or URL, or a branch name. Empty means the current branch.

Workflow

1. Find the branch. For a PR, gh pr view <number> --json title,body,author,headRefName,baseRefName,files. Note whether the author is on the core team: an outside PR gets step 3 before anything builds.

2. Find or make a worktree for it. git worktree list shows whether the branch is already checked out somewhere.

   • In a linked worktree: use it as it is, with the demo data already in it.
   • Not checked out anywhere: make a worktree for it, named after the branch, and let the project's WorktreeCreate hook copy in what it copies (git-workflow owns that rule). For a PR from a fork, fetch it first (gh pr checkout <number> inside the new worktree). Remember you made it: step 7 removes it.
   • In the main checkout: the demo data there is the original, not a copy. Any migration on the branch, and anything clicked during the demo, changes it for every branch after. Ask before starting the site there, and offer a worktree with a copy instead.

3. For an outside PR, read what would run before building it. Do pr-review's step 2 scan (build scripts, package sources, postinstall entries, workflows, binaries) on the diff before dotnet build or npm install touch the branch. Flag anything it finds and wait for a yes.

4. Check the demo data belongs to this worktree. The site's database must live inside the worktree (such as SQLite under the site folder), as must its media. A connection string to a shared server means the demo writes to data other branches use: ask first. No demo data at all: the site's own install runs on first start, which is fine.

5. Start the site. Use the start command in CLAUDE.md's "Build & test", run in the background from the worktree. The port comes from git wdp-port, never a fixed one. Wait until the backoffice answers, then log in once to check it works. If the build or start fails, stop and report it: a demo that won't start is a finding about the PR.

6. Make sure the change has something to show. With a plan folder, start from the "Demo setup" notes in BUILD-LOG.md. Set up what a note names exactly as written (the same tags, values and settings) so the result it describes still holds; anything you add goes beside it, never into it. Otherwise read the diff for what it needs in the site: a document type using a new property editor, content for a new dashboard to list, a setting turned on. If the demo data doesn't have it, add what shows the change, through the backoffice or the Management API, in this worktree's copy only. List what you added.

   Make it look like a real site. Write what an editor of this site would really write: real-sounding titles, names and text that match the demo's existing content and languages; a mix of lengths, including one long enough to wrap; the characters real content has (an accent, an ampersand, quotes); an optional field left empty. Add enough of it to reach paging, sorting or an empty state when the change has one, and write out every item: never "add more until there are 12" for the user to finish. Never "Test 1", "foo" or lorem ipsum: placeholder data hides the layout and edge-case problems a click-through is meant to find.

7. Hand over. Give:

   • The backoffice address, with the worktree's port.
   • Where the login lives (the file or environment variable), not the password itself.
   • What you added in step 6.
   • The click-through list: each item a click path and what should happen ("Settings › Tag filters › add internal- as a prefix › the cloud on the home page drops the "internal-notes" tag"). Take it from the plan folder when the branch has one (SPEC.md, STORIES.md, and the click paths in BUILD-LOG.md), otherwise from the PR's description (its "Where to find it" or "How to verify", when pr-describe wrote it). Include the edge cases the spec or PR names, and the screens next to the change that it could have broken.

   When the user says they're done: stop the site. Remove a worktree this skill made, unless it has changes the user made in it; then ask. Leave a worktree that already existed.

Hand off

One line: the address, the branch, and whether the worktree was made for this demo. If another skill started this one, return that line and stop. That skill decides what runs next. Otherwise, if the user found a problem, offer the fix route that fits its size.