myrepo — publish a project to GitHub with a live page

Turn a local project into its own public GitHub repository with a browser-runnable Pages site, conforming to the 42.uk theme and spec.

Hard constraints

• Publishing is outward-facing and requires the user's explicit go-ahead. Before creating or pushing anything public, confirm with the user in chat: the exact repo name, public vs. private, and what will be pushed. A --dry-run preview is the safe way to show them first.
• Never leak the local machine. The publisher runs a privacy scan and refuses if it finds home/workspace paths (e.g. C:\Users\..., /home/...). Do not pass --allow-paths to silence it unless the user confirms those strings are intentional and safe.
• Never publish secrets. Do not publish a directory containing credentials, tokens, .env files, or private keys. Check before running.
• Verify, don't assume. The publisher polls the live Pages URL until it returns 200. Report the verified URL; if it did not go green, say so (Pages builds can lag a few minutes) rather than claiming it is live.
• OAuth only. Authentication is the user's existing gh login. Never request, embed, or suggest a Personal Access Token in code or committed files.

Verify it offline

Before diagnosing GitHub setup, prove that myrepo 1.3.1's local safety gates work:

node scripts/publish.mjs --self-test

This deterministic self-test uses temporary fixtures to exercise the clean-project, secret-file, inline-credential, private-key, and local-user-path cases. It makes zero network calls, runs no external commands, and does not require gh or a signed-in account.

Treat publisher health and GitHub readiness as separate signals:

• The --self-test result proves whether myrepo's privacy and secret gates work.
• gh --version proves whether the GitHub CLI is installed (gh_cli).
• gh auth status proves whether that CLI has a usable account session (gh_auth). Run it only when gh_cli is ready.

A missing CLI or signed-out account does not mean the safety gates failed. Report it as dependency setup still needed. Actual previewing or publishing requires both gh_cli and gh_auth to be ready.

Run it

1. Confirm the project has a web entry point if it should run in a browser: an index.html at the directory root. If there is none, the Pages site gets a themed landing page instead of a runnable app — tell the user which they are getting.

2. Preview first (creates nothing):

   node scripts/publish.mjs --name <repo> --desc "<one-line description>" --dry-run

3. After the user confirms, publish for real:

   node scripts/publish.mjs --name <repo> --desc "<one-line description>" --title "<Human Title>"

   This scaffolds README.md, LICENSE, and .nojekyll (keeping any existing README unless --force-docs), commits, creates ‹login›/‹repo› (public by default; --private disables Pages), pushes, enables Pages, and verifies the live URL.

4. Relay the two links the publisher reports to the user: the repository and the live in-browser page. Both also appear in the JSON on stdout (repo, pages_url).

Conforming docs and theme

Scaffolded docs carry the 42.uk identity: the ◆ mark, the project title and description, a live page link, a run-in-browser note, the MIT license, the "part of the 42.uk universe" line, and the tagline RELAX. IT'S ALREADY OVER. An app's own index.html is the page; a doc-only repo gets a themed landing index.html so it still has something to serve. Match new visual assets to the terminal palette (bg #080a0a, accent #00ff99, text #e6ffe6, monospace) so every 42.uk repo reads as one family.

Options

--dir <path> project dir · --private (no Pages) · --no-pages · --force-docs overwrite README/LICENSE · --allow-paths skip the local-path privacy refusal (confirm first; secret checks remain mandatory). Entries git ignores (.ensemble_reviews/, model caches, .env) are skipped by the scan because they can never be pushed; everything git would publish is scanned · --dry-run · --self-test (offline safety gates) · --version.

Every publish is recorded to an owner-only local log at ~/.myrepo/publishes.jsonl (which myrepo version pushed what, where, and what the scan found) — your debuggable audit trail. Each run confesses its version and checks for updates (fail-silent, cached daily; disable with NO_UPDATE_CHECK=1).

Companion skills: momm (review the code before you ship it) and myvoice (add a consented local voice). A good flow is momm → fix → myrepo.