When you are creating a project, you should make it usable and maintainable, you need to make infrastructure tools, release and validation system work perfectly.
When creating projects, what you should focus on is not the project code, but everything except project code.
You can create a small placeholder like
macro and
. You can fill the code later if I required. If I don't require you implement any logic, just keep placeholders.
Required initialization gate
For a completely new project, finish the managed project initialization before writing any scaffold or project files:
- Load the skill and use its paired resolver to find the configured project root and project CLI.
- Resolve the repository owner and name. If either is missing or ambiguous, ask the user before creating the project directory.
- Resolve whether the repository should be public or private. If the user did not specify visibility, ask before continuing.
- Run the selected CLI's command with the explicit visibility option from .
- Verify the local path and 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, and visibility are known, do not ask for a second confirmation before running
,
, or the paired
command.
Do not create the project in the current task directory,
,
, or another artifact directory unless the user explicitly chose that location. Generic artifact-output guidance does not override the managed project workflow.
Do not use plain
as a substitute for
or
. Do not silently skip managed initialization because a required choice is missing; ask the user for that choice instead.
Templates
Templates live in
next to this file. Load
to pick the stack, then scaffold with the script next to this file:
bash
scripts/scaffold.sh <stack> <root>/<owner>/<repo> <owner> <repo> "<description>"
| Stack | Layers | Use for |
|---|
| + | Rust crates and CLIs |
| + + | npm libraries |
| + + | Node.js command line tools |
Websites and napi-rs projects have no template yet. Build them by hand, still following
and the aspects below.
The script copies the layers in order, renames
paths to
and
paths to the repo name, fills the mechanical placeholders, and runs each layer's
to add dependencies with their latest versions. Never copy pinned dependency versions from other projects into a new one.
After scaffolding:
- Write every placeholder the script prints, mostly in . Delete a section instead of leaving it empty. Keep a new project's short (around 40 lines), it should only hold non-obvious rules and gotchas.
- Adjust the scaffold to the project: the package name (for example a scoped npm name), extra crates or packages, CLI binaries, and the CI matrix.
- Run the stack's checks before finishing: for Rust,
vp run check && vp run build && vp run test
If a template itself is wrong or outdated, fix it in the
repository instead of only patching the generated project.
Related skills
When you are initializing a project, like handling infrastructure and related data, you are supposed to load
skills. You can also use
to find how my other projects use CI and tools. Load
for details of the
preset in JavaScript projects.
Aspects of a project
When you are initializing a project, you should care about these aspect:
- Project layout (single-package, or a workspace, one language or multiple-languages mixed)
- Basic toolchain (Do not only care about build, care about linting, formatting, testing, git hooks, staging)
- Package Release (Skip for website, how to trigger, maintenance comment in response, GitHub compatible)
- CI checking (Add CI checks, including test, build, snap tests, e2e tests, codestyle, linting, formatting)
- Document placeholder (MIT License or other license as required, basically README.md)
- Editor settings ( folder, format and lint)
- Scripts (For manually validation, and installing the developing products onto the using computer)
- Deploy (Websites)
- Tools version (Node version, Rust version)
- GitHub repo description, PR merge setting (Squash, Description as message, Auto delete branch)
- AGENTS.md document
You should prepare them in detail but should not make them too complex, for example, linting CI shouldn't be run on all macOS, Linux and Windows, a small library also doesn't need a VitePress website for docs,
shouldn't be provided most of the time.