creating-projects

A new project is judged by everything except its code: the toolchain, CI, release and docs must work from the first commit, while the code itself stays a placeholder until the user asks for logic.

Read guide.md before writing any file. It explains how to read the request, what you may change in a template and why, how to write the docs, and what to do when no template fits.

Required initialization gate

For a completely new project, finish the managed project initialization before writing any scaffold or project files:

1. Load the $global-projects skill and use its paired resolver to find the configured project root and project CLI.
2. Resolve the repository owner and name. If either is missing or ambiguous, ask the user before creating the project directory.
3. Resolve whether the repository should be public or private. If the user did not specify visibility, ask before continuing. "Private" only sets the GitHub repository visibility, never private: true in a package.
4. Resolve a one-sentence description of what the project does. If the request doesn't say, ask instead of describing the scaffold.
5. Run the selected CLI's init command with the explicit visibility option from <root>/<owner>/<repo>.
6. Verify the local path and origin remote, then create the scaffold inside that initialized repository (see Templates).

An explicit request to create or initialize a new project authorizes the managed initialization. Once the owner, name, visibility, and description are known, do not ask for a second confirmation before running moi init --public, moi init --private, or the paired mo command.

Do not create the project anywhere else (the current task directory, work/, outputs/), and do not use plain git init instead of the managed init. If a required choice is missing, ask for it instead of skipping the initialization.