startup

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

startup

仓库Agent化初始化（startup）

Make a repo agent-ready in one move. Idempotent: safe on a brand-new empty directory or to retrofit an existing repo. Lean into running it when the user signals a new project; confirm first, then run.

一键将仓库配置为支持Agent的状态。具有幂等性：在全新空目录或改造现有仓库时都能安全运行。当用户表示要创建新项目时即可运行，先确认再执行。

What it does (meta layer: always, safe, idempotent)

功能说明（元层：始终安全、幂等）

Run the bundled script from the target repo root:

bash

bash <path-to-this-skill>/scripts/startup.sh "<repo-root>"

It ensures, without ever clobbering existing file contents:

```
git init
```
(if not already a repo)
```
AGENTS.md
```
(scaffolded from the stack template if missing)
```
CLAUDE.md
```
containing
```
@AGENTS.md
```
(so Claude auto-loads the instructions)
```
.gitignore
```
defaults
the Obsidian knowledge vault via the
```
docs-vault
```
skill (creates
```
docs/<repo>-vault/
```
and the read-first/write-after block in
```
AGENTS.md
```
)
an AFK board registry entry via the
```
afk-setup
```
skill. The default tracker is Linear (team
```
Engineering
```
); since the Linear project cannot be inferred, a fresh repo is not auto-registered. Finish it via
```
/afk-setup
```
(determine the project with the maintainer, reusing or creating one via the Linear MCP), or pass
```
--tracker github
```
for a GitHub board

从目标仓库根目录运行捆绑脚本：

bash

bash <path-to-this-skill>/scripts/startup.sh "<repo-root>"

它会确保以下内容，且绝不会覆盖现有文件内容：

```
git init
```
（若尚未是仓库）
```
AGENTS.md
```
（若缺失则从技术栈模板生成）
包含
```
@AGENTS.md
```
的
```
CLAUDE.md
```
（让Claude自动加载指令）
```
.gitignore
```
默认配置
通过
```
docs-vault
```
技能创建Obsidian知识库（生成
```
docs/<repo>-vault/
```
目录，并在AGENTS.md中添加“先读后写”区块）
通过
```
afk-setup
```
技能添加AFK看板注册表条目。默认跟踪工具为Linear（团队为
```
Engineering
```
）；由于无法推断Linear项目，新仓库不会自动注册。可通过
```
/afk-setup
```
完成注册（与维护者确定项目，通过Linear MCP复用或创建一个项目），或传递
```
--tracker github
```
使用GitHub看板

Default stack (pinned; edit HERE to pivot for all future repos)

默认技术栈（固定配置；如需调整所有未来仓库的技术栈，请在此处修改）

For JS/TS web apps. Override only when it does not make sense (e.g. a Python service, a static site):

Language: TypeScript (strict)
Runtime + package manager: Bun (always)
Framework: Next.js (App Router)
Database + Auth: Supabase (Postgres + Supabase Auth)
ORM / query: Drizzle + postgres-js
UI: Tailwind v4 + shadcn/ui
Lint + format: Biome (no Prettier)
Unit tests: Vitest
E2E / browser: Playwright
Deploy: Vercel (default); Fly.io for file/SQLite apps

适用于JS/TS Web应用。仅在不适用时才覆盖（例如Python服务、静态站点）：

语言：TypeScript（严格模式）
运行时与包管理器：Bun（默认必选）
框架：Next.js（App Router）
数据库与认证：Supabase（Postgres + Supabase Auth）
ORM/查询工具：Drizzle + postgres-js
UI框架：Tailwind v4 + shadcn/ui
代码检查与格式化：Biome（不使用Prettier）
单元测试：Vitest
端到端/浏览器测试：Playwright
部署平台：Vercel（默认）；文件/SQLite应用使用Fly.io

Stack layer (fresh JS/TS web projects only; confirm before running)

技术栈搭建层（仅适用于全新JS/TS Web项目；执行前需确认）

Only for an EMPTY/new project dir. Never run a project generator in a non-empty repo (it can clobber). Skip this entirely when retrofitting an existing repo.

After confirming with the user, scaffold with the official tools, e.g.:

bash

bun create next-app@latest . --typescript --app --no-eslint
bunx @biomejs/biome init
bun add -d vitest @playwright/test && bunx playwright install
bun add drizzle-orm postgres && bun add -d drizzle-kit
bunx shadcn@latest init

Adjust to the pinned stack above. Record the actual chosen stack in the repo's

AGENTS.md

Stack line. If the project is not a JS/TS web app, skip the stack layer and keep only the meta layer.

Because

biome init

runs here, AFTER the meta layer scaffolded the vault, the new

biome.json

will not yet exclude the vault. Re-run the meta layer (or

docs-vault/scripts/init-vault.sh

, which is idempotent) once Biome exists so it adds

!docs/*-vault

biome.json

files.includes. Vault notes are prose, not code, and should never be linted or formatted.

仅适用于空/新项目目录。绝不能在非空仓库中运行项目生成器（可能会覆盖文件）。改造现有仓库时完全跳过此步骤。

确认用户同意后，使用官方工具搭建项目，例如：

bash

bun create next-app@latest . --typescript --app --no-eslint
bunx @biomejs/biome init
bun add -d vitest @playwright/test && bunx playwright install
bun add drizzle-orm postgres && bun add -d drizzle-kit
bunx shadcn@latest init

根据上述固定技术栈调整配置。将实际选择的技术栈记录在仓库的

AGENTS.md

的Stack行中。若项目不是JS/TS Web应用，则跳过技术栈搭建层，仅保留元层操作。

由于

biome init

在此处运行，而元层已搭建好知识库，新生成的

biome.json

尚未排除知识库目录。Biome配置完成后，需重新运行元层（或运行幂等的

docs-vault/scripts/init-vault.sh

），以便将

!docs/*-vault

添加到

biome.json

的files.includes中。知识库笔记为散文内容，而非代码，不应被检查或格式化。

After running

执行后操作

The script scaffolds structure but stops where it needs human knowledge or a choice it cannot infer. Close those interactively now, do not leave them as TODOs or just point the user at another command:

Fill AGENTS.md.
- Commands: if a
```
package.json
```
  (or Makefile/justfile/etc.) exists, read its scripts and replace the template Commands block with the repo's real ones, including domain commands (e.g.
```
db:migrate
```
  ,
```
ingest
```
  ), not just the defaults. This is inferable, so do it without asking.
- Description and Stack: ask the user for the one-line description, but propose a draft from the README/code first so they can confirm or tweak in one reply. Fix the Stack line if the repo diverges from the default stack.
- For a fresh JS/TS web app only, run the stack layer (above) after confirming.
Register the AFK board interactively. The script leaves afk unregistered because the tracker target cannot be inferred; resolve it with the user now. The default tracker is Linear: list existing Linear projects (Linear MCP
```
list_projects
```
) and ask the user to pick one or name a new one to create (or use
```
--tracker github
```
if they prefer a GitHub board). Then run the
```
afk-setup
```
script with the chosen project so
```
~/.claude/afk.json
```
is updated.
Instantiate the standard checklist. Pick the repo profile with the user (web-app, service, cli-tool, bot, or content) and use the
```
repo-standard
```
skill's "Generate the checklist" step to write
```
docs/repo-standard.md
```
, stamped with the current standard version and profile, items startup satisfied marked done.
Register the new vault in Obsidian (where Obsidian is installed; skip on a headless box). The freshly created vault is not in Obsidian's registry yet, so repo-standard's C3 reports it "not opened yet." Add it to
```
obsidian.json
```
(
```
~/Library/Application Support/obsidian
```
on macOS,
```
~/.config/obsidian
```
on Linux) as a new entry: a 16-hex id, the vault's real path, a
```
ts
```
. Only do this when Obsidian is not running (
```
pgrep -x Obsidian
```
): a running Obsidian rewrites the registry from memory on quit and would drop a hand-added entry, so if it is running, prompt the user to open the folder as a vault instead.
Verify. Run
```
/repo-standard
```
and present the results table. With the vault registered, C3 passes end to end.
```
repo-standard
```
is the verify side of this flow: run it any time to confirm the repo is still in sync.

脚本仅搭建基础结构，在需要人工知识或无法推断的选择时会停止。需交互式完成以下操作，不要留待以后处理或仅让用户执行其他命令：

完善AGENTS.md
- 命令部分：若存在
```
package.json
```
  （或Makefile/justfile等），读取其脚本内容，将模板中的Commands区块替换为仓库的实际命令，包括领域相关命令（如
```
db:migrate
```
  、
```
ingest
```
  ），而非仅默认命令。此部分可自动推断，无需询问用户。
- 描述与技术栈：向用户请求一行项目描述，但先根据README/代码内容提供草稿，方便用户确认或调整。若仓库技术栈与默认栈不同，修正Stack行内容。
- 仅针对全新JS/TS Web应用，确认后运行上述技术栈搭建层。
交互式注册AFK看板：由于无法推断跟踪目标，脚本未完成AFK注册；需立即与用户解决此问题。默认跟踪工具为Linear：列出现有Linear项目（Linear MCP
```
list_projects
```
），询问用户选择现有项目或命名新项目（或使用
```
--tracker github
```
选择GitHub看板）。然后运行
```
afk-setup
```
脚本并传入所选项目，更新
```
~/.claude/afk.json
```
。
生成标准检查清单：与用户确认仓库类型（web-app、service、cli-tool、bot或content），使用
```
repo-standard
```
技能的“Generate the checklist”步骤生成
```
docs/repo-standard.md
```
，标记当前标准版本和类型，并将初始化已完成的项标记为已完成。
在Obsidian中注册新知识库（仅在安装了Obsidian的环境中执行；无头服务器跳过此步骤）。新创建的知识库尚未在Obsidian的注册表中，因此repo-standard的C3会报告“not opened yet”。将其添加到
```
obsidian.json
```
（macOS路径为
```
~/Library/Application Support/obsidian
```
，Linux路径为
```
~/.config/obsidian
```
）中作为新条目：包含16位十六进制ID、知识库实际路径和
```
ts
```
字段。仅在Obsidian未运行时执行此操作（可通过
```
pgrep -x Obsidian
```
检查）：运行中的Obsidian会在退出时从内存重写注册表，会丢失手动添加的条目；若Obsidian正在运行，提示用户手动将文件夹作为知识库打开。
验证：运行
```
/repo-standard
```
并展示结果表格。知识库注册完成后，C3会通过端到端验证。
```
repo-standard
```
是此流程的验证环节：可随时运行它确认仓库是否保持同步。

Pressure-test scope to make money (optional, the

make-money

lens)

范围压力测试（可选，make-money视角）

Not every repo is a commercial product. Some are just tools, internal utilities, or non-commercial apps. So make this a prompt, not an automatic step:

Ask: "Is this meant to make money, or is it just a tool? Want to run
/make-money
now to pressure-test scope toward the first paying user?"

Skip it for throwaway tools and anything not chasing revenue. If it is a money-making web app and the user says yes:

Surface it:
```
/make-money
```
is the reality check for a zero-signup, zero-revenue repo. Everything added should earn its keep toward the first paying user.
Apply it pre-emptively: before building infra, background jobs, extra services, or "nice to have" features, ask the
```
make-money
```
question: does this move us toward the first paying customer, or is it gold-plating? Default to the leanest thing that ships.

Run this before the grill-with-docs step so the lens is active while you decide what the app is.

并非所有仓库都是商业产品。有些只是工具、内部实用程序或非商业应用。因此此步骤需用户确认，而非自动执行：

询问：“此项目是否以盈利为目标，还是仅作为工具使用？是否要现在运行
/make-money
来针对首个付费用户进行范围压力测试？”

一次性工具和非盈利项目可跳过此步骤。若为盈利性Web应用且用户同意：

执行说明：
```
/make-money
```
是针对零注册、零收入仓库的现实检查。所有添加的内容都应有助于获取首个付费用户。
提前应用：在搭建基础设施、后台任务、额外服务或“锦上添花”的功能之前，先问自己make-money相关问题：这是否能帮助我们获取首个付费客户，还是过度优化？默认选择最精简的可交付方案。

在grill-with-docs步骤之前运行此操作，以便在确定应用定位时保持该视角。

Account for deployment (preview + prod)

部署规划（预览+生产）

Every app has to ship somewhere, and the preview / manual-QA flow depends on it, so deployment is a first-class concern at startup, not a thing bolted on after the build. startup does not have to set it up immediately or pick a launch date; it has to account for it so it never gets forgotten. The failure mode to prevent: a repo builds for weeks with no preview URL, so no PR can be QA'd without running locally.

Determine the target from the project shape (infer it, do not ask if it is obvious):

Network-backed web app (the default stack) is Vercel: per-PR preview deploys plus production from
```
main
```
.
File / SQLite app is Fly.io.

(See the deploy line in the pinned stack and the hosting-strategy ADR. You do not have to recommend timing here, just fix the target.)

Slot it into the phase progression deliberately. When the build is broken into phased, thin-slice issues (during grill-with-docs / to-issues), deployment must appear as its own planned item: wiring the chosen target with the app's env vars, per-branch previews, and prod. Do not silently drop it, and do not auto-append it at the end. Ask the user where in the progression it goes ("where do you want to slot deploy / preview into the build-out?"). Landing it early means every PR from then on gets a preview URL for manual QA; landing it later keeps the first slices leaner. It is their call, but make sure the question is asked and a deployment issue actually exists in the plan.

每个应用都需要部署到某个平台，而预览/手动QA流程依赖于部署，因此部署是初始化阶段的核心关注点，而非构建完成后再附加的环节。初始化工具无需立即完成部署配置或确定发布日期；但必须提前规划，确保不会被遗忘。要避免的失败场景：仓库开发数周却没有预览URL，导致所有PR都必须在本地运行才能进行QA。

根据项目类型推断部署目标（若明显则无需询问）：

网络Web应用（默认技术栈）使用Vercel：每个PR对应预览部署，生产环境从
```
main
```
分支部署。
文件/SQLite应用使用Fly.io。

（请查看固定技术栈中的部署行和托管策略ADR。无需推荐部署时间，只需确定目标平台。）

将部署规划纳入阶段进度。当构建工作拆分为阶段性的细粒度任务（在grill-with-docs / to-issues期间），部署必须作为单独的计划项：将所选平台与应用的环境变量关联，配置分支预览和生产环境。不要忽略它，也不要自动将其放在最后。询问用户部署/预览在进度中的位置（“你希望将部署/预览环节安排在构建流程的哪个阶段？”）。提前安排意味着此后每个PR都能获得预览URL用于手动QA；延后安排则能让初始阶段的工作更精简。由用户决定，但必须确保提出该问题并在计划中创建部署任务。

Lock in the shared language (the

grill-with-docs

step)

锁定共享领域语言（grill-with-docs步骤）

Final step. Once the repo is scaffolded, offer to run

/grill-with-docs

to nail down what the app is going to be and capture its ubiquitous language, so every future conversation about the repo is clear, consistent, and understood.

Offer: "Want to run
/grill-with-docs
now to lock in the domain language, or later?" It is a long, interactive, one-question-at-a-time session, so let the user choose now vs later instead of launching it unprompted.

When run, it interviews the user, sharpens fuzzy terms, and writes the results inline:

CONTEXT.md
at the repo root: the glossary and nothing else (no implementation details). This is the saved shared language that future sessions read first.
docs/adr/
: an ADR only when a decision is hard to reverse, surprising without context, and the result of a real trade-off.

This pairs with the vault from the meta layer: the vault holds durable how-it-works knowledge,

CONTEXT.md

holds the canonical vocabulary.

最后一步。仓库搭建完成后，可提议运行

/grill-with-docs

来明确应用定位并捕获通用领域语言，确保未来关于该仓库的所有对话都清晰、一致且易于理解。

提议：“是否要现在运行
/grill-with-docs
来锁定领域语言，还是稍后再进行？”这是一个较长的交互式会话，每次仅提出一个问题，因此请让用户选择现在或稍后执行，而非直接启动。

运行时，它会与用户交互，明确模糊术语，并将结果写入以下文件：

仓库根目录下的**
```
CONTEXT.md
```
**：仅包含术语表（无实现细节）。这是未来会话会优先读取的共享语言存档。
docs/adr/
：仅在决策难以逆转、缺乏上下文时会令人惊讶、且是真实权衡的结果时，才会编写ADR（架构决策记录）。

这与元层创建的知识库相辅相成：知识库存储持久化的工作原理知识，

CONTEXT.md

存储规范的词汇表。

startup

Original

Translation

startup

仓库Agent化初始化（startup）

What it does (meta layer: always, safe, idempotent)

功能说明（元层：始终安全、幂等）

Default stack (pinned; edit HERE to pivot for all future repos)

默认技术栈（固定配置；如需调整所有未来仓库的技术栈，请在此处修改）

Stack layer (fresh JS/TS web projects only; confirm before running)

技术栈搭建层（仅适用于全新JS/TS Web项目；执行前需确认）

After running

执行后操作

Pressure-test scope to make money (optional, the
`make-money`
lens)

范围压力测试（可选，make-money视角）

Account for deployment (preview + prod)

部署规划（预览+生产）

Lock in the shared language (the
`grill-with-docs`
step)

锁定共享领域语言（grill-with-docs步骤）