bootstrap

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Bootstrap

Collect project requirements through structured dialogue, generate foundational documentation, and scaffold the project structure — then hand off to downstream workflow skills.

通过结构化对话收集项目需求，生成基础文档并搭建项目结构，之后移交至下游工作流技能处理。

Parameters

参数

```
--scratch
```
: Start from nothing. Full scaffold: directories, configs, docs, README.
```
--existing
```
: Project already initialized (e.g.,
```
npm init
```
done, framework scaffolded). Enhance with docs and structure without overwriting existing files.

```
--scratch
```
：从零开始。完整搭建：目录、配置文件、文档、README。
```
--existing
```
：项目已完成初始化（如已执行
```
npm init
```
、框架已搭建）。在不覆盖现有文件的前提下，补充文档并完善结构。

Requirement Categories

需求分类

Collect information across these 8 dimensions. All categories except Techstack and Product definition are optional and may fall back to smart defaults.

#	Category	What to collect
1	Techstack	Language, framework, runtime, package manager
2	Product definition	Purpose, target users, core features, success criteria
3	Architecture	Component structure, data flow, API design, deployment target
4	Roadmap	Phases, milestones, MVP scope
5	Tooling	Linter, formatter, test framework, CI provider
6	Code standards	Naming conventions, file structure patterns, commit conventions
7	Design system	UI library, styling approach — frontend projects only
8	Auth & data	Auth method, database, ORM — if applicable

从以下8个维度收集信息。除**Techstack（技术栈）和Product definition（产品定义）**外，其余类别均为可选，可使用智能默认值。

序号	分类	收集内容
1	Techstack	编程语言、框架、运行时、包管理器
2	Product definition	项目用途、目标用户、核心功能、成功标准
3	Architecture	组件结构、数据流、API设计、部署目标
4	Roadmap	阶段划分、里程碑、MVP范围
5	Tooling	代码检查工具、格式化工具、测试框架、CI提供商
6	Code standards	命名规范、文件结构模式、提交规范
7	Design system	UI库、样式方案 — 仅针对前端项目
8	Auth & data	认证方式、数据库、ORM — 仅在适用时收集

Workflow

工作流

Step 1: Detect Project State

步骤1：检测项目状态

Check if a
```
package.json
```
,
```
pyproject.toml
```
,
```
Cargo.toml
```
, or similar manifest exists.
Check if a
```
docs/
```
directory and documentation files exist.
Determine mode:
- If the user passed
```
--scratch
```
  or nothing exists → proceed as
```
--scratch
```
  .
- If the user passed
```
--existing
```
  or a project manifest exists → proceed as
```
--existing
```
  .
Announce the detected mode and ask for confirmation before continuing.

检查是否存在
```
package.json
```
、
```
pyproject.toml
```
、
```
Cargo.toml
```
或类似的清单文件。
检查是否存在
```
docs/
```
目录及相关文档文件。
确定运行模式：
- 若用户传入
```
--scratch
```
  参数或无任何项目文件 → 以
```
--scratch
```
  模式运行。
- 若用户传入
```
--existing
```
  参数或已存在项目清单文件 → 以
```
--existing
```
  模式运行。
告知检测到的模式，并在继续前请求用户确认。

Step 2: Gather Requirements

步骤2：收集需求

Ask one question at a time. Use multiple-choice options (2–4 choices) when possible. Pause for full user input only when a question requires detailed explanation.

Sequence:

Techstack (required) — Ask about language/framework first. Offer common options based on context clues.
Product definition (required) — Ask: what does this project do, who uses it, what are the 2-3 core features?
Architecture — Ask: what are the main components, is there an API, where will it deploy?
Roadmap — Ask: what is the MVP scope, are there phases?
Tooling — Offer defaults from the Smart Defaults table; ask to confirm or override.
Code standards — Ask about naming conventions, file layout preferences, commit style (Conventional Commits?).
Design system — Skip for non-frontend projects. Ask about UI library and styling approach.
Auth & data — Skip if not applicable. Ask about authentication and database/ORM if the project has these concerns.

Rules for gathering:

If user says "I don't know", "default", or is vague → apply Smart Defaults for the detected stack and confirm.
Skip categories that are clearly irrelevant (e.g., Design system for a CLI tool, Auth & data for a static site).
Minimum required: Techstack + Product definition. All others can use defaults.

逐个提出问题。尽可能提供2-4个多选选项。仅当问题需要详细解释时，才等待用户完整输入。

顺序：

Techstack（必填）—— 首先询问编程语言/框架。根据上下文线索提供常见选项。
Product definition（必填）—— 询问：该项目的用途是什么？目标用户是谁？核心功能有哪2-3个？
Architecture —— 询问：主要组件有哪些？是否包含API？部署目标是什么？
Roadmap —— 询问：MVP范围是什么？是否有阶段划分？
Tooling —— 根据智能默认值表提供默认选项，询问用户是否确认或覆盖。
Code standards —— 询问命名规范、文件布局偏好、提交风格（是否使用Conventional Commits？）。
Design system —— 非前端项目跳过此步骤。询问UI库和样式方案。
Auth & data —— 不适用则跳过。若项目涉及相关需求，询问认证方式及数据库/ORM。

收集规则：

若用户回答“我不知道”、“默认”或表述模糊 → 针对检测到的技术栈应用智能默认值，并请求用户确认。
跳过明显不相关的分类（如CLI工具无需设计系统，静态站点无需认证与数据）。
最低必填项：Techstack + Product definition。其余均可使用默认值。

Step 3: Confirm Requirements Summary

步骤3：确认需求汇总

Present a concise summary of all collected requirements in a structured list. Ask for approval before proceeding:

```
Looks good
```
/
```
Confirmed
```
→ proceed to Step 4.
User provides corrections → update the relevant category and re-present the summary.

以结构化列表形式呈现所有收集到的需求的简洁汇总。在继续前请求用户批准：

若用户回复“看起来不错”/“已确认” → 进入步骤4。
若用户提出修改意见 → 更新对应分类内容并重新呈现汇总。

Step 4: Generate Documentation

步骤4：生成文档

Create the

docs/

directory if it doesn't exist. Generate all four foundational docs populated with concrete project-specific content — no placeholders.

File	Source categories
`docs/project-pdr.md`	Product definition, Roadmap
`docs/architecture.md`	Architecture, Techstack, Auth & data
`docs/codebase.md`	Generated from actual structure after Step 5
`docs/code-standard.md`	Techstack, Code standards, Tooling

Follow the same content requirements as the

docs --init

skill for each file.

For

--existing

mode: read existing docs first. Only add missing sections; do not overwrite content that is already accurate.

若

docs/

目录不存在则创建该目录。生成四份填充了具体项目内容的基础文档——无占位符。

文件	内容来源分类
`docs/project-pdr.md`	产品定义、路线图
`docs/architecture.md`	架构、技术栈、认证与数据
`docs/codebase.md`	步骤5完成后，根据实际生成的结构创建
`docs/code-standard.md`	技术栈、代码规范、工具链

每份文档需遵循与

docs --init

技能相同的内容要求。

对于

--existing

模式：先读取现有文档。仅补充缺失的章节；不得覆盖已有的准确内容。

Step 5: Scaffold Project Structure

步骤5：搭建项目结构

Create standard directories and essential config files based on the chosen techstack.

General rules:

Create
```
src/
```
,
```
tests/
```
(or framework equivalent),
```
public/
```
for web projects.

Create config files:

tsconfig.json

.eslintrc.json

.prettierrc

.gitignore

, etc.

Initialize git (
```
git init
```
) if not already a repository.
For
```
--existing
```
mode: only add missing files/directories. Never overwrite files that already exist.

Common scaffolds:

Next.js:

src/app/

src/components/

src/lib/

public/

tests/

React (Vite):

src/components/

src/hooks/

src/lib/

public/

tests/

Express/Node:

src/routes/

src/middleware/

src/lib/

tests/

Python:
```
src/<package>/
```
,
```
tests/
```
,
```
scripts/
```
CLI (Node):
```
src/commands/
```
,
```
src/lib/
```
,
```
tests/
```

After scaffolding, regenerate

docs/codebase.md

to reflect the actual directory structure.

根据所选技术栈创建标准目录和必要的配置文件。

通用规则：

创建
```
src/
```
、
```
tests/
```
（或框架对应目录），Web项目需创建
```
public/
```
。

创建配置文件：

tsconfig.json

、

.eslintrc.json

、

.prettierrc

、

.gitignore

等。

若尚未初始化仓库，则执行
```
git init
```
初始化git。
对于
```
--existing
```
模式：仅添加缺失的文件/目录。不得覆盖已存在的文件。

常见结构示例：

Next.js：

src/app/

、

src/components/

、

src/lib/

、

public/

、

tests/

React (Vite)：

src/components/

、

src/hooks/

、

src/lib/

、

public/

、

tests/

Express/Node：

src/routes/

、

src/middleware/

、

src/lib/

、

tests/

Python：
```
src/<package>/
```
、
```
tests/
```
、
```
scripts/
```
CLI (Node)：
```
src/commands/
```
、
```
src/lib/
```
、
```
tests/
```

搭建完成后，重新生成

docs/codebase.md

以反映实际的目录结构。

Step 6: Initialize Tooling

步骤6：初始化工具链

Install and configure selected tools:

Run package manager install:
```
npm install
```
,
```
pnpm install
```
,
```
pip install
```
, etc.
Install linter/formatter dev dependencies.
Write or update linter config (
```
.eslintrc.json
```
,
```
ruff.toml
```
, etc.).
Write or update formatter config (
```
.prettierrc
```
, etc.).
Add lint/format scripts to
```
package.json
```
(or equivalent).
If a test framework was selected, install it and create one example test file under
```
tests/
```
.

Skip any sub-step where the file already exists (

--existing

mode).

安装并配置所选工具：

执行包管理器安装命令：
```
npm install
```
、
```
pnpm install
```
、
```
pip install
```
等。
安装代码检查/格式化工具的开发依赖。
编写或更新代码检查工具配置（如
```
.eslintrc.json
```
、
```
ruff.toml
```
等）。
编写或更新格式化工具配置（如
```
.prettierrc
```
等）。
向
```
package.json
```
（或对应文件）添加lint/格式化脚本。
若已选择测试框架，则安装该框架并在
```
tests/
```
目录下创建一个示例测试文件。

对于

--existing

模式：跳过任何已存在对应文件的子步骤。

Step 7: Generate README

步骤7：生成README

Create

README.md

with:

Project name and one-sentence description
Tech stack badges or a concise stack list
Prerequisites
Quick start (install + run commands)
Documentation links section pointing to all 4 docs files
License (if specified)

For

--existing

mode: update README only if it is missing or significantly incomplete.

创建

README.md

，包含以下内容：

项目名称及一句话描述
技术栈徽章或简洁的技术栈列表
前置要求
快速开始（安装+运行命令）
文档链接部分，指向所有4份文档
许可证（若已指定）

对于

--existing

模式：仅当README缺失或内容严重不完整时才进行更新。

Step 8: Handoff

步骤8：移交

Summarize everything created:

List all new files/directories created
List all docs generated
List all tools configured

Then recommend the next skill based on project readiness:

If requirements are exploratory or architecture is uncertain → recommend
```
brainstorm
```
If the plan is clear → recommend
```
write-plan
```
to create the first implementation plan
If there's an immediate small task → recommend
```
quick-implement
```

汇总所有已创建的内容：

列出所有新建的文件/目录
列出所有生成的文档
列出所有已配置的工具

然后根据项目就绪状态推荐下一个技能：

若需求仍在探索阶段或架构不确定 → 推荐
```
brainstorm
```
技能
若计划已明确 → 推荐
```
write-plan
```
技能以创建首个实现计划
若有即时的小型任务 → 推荐
```
quick-implement
```
技能

Smart Defaults

智能默认值

Stack	Package Manager	Linter	Formatter	Test Framework	Styling
Next.js	pnpm	ESLint	Prettier	Vitest	Tailwind CSS
React (Vite)	pnpm	ESLint	Prettier	Vitest	Tailwind CSS
Express/Node	npm	ESLint	Prettier	Vitest	N/A
CLI tool (Node)	npm	ESLint	Prettier	Vitest	N/A
Python	uv	Ruff	Ruff	pytest	N/A
Rust	cargo	clippy	rustfmt	cargo test	N/A

技术栈	包管理器	代码检查工具	格式化工具	测试框架	样式方案
Next.js	pnpm	ESLint	Prettier	Vitest	Tailwind CSS
React (Vite)	pnpm	ESLint	Prettier	Vitest	Tailwind CSS
Express/Node	npm	ESLint	Prettier	Vitest	无
CLI tool (Node)	npm	ESLint	Prettier	Vitest	无
Python	uv	Ruff	Ruff	pytest	无
Rust	cargo	clippy	rustfmt	cargo test	无

Rules

规则

Never overwrite existing files in
```
--existing
```
mode unless the user explicitly approves.
Do not invent product requirements — always collect them from the user.
Skip irrelevant categories; don't ask questions that don't apply to the project type.
Generate documentation with concrete, project-specific content — no generic placeholders.
Keep
```
docs/codebase.md
```
in sync with the actual scaffolded structure.
If unsure about a decision, apply the smart default and confirm with the user.
Do not run destructive commands (e.g.,
```
rm -rf
```
) without explicit user approval.

在
```
--existing
```
模式下，除非用户明确批准，否则不得覆盖现有文件。
不得自行编造产品需求 — 必须从用户处收集。
跳过不相关的分类；不得询问与项目类型不符的问题。
生成的文档需包含具体的项目相关内容 — 不得使用通用占位符。
保持
```
docs/codebase.md
```
与实际搭建的结构同步。
若对某个决策不确定，应用智能默认值并请求用户确认。
未经用户明确批准，不得执行破坏性命令（如
```
rm -rf
```
）。