Publish Project to GitHub

Turn a finished local project into a clean public artifact. Treat repository creation, public visibility, and deployment as separate gates; a successful push is not proof that the public site works.

Deliverables

Produce the applicable items:

• a narrowly scoped Git repository
• an intentional public or private GitHub repository
• a project-specific README.md
• a real preview image when the project is visual
• a portable build or remix prompt when it adds value
• a configured GitHub Pages site for compatible web projects
• post-push and post-deploy read-back

1. Resolve scope and authority

Inspect the local project, repository state, remotes, and local instructions before writing.

Confirm or safely infer:

• the exact project directory and intended files
• repository name and owner
• whether the target should be public or private
• whether an existing repository must be updated or a new one created
• whether the user wants a live website, source hosting only, or both

Creating a public repository is authorized only when the user explicitly asks for public sharing, a public URL, open source, or equivalent. Otherwise ask for visibility before creating it.

Never force-push, overwrite an existing remote, change repository visibility, or replace an existing Pages configuration without exact authorization.

2. Audit before packaging

Run the bundled audit from the project root:

bash /path/to/publish-project-to-github/scripts/audit_public_project.sh .

Then inspect findings rather than treating the script as a substitute for judgment.

Block publication on:

• API keys, tokens, private keys, passwords, or .env files
• personal data or private client information
• absolute local filesystem paths required at runtime
• unlicensed or private assets
• missing runtime files
• unclear ownership of a repository name that already exists