---
name: deploy-browser-app
description: Guide a student through GitHub onboarding and publish an evaluated browser app to its own GitHub Pages repository, then verify the exact deployed revision. Use for first publication or updates.
---

# Publish the evaluated app

Read the [shared workflow](../../references/workflow.md), plan, setup, evaluation, and any deployment record. Inspect current source and Git history. Resolve failed required checks; missing account access need not prevent preparing the public files.

1. **Prepare the destination.** Establish the student's GitHub account, repository name, and public visibility. Explain that source and pushed history will be public. Use browser tools to guide registration, sign-in, and settings; students handle passwords, verification, and required agreements. If browser support is unavailable, state the missing capability and the exact step needed. Use authorized Git/GitHub tools for repository operations; reuse authentication. Install GitHub CLI only if needed for the chosen route. Never ask for tokens/passwords in chat or store them in project files.
2. **Prepare the public result.** Inspect current files and full history, including author attribution, deleted files, and evidence. Require public/synthetic material only. If history contains sensitive material, stop publication and explain remediation; do not push or rewrite history automatically. Exclude reports, tests, local imports, and repository metadata from the website. Add a real source-repository link to the app and README using the agreed URL. For educational examples also verify the compact “How this was built” route to sanitized request, plan, recipe choices and evaluation; keep full records in the source repository, not the publication bundle.
3. **Prepare Pages.** For a plain app copy the [workflow template](../../assets/pages.yml); for a managed app follow [managed build](../../references/managed-build.md) and copy the [managed workflow](../../assets/pages-managed.yml) to `.github/workflows/pages.yml`, preserving any existing workflow until its differences are understood. Verify the official Action releases if updating the template. This targets GitHub.com; do not silently apply it to another hosting service. The plain workflow copies app/ to dist/; the managed workflow uses locked npm dependencies and the tested Node version to build dist/. Both upload only dist/. Set the managed Vite base to the repository prefix and test that production path before final evaluation. Keep generated output ignored. For a new repo, create it empty rather than generating a conflicting README. Use `main`; if an existing project uses another branch, resolve that explicitly without force-pushing or discarding history.
4. **Refresh evaluation.** Include the workflow and source link in the final source checkpoint. Run [Evaluate](../evaluate-browser-app/SKILL.md) for affected checks. Apply the exact [freshness checks](../../references/evaluation-freshness.md), including untracked source, extra tooling, and substantive changes to the evaluated plan. Static workflow checks do not establish numerical correctness. Do not label evaluation complete if browser tests were unavailable.
5. **Publish.** Inspect the concrete result before any final approval still required, reusing authorization already provided. Confirm the intended Git root, remote, branch, and staged files. After any required approval, create the authorized empty repository if missing, set Settings → Pages → Source to GitHub Actions, then push. For an existing repository verify that setting before pushing. Create/push only the authorized repository; do not overwrite an existing remote or force-push. A protected branch or denied permission needs resolution, not a workaround. Wait for the Pages deployment of the actual pushed commit; a queued run or successful push is not success.
6. **Verify live.** Open the live URL from the completed deployment. Check assets under the repository path, the main interaction, one independently known calculation, and the source link. Record URL, source URL, evaluated and deployed commits, workflow result, live observations, and remaining limitations in `DEPLOYMENT.md`. Verify an ordinary update in a returning browser: imported Vite assets have content-based names, while changed verbatim public/ assets need explicit versioning. Add ordinary update instructions: revise, evaluate affected behavior, check freshness, commit, push, and verify the new deployment.

On retry, inspect existing repository and workflow state before creating anything. Never create duplicate repos after an ambiguous result. An update is an ordinary commit and deployment, not a history rewrite. Do not claim live publication if authentication, authorization, workflow completion, or live verification remains unresolved.