atelier-greenfield

Greenfield

让一个仓库从诞生的第一个提交起，就符合 atelier 标准。这是为主标准假定已经完成的那一刻准备的配套技能：仓库诞生。原材料、各变体的引导清单和可复制的门禁资产都已准备就绪；此技能负责安排并执行这些步骤，让新仓库通过所有门禁，并在本地运行快速 pre-commit 钩子和完整的 CI 套件，然后才开始编写任何功能代码。

它是四个专注、按需使用的配套技能之一，配合始终启用的 atelier 标准：atelier-grill-me 负责决策前的时刻，atelier-greenfield 负责仓库诞生的时刻，atelier-review-me 负责代码审查和 brownfield 采用，atelier-distill 负责记忆压缩。

交互与 Agent 规范：遵循主 atelier 技能的 Interaction 部分（简洁，先给答案，不使用 em dash，围绕你的建议进行一轮提问，在结束时给出后续步骤），并遵守其中两项门禁：未经用户同意，绝不提交或推送，也绝不修改现有测试（规则 24-25）。

适用场景

• 启动全新的 Bun/TypeScript 脚本仓库、在 Next.js monorepo 中新建一个包，或创建新的 Java (Quarkus) 服务。
• 用户说“按标准构建脚手架／引导／设置一个新仓库（或包）”。
• 一个空目录或几乎为空的目录，需要将其构建为符合标准的仓库。

仅适用于 Greenfield。对于已有代码的仓库，应使用主 atelier 技能，不要在已有内容的目录树上运行此技能；它会构建脚手架并造成冲突。根据用户的需求调整投入力度：临时试验不需要完整的门禁机制，请说明这一点并提供最精简的子集。

运行方法

1. 确认变体和目标目录：提出一个问题，并给出建议。 根据目录结构判断：附近有 packages/* 工作区和 next.config.ts → Next.js 包；处于 pom.xml 上下文，或明确要求使用 Java → Java（Quarkus、Maven：每个 Java 门禁都是 Maven 插件或 pom 检查，因此 Gradle 构建不在范围内）；否则 → Bun-script。说明你的判断，并在动手前征求确认。

2. 定位 atelier 资源。 门禁脚本和辅助工具位于已安装的 atelier 技能的 assets/ 目录（通常是 ~/.claude/skills/atelier/assets/）。解析该路径并报告。如果路径不存在，请停止并告知用户先安装 atelier 技能：atelier-greenfield 会从该技能复制文件，不会自带副本。

3. 逐字遵循相应的引导清单。 阅读并执行对应变体的编号清单：不要自行设计配置：

   • Bun-script → 已安装的 atelier 技能中的 references/bun-typescript.md（§ Bootstrap checklist）：目录布局、tsconfig、扁平 ESLint 配置、Result + Logger 端口/适配器/伪实现、资源复制、覆盖率门禁、Stryker、两个 git 钩子、CI 工作流（assets/ci.yml 加上 assets/check-commit-messages.sh，用于重新检查规则 23、捕获 --no-verify 绕过的情况；以及 assets/audit.yml，用于监控指定范围的 CVE）、bunfig.toml。
   • Next.js → 已安装的 atelier 技能中的 references/nextjs-monorepo.md（§ Bootstrap checklist）：包布局、tsconfig/eslint/postcss/next.config、simple-git-hooks、globals.css、src/components/{atoms,molecules,organisms} + src/page + src/lib + src/config 目录树，以及 CI 工作流（assets/ci-next.yml、assets/audit.yml）和它们调用的脚本。
   • Java → 已安装的 atelier 技能中的 references/java-quarkus.md（§ Bootstrap checklist）：带 Maven wrapper 的 Quarkus 脚手架、规范 pom 加上 The Quarkus delta、domain/usecases/infra/api/composition 包、密封的 Result、Flyway，以及该参考文档 Gates and hooks 复制块中的所有钩子、CI 和门禁资源；整块复制，不要手写（不完整的复制会导致钩子或 CI 的第一步失败）。 每份清单都会将 assets/gitattributes 复制到 .gitattributes，确保所有机器上的文本检出时都使用 LF（在 Git for Windows 的系统级 core.autocrlf=true 设置下，检出结果会变成 CRLF，导致格式检查对每个文件都失败）。 每份清单还会复制身份门禁和包含三个防护的规范检查封装脚本（check-identity.sh、check-disciplines.sh、check-pii-channels.sh、check-io-deadlines.sh、check-data-lifecycle.sh；规则 26、27、29、30）：钩子会对暂存行运行这些检查，CI 则使用 --all 运行。隔离防护（check-isolation-tests.sh，规则 28）为可选项：如果仓库将服务于租户或所有者，请复制它并在封装脚本旁调用它。每份清单还会复制回复门禁（将 check-reply.py 复制到 scripts/，将 claude-settings.json 复制到 .claude/settings.json）；这是 Claude Code Stop 钩子，而不是 git 钩子：如果回复违反 Interaction 部分的机械规则，会将其重述一次。每份清单还会复制规则 38 的监控脚本（将 check-branches.sh、check-host.py 和 host-ruleset.json 复制到 scripts/，将 branches.yml 复制到 .github/workflows/）。仓库从 main 开始（如果目录尚不是仓库，则运行 git init -b main）；首次推送后（需等待所有者同意），建议运行 python3 scripts/check-host.py --apply，并在所有者同意后执行：该脚本使用其管理员令牌将 main 设为默认分支、启用保护，并将合并方式设为仅 rebase 且删除源分支（references/workflow.md，Branch lifecycle）。 切勿同时安装两种钩子机制：Bun-script 使用 .githooks 快速门禁钩子，Next.js 使用 simple-git-hooks；Java 变体使用自己的门禁链复用 .githooks。

4. 正确固定版本。 使用 bun add / bun add -d 添加每个依赖，使其解析为具体的 ^X.Y.Z；绝不要手写 "latest" 或 "*"（规则 19：门禁 2 会拒绝）。Java：pom 中使用精确版本，不得使用版本范围或 SNAPSHOT 依赖（enforcer 会阻止）。

5. 将身份信息排除在文件内容之外（规则 26）。 提交元数据会携带你的常用身份，无需处理。脚手架文件不得包含这些信息：注释、LICENSE 持有人行、package.json 的 author 字段或测试 fixture 中，都不能出现个人、雇主或客户名称；如果结构上必须填写持有人字符串，请使用中性名称（例如 atelier）。推送后再清除提及内容，需要通过 git filter-repo 重写历史并强制推送，因此应在这里提前检查。随附的 check-identity.sh 从首次提交起就会执行此检查（钩子检查暂存行，CI 使用 --all）：它会从 git 配置中读取提交者姓名和邮箱，雇主或客户名称则仅通过环境变量 IDENTITY_DENYLIST 获取，因此如果仓库是为某一雇主或客户构建的，请设置该变量。在私有仓库中，请在首次提交时提交内容为 private 的 .github/visibility：之后门禁会发出警告，而不是阻止操作；CI 也会检查该文件与代码托管平台上的设置是否一致。

6. 初始化会话记忆、README 和标准指引文件。 创建 .claude/LESSONS.md，其中只包含标题，以便从第一次提交起就能使用跨会话日志（这是 lessons.md“在有第一条实际经验时再创建”的唯一例外）；编写 README，写明安装步骤、git config core.hooksPath .githooks，以及 CI 文档步骤会运行的入口点的 ## Verify 区块（规范 5；references/governance.md）；按照主技能提供的规范区块编写仓库的 CLAUDE.md，让每次后续会话都能在确定的仓库上下文中获取这套标准；技能触发只是兜底机制，不是传递标准的方式。这是主要的分发步骤，不是可有可无的优化：即使某个会话从未触发该技能，也会遵循这套标准。

   { printf '# CLAUDE.md\n\n'; cat <skill>/assets/claude-md-pointer.md
     if [ -f CLAUDE.md ]; then printf '\n'; sed '1{/^# CLAUDE\.md$/d;}' CLAUDE.md; fi
   } > CLAUDE.md.new && mv CLAUDE.md.new CLAUDE.md
   

   该代码块位于顶部，现有的 CLAUDE.md（由 bun init 写入的文件，或存量代码库自带的文件）保留在其下方，绝不会被覆盖。 该区块的文本仅存放在 assets/claude-md-pointer.md 中；请复制，不要重新输入（两份副本会逐渐不一致，理由与规则 23 的钩子相同）。之后提供 /init，以便为文件补充代码库专属文档；指针区块保留在顶部。

7. 搭建最小可运行骨架。 贯穿每一层的最精简端到端切片（参见已安装的 atelier 技能中的 references/architecture.md § 最小可运行骨架）：对于 Bun 脚本仓库，创建一个通过主要端口返回 Result.ok 的用例、其带品牌类型的输入，以及经确认的测试（规则 24：提出测试，获得同意后再编写）；对于 Next.js，创建一个带测试的 src/lib 纯函数，并将其接入只渲染单个原子的页面外壳；对于 Java，创建一个通过端口返回 Ok 的应用服务及其 JUnit 测试，再创建一个资源及其 REST Assured 测试，其中包括 401 拒绝响应。这不是推测性代码，而是让覆盖率和变异测试真正通过、并展示 TDD 循环已就位的内容。将其精简到绝对最低限度，并提供跳过选项，以便只搭建空脚手架。

8. 先证明通过，再证明失败。 运行内循环并确认每项都干净：所有 Bun 系变体运行 bun test --randomize（test 脚本，规则 36）、bun run lint、bun run typecheck；Bun 脚本变体还要运行 bun run coverage 和 bun run mutate（Next.js 没有覆盖率或变异测试门禁；其证明是 bun run build）；Java 则运行 ./mvnw spotless:check verify，并对骨架运行 PIT。然后证明这些门禁确实可以失败（规范 15.10：只见过绿灯的门禁仍只是个假设）。分别运行各门禁本身，让它因自身原因而变红：在含有无效提交主题的文件上运行 .githooks/commit-msg，确认其拒绝提交（Next.js：在同一文件上运行 commitlint）；门禁 2 拒绝植入的 "latest" 依赖；暂存区 lint 门禁拒绝植入的违规内容；复杂度上限拒绝植入一个含十个保护子句的函数（规则 35，复杂度为 11；Java 侧运行 pmd:check）；TypeScript 变体中的样式禁令拒绝在 src/domain 中植入的 class（规则 1），分层区域规则拒绝领域层中植入的 ../infra 导入（规则 37；在静态 Next.js 包中，则在原子中植入分子导入）；Next.js 服务端包中的区域规则拒绝 src/domain 中植入的 node:fs（规则 20）；Java 中，LayerRulesTest 拒绝植入的、导入用例的领域类（规则 37）或通过 java.nio.file 读取内容的领域类（规则 20），PMD 拒绝植入的 System.out（规则 4）；所有变体的身份门禁都拒绝暂存文件中带有通过 IDENTITY_DENYLIST 植入的姓名（规则 26；单词形式的 git 名称和 noreply 邮箱会被跳过，因此提交者不能独自证明这一点）；规范包装器拒绝查询字符串中植入的个人标识符（规则 27）；植入的内联抑制也会被拒绝（规则 15：TypeScript 变体的 lint 会拒绝 // eslint-disable-next-line，Java 的 check-no-suppressions.sh 会拒绝暂存的 @SuppressWarnings）；所有变体的范围门禁拒绝带有规则 38 标签的合并提交（将仅有一个提交的侧分支用 git merge --no-ff 合并，然后运行 bash scripts/check-commit-range.sh HEAD~1）；对于停止事件中以粗体开头的列表项作为回复的情况，回复门禁会以状态码 2 退出，并附带 bold-lead-in 标签（echo '{"hook_event_name": "Stop", "last_assistant_message": "- **Plan.** Done."}' | python3 scripts/check-reply.py --hook）。撤销每项植入。若引导流程没有在展示红灯后以绿灯结束，就还没有完成。

9. 在首次提交前停下。 脚手架规模超过门禁 1 的限制（10 个文件、300 行），因此应将落地方案拆分为每次最多 10 个文件的切片，并为每个切片提供 Conventional Commits 消息（工具链和配置、门禁和钩子、CI 工作流、最小可运行骨架），然后等待用户明确同意（规则 25）。如果用户希望只提交一次，初始脚手架是唯一获准绕过的情形：在正文中说明理由后使用 git commit --no-verify（references/workflow.md，切勿绕过），且必须在步骤 8 手动运行每个钩子门禁。切勿自动提交。

输出

一个通过所有门禁的目录，并附带一屏摘要：所选变体、复制的资产（及其来源）、已接入的钩子、文件内容身份核验通过（规则 26）、新增的脚本、行走骨架的单个场景、内循环结果，以及等待确认的拟议首次提交消息。

搭建能通过所有门禁的最简单合规仓库：行走骨架只是一个切片，不是一个功能。除此之外的所有内容都将在之后依照主 atelier 标准，采用测试先行的方式构建。此处不包括：现有仓库的棕地采用、部署流水线、Docker，以及选择 Web 框架。CI 门禁工作流属于范围内：assets/ci.yml / assets/ci-next.yml / assets/ci-java.yml 随引导流程一同提供（即权威门禁集）；只有超出门禁范围的内容（部署、环境）不包括在内。

此技能是该标准铺设好的道路（金色路径）：从中诞生的仓库一开始就通过所有门禁，而不是之后再逐步迁移以满足合规要求。交付真实产物，而非操作说明；最快的起步方式也是合规的方式。当新仓库将存储个人数据、服务多个租户或调用 AI 模型时，请在收尾摘要中列出将适用的生产规范（atelier 规则 27-34），让首批功能从设计之初就遵循这些规范，而不是事后补上。