Back to Details

creating-projects

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
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 
todo!()
macro and 
console.error()
. You can fill the code later if I required. If I don't require you implement any logic, just keep placeholders.
创建项目时，应确保项目可用且易于维护，并需要让基础设施工具、发布流程和验证系统完美运行。
创建项目时，重点不在项目代码本身，而在项目代码之外的所有事项。
可以创建类似 
todo!()
宏和 
console.error()
这样的简单占位实现。如果我后续要求，再补全代码。如果我未要求实现任何逻辑，就只保留占位内容。

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.
  4. Run the selected CLI's 
    init
    command with the explicit visibility option from 
    <root>/<owner>/<repo>
    .
  5. 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, and visibility 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 in the current task directory, 
work/
, 
outputs/
, 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 
git init
as a substitute for 
moi init
or 
mo init
. Do not silently skip managed initialization because a required choice is missing; ask the user for that choice instead.
对于全新的项目，在编写任何脚手架或项目文件之前，必须完成托管项目初始化：
  1. 加载 
    $global-projects
    skill，并使用其配套解析器查找已配置的项目根目录和项目 CLI。
  2. 解析仓库所有者和名称。如果其中任一项缺失或不明确，请在创建项目目录之前询问用户。
  3. 确定仓库应为公开还是私有。如果用户未指定可见性，请先询问用户再继续。
  4. 从 
    <root>/<owner>/<repo>
    运行所选 CLI 的 
    init
    命令，并明确指定可见性选项。
  5. 验证本地路径和 
    origin
    remote，然后在已初始化的仓库中创建脚手架（参见模板）。
明确要求创建或初始化新项目，即表示授权执行托管初始化。一旦所有者、名称和可见性均已确定，在运行 
moi init --public
、
moi init --private
或配套的 
mo
命令之前，不要再次请求确认。
除非用户明确选择了该位置，否则不要在当前任务目录、
work/
、
outputs/
或其他产物目录中创建项目。通用的产物输出指导不能覆盖托管项目工作流。
不要使用普通的 
git init
代替 
moi init
或 
mo init
。不要因为缺少必要选项而擅自跳过托管初始化；应向用户询问该选项。

Templates

模板

Templates live in 
templates/
next to this file. Load 
$choosing-tools
to pick the stack, then scaffold with the script next to this file:
bash
scripts/scaffold.sh <stack> <root>/<owner>/<repo> <owner> <repo> "<description>"
StackLayersUse for
rust
common
+ 
rust
Rust crates and CLIs
js-lib
common
+ 
js
+ 
js-lib
npm libraries
js-cli
common
+ 
js
+ 
js-cli
Node.js command line tools
Websites and napi-rs projects have no template yet. Build them by hand, still following 
common
and the aspects below.
The script copies the layers in order, renames 
_name
paths to 
.name
and 
__repo__
paths to the repo name, fills the mechanical placeholders, and runs each layer's 
setup.sh
to add dependencies with their latest versions. Never copy pinned dependency versions from other projects into a new one.
After scaffolding:
  1. Write every 
    {{TODO: ...}}
    placeholder the script prints, mostly in 
    AGENTS.md
    . Delete a section instead of leaving it empty. Keep a new project's 
    AGENTS.md
    short (around 40 lines), it should only hold non-obvious rules and gotchas.
  2. 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.
  3. Run the stack's checks before finishing: 
    just ready
    for Rust, 
    vp run check && vp run build && vp run test
    for JavaScript.
If a template itself is wrong or outdated, fix it in the 
liangmiQwQ/new
repository instead of only patching the generated project.
模板位于本文件旁的 
templates/
中。加载 
$choosing-tools
以选择技术栈，然后使用本文件旁的脚本生成脚手架：
bash
scripts/scaffold.sh <stack> <root>/<owner>/<repo> <owner> <repo> "<description>"
技术栈层级适用场景
rust
common
+ 
rust
Rust crates 和 CLI
js-lib
common
+ 
js
+ 
js-lib
npm 库
js-cli
common
+ 
js
+ 
js-cli
Node.js 命令行工具
网站和 napi-rs 项目目前尚无模板。需要手动构建，但仍应遵循 
common
层及下述各方面要求。
该脚本会按顺序复制各层，将 
_name
路径重命名为 
.name
，将 
__repo__
路径重命名为仓库名称，填充机械性占位符，并运行各层的 
setup.sh
以添加采用最新版本的依赖。绝不要将其他项目中固定版本的依赖复制到新项目中。
生成脚手架后：
  1. 填写脚本输出的每个 
    {{TODO: ...}}
    占位符，这些内容大多位于 
    AGENTS.md
    中。如果不需要某个章节，应直接删除，而不是留下空章节。新项目的 
    AGENTS.md
    应保持简短（约 40 行），只记录不易理解的规则和易踩坑之处。
  2. 根据项目调整脚手架：软件包名称（例如带 scope 的 npm 名称）、额外的 crates 或 packages、CLI binaries 以及 CI matrix。
  3. 完成前运行相应技术栈的检查：Rust 使用 
    just ready
    ，JavaScript 使用 
    vp run check && vp run build && vp run test
    。
如果模板本身有误或已过时，应在 
liangmiQwQ/new
仓库中修复，而不应只修补生成的项目。

Related skills

相关 skill

When you are initializing a project, like handling infrastructure and related data, you are supposed to load 
$choosing-tools
skills. You can also use 
$global-projects
to find how my other projects use CI and tools. Load 
$use-vp-config
for details of the 
@liangmi/vp-config
preset in JavaScript projects.
初始化项目时，包括处理基础设施和相关数据，应加载 
$choosing-tools
skill。也可以使用 
$global-projects
了解我的其他项目如何使用 CI 和工具。对于 JavaScript 项目中 
@liangmi/vp-config
预设的详细信息，请加载 
$use-vp-config
。

Aspects of a project

项目的各个方面

When you are initializing a project, you should care about these aspect:
  1. Project layout (single-package, or a workspace, one language or multiple-languages mixed)
  2. Basic toolchain (Do not only care about build, care about linting, formatting, testing, git hooks, staging)
  3. Package Release (Skip for website, how to trigger, maintenance comment in response, GitHub compatible)
  4. CI checking (Add CI checks, including test, build, snap tests, e2e tests, codestyle, linting, formatting)
  5. Document placeholder (MIT License or other license as required, basically README.md)
  6. Editor settings (
    .vscode
    folder, format and lint)
  7. Scripts (For manually validation, and installing the developing products onto the using computer)
  8. Deploy (Websites)
  9. Tools version (Node version, Rust version)
  10. GitHub repo description, PR merge setting (Squash, Description as message, Auto delete branch)
  11. 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, 
.editorconfig
shouldn't be provided most of the time.
初始化项目时，应关注以下方面：
  1. 项目布局（单包或 workspace、单一语言或多语言混合）
  2. 基础工具链（不要只关注构建，还要关注 linting、格式化、测试、git hooks、staging）
  3. 软件包发布（网站可跳过；如何触发、响应中的维护说明、兼容 GitHub）
  4. CI 检查（添加 CI 检查，包括 test、build、snap tests、e2e tests、codestyle、linting、formatting）
  5. 文档占位内容（按要求提供 MIT License 或其他许可证，基本要求是 README.md）
  6. 编辑器设置（
    .vscode
    文件夹、format 和 lint）
  7. 脚本（用于手动验证，以及将开发中的产品安装到使用者的计算机上）
  8. 部署（网站）
  9. 工具版本（Node 版本、Rust 版本）
  10. GitHub 仓库描述、PR 合并设置（Squash、Description as message、Auto delete branch）
  11. AGENTS.md 文档
应详细准备这些内容，但不要做得过于复杂。例如，不应在所有 macOS、Linux 和 Windows 环境中运行 linting CI；小型库也不需要为文档搭建 VitePress 网站；多数情况下无需提供 
.editorconfig
。