atelier-greenfield

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Greenfield

Bring a repo into existence already conforming to the atelier standard, green from the first commit. This is the companion skill for the one moment the main standard assumes has already happened: repo birth. The raw material, the per-variant bootstrap checklists and the copyable gate assets, already exists; this skill sequences and executes it so a fresh repo passes every gate, the fast pre-commit hook and the full CI set run locally, before a line of feature code is written.

It is one of four focused, on-demand companions to the always-on atelier standard: atelier-grill-me owns the pre-decision moment, atelier-greenfield the repo-birth moment, atelier-review-me the review and the brownfield adoption, atelier-distill the memory compaction.

Interaction and agent discipline: as the main atelier skill's Interaction section (terse, answer first, no em dashes, one question round led by your recommendation, next steps at wrap-up), including its two gates: never commit or push, and never touch an existing test, without the user's yes (rules 24-25).

创建一个从诞生起就符合 atelier 标准的仓库，从第一次 commit 开始保持 green。这是主标准所假定已经完成的那一刻的 companion skill：repo birth。所需的原料、各 variant 的 bootstrap checklist 以及可直接复制的 gate assets 均已存在；此 skill 负责安排并执行这些工作，使新仓库在写入第一行功能代码之前，所有 gate、快速 pre-commit hook 和完整 CI 集合都能在本地通过。

它是常驻 atelier 标准下四个专注且按需调用的 companion skill 之一：atelier-grill-me 负责决策前阶段，atelier-greenfield 负责 repo birth 阶段，atelier-review-me 负责评审和 brownfield adoption，atelier-distill 负责记忆压缩。

交互与 Agent 纪律：遵循主 atelier skill 的 Interaction section（简洁、先回答、不使用 em dash、每轮只问一个问题并给出建议、收尾时给出 next steps），包括其中两项 gate：未经用户明确同意，绝不 commit 或 push，也绝不改动现有 test（规则 24-25）。

When to use

何时使用

Starting a brand-new Bun/TypeScript script repo, a new package in a Next.js monorepo, or a new Java (Quarkus) service.
The user says "scaffold / bootstrap / set up a new repo (or package) to the standard".
An empty or near-empty directory that should become a conforming repo.

Greenfield only. For a repo that already has code, the main atelier skill applies, do not run this over a populated tree; it scaffolds and would collide. Match intensity to the ask: a throwaway spike does not need the full gate machinery, say so and offer the minimal subset.

启动全新的 Bun/TypeScript script 仓库、Next.js monorepo 中的新 package，或新的 Java（Quarkus）service。
用户表示要“scaffold / bootstrap / set up a new repo（或 package）to the standard”。
某个空目录或接近空目录需要变成符合标准的仓库。

仅限 Greenfield。如果仓库中已有代码，则应使用主 atelier skill，不要在已填充的目录树上运行此 skill；它会执行 scaffold，从而产生冲突。应根据需求调整执行强度：一次性 spike 不需要完整的 gate 机制，应明确说明并提供最小子集。

How to run

如何运行

Confirm variant and target directory: one question, with a recommendation. Read the shape from the directory: a
```
packages/*
```
workspace with
```
next.config.ts
```
nearby → Next.js package; a
```
pom.xml
```
context or an explicit Java ask → Java (Quarkus, Maven: every Java gate is a Maven plugin or a pom check, so a Gradle build is out of scope); otherwise → Bun-script. State your read and confirm before touching anything.
Locate the atelier assets. The gate scripts and helpers live in the installed
```
atelier
```
skill's
```
assets/
```
directory (typically
```
~/.claude/skills/atelier/assets/
```
). Resolve that path and report it. If it is missing, stop and tell the user to install the
```
atelier
```
skill first: atelier-greenfield copies from it, it does not vendor its own copies.
Follow the matching bootstrap checklist verbatim. Read and execute the numbered checklist for the variant: do not improvise the config:
- Bun-script → the installed
```
atelier
```
  skill's
```
references/bun-typescript.md
```
  (§ Bootstrap checklist): layout,
```
tsconfig
```
  , flat ESLint config,
```
Result
```
  + Logger port/adapter/fake, asset copy, coverage gate, Stryker, the two git hooks, the CI workflows (
```
assets/ci.yml
```
  plus
```
assets/check-commit-messages.sh
```
  , the rule 23 re-check that catches a
```
--no-verify
```
  bypass, and
```
assets/audit.yml
```
  , the scoped CVE watchdog),
```
bunfig.toml
```
  .
- Next.js → the installed
```
atelier
```
  skill's
```
references/nextjs-monorepo.md
```
  (§ Bootstrap checklist): package layout,
```
tsconfig
```
  /
```
eslint
```
  /
```
postcss
```
  /
```
next.config
```
  ,
```
simple-git-hooks
```
  ,
```
globals.css
```
  , the
```
src/components/{atoms,molecules,organisms}
```
  +
```
src/page
```
  +
```
src/lib
```
  +
```
src/config
```
  tree, and the CI workflows (
```
assets/ci-next.yml
```
  ,
```
assets/audit.yml
```
  ) with the scripts they call.
- Java → the installed
```
atelier
```
  skill's
```
references/java-quarkus.md
```
  (§ Bootstrap checklist): Quarkus scaffold with the Maven wrapper, the canonical pom plus The Quarkus delta, the
```
domain
```
  /
```
usecases
```
  /
```
infra
```
  /
```
api
```
  /
```
composition
```
  packages, sealed
```
Result
```
  , Flyway, and every hook, CI and gate asset in that reference's Gates and hooks copy block, copied whole, not hand-written (a partial copy fails the hook or CI's first step). Every checklist copies
```
assets/gitattributes
```
  to
```
.gitattributes
```
  , so text checks out LF on every machine (under Git for Windows' system-wide
```
core.autocrlf=true
```
  a checkout turns CRLF and the formatter fails every file). Every checklist also copies the identity gate and the discipline wrapper with its three guards (
```
check-identity.sh
```
  ,
```
check-disciplines.sh
```
  ,
```
check-pii-channels.sh
```
  ,
```
check-io-deadlines.sh
```
  ,
```
check-data-lifecycle.sh
```
  ; rules 26, 27, 29, 30): the hook runs them on the staged lines and CI with
```
--all
```
  . The isolation guard (
```
check-isolation-tests.sh
```
  , rule 28) is opt-in: copy it and call it beside the wrapper when the repo will serve tenants or owners. Every checklist also copies the reply gate (
```
check-reply.py
```
  to
```
scripts/
```
  ,
```
claude-settings.json
```
  to
```
.claude/settings.json
```
  ), a Claude Code Stop hook rather than a git hook: a reply that breaks the Interaction section's mechanical rules is restated once. And every checklist copies rule 38's watchdog (
```
check-branches.sh
```
  ,
```
check-host.py
```
  and
```
host-ruleset.json
```
  to
```
scripts/
```
  ,
```
branches.yml
```
  to
```
.github/workflows/
```
  ). The repository starts on
```
main
```
  (
```
git init -b main
```
  when the directory is not a repository yet); after the first push, which waits for the owner's yes, propose
```
python3 scripts/check-host.py --apply
```
  and run it on their yes: with their admin token it makes
```
main
```
  the default, protects it, and sets rebase-only merges with head-branch deletion (
```
references/workflow.md
```
  , Branch lifecycle). Never install both hook mechanisms: the
```
.githooks
```
  fast-gate hook for Bun-script,
```
simple-git-hooks
```
  for Next.js; the Java variant reuses
```
.githooks
```
  with its own gate chain.
Pin versions properly. Add every dependency with
```
bun add
```
/
```
bun add -d
```
so it resolves to a concrete
```
^X.Y.Z
```
; never hand-write
```
"latest"
```
or
```
"*"
```
(rule 19: gate 2 would reject it). Java: exact versions in the pom, no ranges, no SNAPSHOT deps (the enforcer blocks them).
Keep identity out of file contents (rule 26). Commit metadata carries your normal identity and needs no action. The scaffolded files carry none of it: no person, employer, or client name in a comment, a LICENSE holder line, a
```
package.json
```
author field, or a fixture; use a neutral handle (e.g.
```
atelier
```
) where a holder string is structurally required. Scrubbing a mention after a push is a
```
git filter-repo
```
history rewrite and a force-push, so catch it here. The shipped
```
check-identity.sh
```
backs this from the first commit (the hook on the staged lines, CI with
```
--all
```
): it knows the committer's name and email from git config, and employer or client names only through
```
IDENTITY_DENYLIST
```
in the environment, so set that variable when the repo is built for one. In a private repository, commit
```
.github/visibility
```
reading
```
private
```
in the first commit: the gate then warns instead of blocking, and CI checks the file against the host.
Seed session memory, the README and the standard pointer. Create
```
.claude/LESSONS.md
```
with just its header so the cross-session journal works from commit one (the one exception to lessons.md's "create it with the first real lesson"), write a README with the install steps,
```
git config core.hooksPath .githooks
```
and a
```
## Verify
```
block of entry points the CI docs step runs (guideline 5;
```
references/governance.md
```
), and write the repo's
```
CLAUDE.md
```
from the canonical block the main skill ships, so the standard rides in deterministic repo context on every future session; skill triggering is the fallback, not the mechanism. This is the primary distribution step, not a nicety: a session that never triggers the skill still carries the standard.
bash
```
{ 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
```
The block goes on top and an existing
```
CLAUDE.md
```
(the one
```
bun init
```
writes, or a brownfield repo's own) stays below it, never overwritten.
The block's text lives only in
```
assets/claude-md-pointer.md
```
; copy it, never retype it (two copies drift, the same argument as rule 23's hook). Offer
```
/init
```
afterwards to extend the file with codebase-specific documentation; the pointer block stays at the top.
Lay a minimal walking skeleton. The thinnest end-to-end slice that touches every layer (see the installed
```
atelier
```
skill's
```
references/architecture.md
```
§ The walking skeleton): for a Bun-script repo, one use-case returning
```
Result.ok
```
through its primary port, its branded input, and its confirmed test (rule 24, propose the test, get the yes, then write it); for Next.js, one
```
src/lib
```
pure function with a test wired into a page shell that renders a single atom; for Java, one application service returning
```
Ok
```
through its port with its JUnit test, plus one resource with its REST Assured test including the 401 refusal. This is not speculative code, it is what makes coverage and mutation pass for real and demonstrates the TDD loop in place. Keep it to the absolute minimum, and offer to skip it for a bare scaffold.
Prove green, then prove red. Run the inner loop and confirm each is clean:
```
bun test --randomize
```
(the
```
test
```
script, rule 36),
```
bun run lint
```
,
```
bun run typecheck
```
on every Bun-family variant; the Bun-script variant adds
```
bun run coverage
```
and
```
bun run mutate
```
(Next.js has no coverage or mutation gate; its proof is
```
bun run build
```
); for Java,
```
./mvnw spotless:check verify
```
plus PIT on the skeleton. Then prove the gates can fail (canon 15.10, a gate only ever seen green is a hypothesis), each by running the gate itself so it is red for its own reason:
```
.githooks/commit-msg
```
run on a file holding a junk subject rejects it (Next: commitlint on the same file), gate 2 rejects a planted
```
"latest"
```
dependency, the staged-lint gate rejects a planted violation, the complexity cap rejects a planted function of ten guard clauses (rule 35, complexity 11;
```
pmd:check
```
on the Java side), and on the TypeScript variants the style bans reject a planted
```
class
```
in
```
src/domain
```
(rule 1) and the layer zones a planted
```
../infra
```
import in the domain (rule 37; on a static Next.js package, an atom importing a molecule), and on a Next.js server package the zones reject
```
node:fs
```
in
```
src/domain
```
(rule 20), and on Java
```
LayerRulesTest
```
rejects a planted domain class that imports a use-case (rule 37) or reads through
```
java.nio.file
```
(rule 20) and PMD a planted
```
System.out
```
(rule 4), and on every variant the identity gate rejects a staged file carrying a name planted through
```
IDENTITY_DENYLIST
```
(rule 26; a one-word git name and a noreply email are handles it skips, so the committer alone can prove nothing) and the discipline wrapper a planted personal identifier in a query string (rule 27), and a planted inline suppression is rejected (rule 15: the lint rejects
```
// eslint-disable-next-line
```
on the TypeScript variants,
```
check-no-suppressions.sh
```
a staged
```
@SuppressWarnings
```
on Java), and on every variant the range gate rejects a merge commit with the rule 38 tag (merge a one-commit side branch with
```
git merge --no-ff
```
, then
```
bash scripts/check-commit-range.sh HEAD~1
```
), and the reply gate exits 2 with the
```
bold-lead-in
```
tag on a Stop event whose reply opens a list item in bold (
```
echo '{"hook_event_name": "Stop", "last_assistant_message": "- **Plan.** Done."}' | python3 scripts/check-reply.py --hook
```
); revert each plant. A bootstrap that does not end green, having shown red, has not finished.
Stop before the first commit. The scaffold is larger than gate 1 allows (10 files, 300 lines), so propose the landing as slices of at most 10 files, each with its Conventional-Commits message (the toolchain and configs, the gates and hooks, the CI workflows, the walking skeleton), and wait for the user's explicit yes (rule 25). If the user wants one commit, the initial scaffold is the one sanctioned bypass:
```
git commit --no-verify
```
with the justification in the body (
```
references/workflow.md
```
, Never bypass), after step 8 ran every hook gate by hand. Never auto-commit.

确认 variant 和目标目录：只问一个问题，并给出建议。 根据目录结构判断其形态：附近有
```
next.config.ts
```
的
```
packages/*
```
workspace → Next.js package；存在
```
pom.xml
```
上下文或用户明确要求 Java → Java（Quarkus, Maven：每个 Java gate 都是 Maven plugin 或 pom 检查，因此 Gradle build 不在范围内）；其他情况 → Bun-script。说明你的判断，并在做任何修改前获得确认。
定位 atelier assets。 gate scripts 和 helpers 位于已安装的
```
atelier
```
skill 的
```
assets/
```
目录（通常是
```
~/.claude/skills/atelier/assets/
```
）。解析该路径并报告。如果它不存在，请停止操作并告知用户先安装
```
atelier
```
skill：atelier-greenfield 会从该目录复制文件，但不会内置自己的副本。
逐字遵循匹配的 bootstrap checklist。 读取并执行对应 variant 的编号 checklist，不要自行即兴修改 config：
- Bun-script → 已安装的
```
atelier
```
  skill 的
```
references/bun-typescript.md
```
  （§ Bootstrap checklist）：布局、
```
tsconfig
```
  、flat ESLint config、
```
Result
```
  + Logger port/adapter/fake、asset copy、coverage gate、Stryker、两个 git hooks、CI workflows（
```
assets/ci.yml
```
  以及
```
assets/check-commit-messages.sh
```
  、用于捕获
```
--no-verify
```
  绕过行为的 rule 23 复查，以及作为限定范围 CVE watchdog 的
```
assets/audit.yml
```
  ）、
```
bunfig.toml
```
  。
- Next.js → 已安装的
```
atelier
```
  skill 的
```
references/nextjs-monorepo.md
```
  （§ Bootstrap checklist）：package 布局、
```
tsconfig
```
  /
```
eslint
```
  /
```
postcss
```
  /
```
next.config
```
  、
```
simple-git-hooks
```
  、
```
globals.css
```
  、
```
src/components/{atoms,molecules,organisms}
```
  +
```
src/page
```
  +
```
src/lib
```
  +
```
src/config
```
  目录树，以及 CI workflows（
```
assets/ci-next.yml
```
  、
```
assets/audit.yml
```
  ）及其调用的 scripts。
- Java → 已安装的
```
atelier
```
  skill 的
```
references/java-quarkus.md
```
  （§ Bootstrap checklist）：使用 Maven wrapper 搭建 Quarkus scaffold、标准 pom 以及 Quarkus 增量配置、
```
domain
```
  /
```
usecases
```
  /
```
infra
```
  /
```
api
```
  /
```
composition
```
  packages、sealed
```
Result
```
  、Flyway，以及该 reference 的 Gates and hooks copy block 中的每个 hook、CI 和 gate asset。必须完整复制，不得手写（只复制一部分会导致 hook 或 CI 的第一步失败）。每份 checklist 都会将
```
assets/gitattributes
```
  复制为
```
.gitattributes
```
  ，从而让文本在每台机器上检出时都使用 LF（在 Git for Windows 的系统级
```
core.autocrlf=true
```
  下，checkout 会将 CRLF 转换回来，导致 formatter 对每个文件都失败）。每份 checklist 还会复制 identity gate 和 discipline wrapper 及其 guards（
```
check-identity.sh
```
  、
```
check-disciplines.sh
```
  、
```
check-pii-channels.sh
```
  、
```
check-io-deadlines.sh
```
  、
```
check-data-lifecycle.sh
```
  ；规则 26、27、29、30）：hook 会对 staged lines 运行这些检查，CI 则使用
```
--all
```
  运行。isolation guard（
```
check-isolation-tests.sh
```
  ，规则 28）需要选择性启用：当仓库将服务多个 tenants 或 owners 时，复制它并在 wrapper 旁调用。每份 checklist 还会复制 reply gate（将
```
check-reply.py
```
  复制到
```
scripts/
```
  ，将
```
claude-settings.json
```
  复制到
```
.claude/settings.json
```
  ）。这是 Claude Code Stop hook，而非 git hook：如果 reply 违反 Interaction section 的机械规则，则会被重述一次。每份 checklist 还会复制 rule 38 的 watchdog（将
```
check-branches.sh
```
  、
```
check-host.py
```
  和
```
host-ruleset.json
```
  复制到
```
scripts/
```
  ，将
```
branches.yml
```
  复制到
```
.github/workflows/
```
  ）。仓库从
```
main
```
  开始（目录尚不是 repository 时执行
```
git init -b main
```
  ）；首次 push 需要等待 owner 明确同意，完成后建议运行
```
python3 scripts/check-host.py --apply
```
  ，并在得到同意后执行：借助 owner 的 admin token，它会将
```
main
```
  设为默认分支并加以保护，同时设置仅允许 rebase 的 merge，并删除 head branch（
```
references/workflow.md
```
  ，Branch lifecycle）。绝不能同时安装两套 hook 机制：Bun-script 使用
```
.githooks
```
  fast-gate hook，Next.js 使用
```
simple-git-hooks
```
  ；Java variant 复用
```
.githooks
```
  ，但采用自己的 gate chain。
正确锁定版本。 使用
```
bun add
```
/
```
bun add -d
```
添加每个依赖，使其解析为具体的
```
^X.Y.Z
```
；绝不要手写
```
"latest"
```
或
```
"*"
```
（规则 19：gate 2 会拒绝这些写法）。Java：在 pom 中使用精确版本，不使用版本范围，也不使用 SNAPSHOT 依赖（enforcer 会阻止这些配置）。
确保身份信息不出现在文件内容中（规则 26）。 Commit metadata 会携带你的常规身份信息，无需处理。Scaffold 创建的文件不得包含任何此类信息：注释、LICENSE holder 行、
```
package.json
```
author 字段或 fixture 中均不得出现人员、雇主或客户名称；如果结构上必须提供 holder 字符串，请使用中性 handle（例如
```
atelier
```
）。Push 后再清除此类提及需要进行
```
git filter-repo
```
历史重写和 force-push，因此必须在此阶段拦截。随附的
```
check-identity.sh
```
会从第一次 commit 起提供保障（hook 检查 staged lines，CI 使用
```
--all
```
）：它从 git config 获取 committer 的姓名和邮箱，而雇主或客户名称只能通过环境变量
```
IDENTITY_DENYLIST
```
提供，因此当仓库为特定组织构建时应设置该变量。在私有仓库中，第一次 commit 应包含读取为
```
private
```
的
```
.github/visibility
```
：此时 gate 会发出警告而不是阻止，CI 会根据 hosting platform 检查该文件。
初始化 session memory、README 和标准指针。 创建只包含 header 的
```
.claude/LESSONS.md
```
，使跨 session journal 从第一次 commit 起即可使用（这是“出现第一条真实经验时再创建 lessons.md”规则的唯一例外）；编写 README，包含安装步骤、
```
git config core.hooksPath .githooks
```
，以及 CI 文档步骤运行的入口点所对应的
```
## Verify
```
block（guideline 5；
```
references/governance.md
```
）；根据主 skill 随附的 canonical block 编写仓库的
```
CLAUDE.md
```
，使标准在之后每个 session 中都通过确定性的 repo context 生效；skill triggering 只是 fallback，而不是主要机制。这是首要的分发步骤，而非锦上添花：即使某个 session 从未触发 skill，仓库仍然携带该标准。
bash
```
{ 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
```
该 block 会放在顶部，现有
```
CLAUDE.md
```
（可能是
```
bun init
```
创建的文件，或 brownfield repo 自己的文件）保留在下方，绝不会被覆盖。 Block 的文本只存在于
```
assets/claude-md-pointer.md
```
；应复制它，绝不能重新输入（两份副本会发生漂移，这与 rule 23 的 hook 采用相同理由）。之后可以提供
```
/init
```
，用代码库专属文档扩展该文件，同时保留顶部的指针 block。
铺设最小 walking skeleton。 这是触碰每一层的最薄端到端切片（参见已安装的
```
atelier
```
skill 的
```
references/architecture.md
```
§ The walking skeleton）：对于 Bun-script repo，提供一个通过 primary port 返回
```
Result.ok
```
的 use-case、一个 branded input，以及一个经过确认的 test（规则 24：先提出 test，获得用户同意后再编写）；对于 Next.js，提供一个
```
src/lib
```
pure function、一个接入 page shell 并渲染单个 atom 的 test；对于 Java，提供一个通过 port 返回
```
Ok
```
的 application service 及其 JUnit test，再提供一个 resource 及包含 401 拒绝场景的 REST Assured test。这不是推测性代码，而是让 coverage 和 mutation 能够真实通过，并展示已经就位的 TDD loop。必须控制在绝对最小的范围内，并提供跳过 walking skeleton、仅生成 bare scaffold 的选项。
先证明 green，再证明 red。 运行 inner loop，并确认每项都干净：在所有 Bun-family variant 中运行
```
bun test --randomize
```
（
```
test
```
script，规则 36）、
```
bun run lint
```
、
```
bun run typecheck
```
；Bun-script variant 还需运行
```
bun run coverage
```
和
```
bun run mutate
```
（Next.js 没有 coverage 或 mutation gate；其证明方式是
```
bun run build
```
）；对于 Java，运行
```
./mvnw spotless:check verify
```
，并在 skeleton 上运行 PIT。随后证明这些 gate 确实能够失败（canon 15.10：一个从未被看到失败过的 gate 只能算一个假设）。每项都要实际运行 gate 本身，使其因自身原因变红：让
```
.githooks/commit-msg
```
检查一个包含垃圾主题的文件并确认其被拒绝（Next.js 在同一文件上使用 commitlint）；让 gate 2 拒绝一个植入的
```
"latest"
```
依赖；让 staged-lint gate 拒绝一个植入的违规项；让 complexity cap 拒绝一个包含十个 guard clauses 的植入函数（规则 35，complexity 11；Java 一侧使用
```
pmd:check
```
）；在 TypeScript variant 中，让 style bans 拒绝植入到
```
src/domain
```
的
```
class
```
（规则 1），并让 layer zones 拒绝 domain 中植入的
```
../infra
```
import（规则 37；对于 static Next.js package，则是 atom import molecule）；在 Next.js server package 中，让 zones 拒绝
```
src/domain
```
中的
```
node:fs
```
（规则 20）；在 Java 中，让
```
LayerRulesTest
```
拒绝一个 import use-case 的植入 domain class（规则 37），或拒绝通过
```
java.nio.file
```
读取文件的行为（规则 20），并让 PMD 拒绝植入的
```
System.out
```
（规则 4）；在每个 variant 中，让 identity gate 拒绝一个 staged file，其中通过
```
IDENTITY_DENYLIST
```
植入了一个受禁名称（规则 26：单词形式的 Git 名称和 noreply 邮箱属于会被跳过的 handle，因此仅靠 committer 无法证明任何问题），并让 discipline wrapper 拒绝植入 query string 的个人标识符（规则 27）；让植入的内联 suppression 被拒绝（规则 15：TypeScript variant 的 lint 拒绝
```
// eslint-disable-next-line
```
，Java 使用
```
check-no-suppressions.sh
```
拒绝 staged
```
@SuppressWarnings
```
）；在每个 variant 中，让 range gate 拒绝带 rule 38 标签的 merge commit（使用
```
git merge --no-ff
```
合并一个只有一次 commit 的 side branch，然后运行
```
bash scripts/check-commit-range.sh HEAD~1
```
）；让 reply gate 在某个 Stop event 的 reply 以粗体开启一个列表项时，以
```
bold-lead-in
```
标签退出并返回状态码 2（
```
echo '{"hook_event_name": "Stop", "last_assistant_message": "- **Plan.** Done."}' | python3 scripts/check-reply.py --hook
```
）。撤销每个植入项。一个 bootstrap 在展示了 red 后如果没有最终回到 green，就尚未完成。
在第一次 commit 前停止。 Scaffold 的规模超过 gate 1 的限制（10 个文件、300 行），因此应将其拆分为每次最多 10 个文件的 landing slices，并为每个 slice 提供 Conventional-Commits message（toolchain 和 configs、gates 和 hooks、CI workflows、walking skeleton），然后等待用户明确同意（规则 25）。如果用户希望只使用一次 commit，初始 scaffold 是唯一获准的 bypass：在 step 8 已手动运行每个 hook gate 后，可以使用
```
git commit --no-verify
```
，并在正文中说明理由（
```
references/workflow.md
```
，Never bypass）。绝不自动 commit。

Output

输出

A directory that passes every gate, with a one-screen summary: variant chosen, assets copied (and from where), hooks wired, file contents identity-clean (rule 26), scripts added, the walking skeleton's single scenario, the inner-loop results, and the proposed first-commit message awaiting confirmation.

Scaffold the simplest conforming repo that runs green: the walking skeleton is one slice, not a feature. Everything past it is built later, test-first, under the main atelier standard. Out of scope here: brownfield adoption of an existing repo, deployment pipelines, Docker, and choosing a web framework. The CI gate workflow is IN scope:

assets/ci.yml

assets/ci-next.yml

assets/ci-java.yml

ship with the bootstrap (the authoritative gate set), only what lies beyond the gates (deploy, environments) is not.

This skill is the standard's paved road (the golden path): a repo born from it starts already passing every gate, instead of migrating toward compliance later. Ship real artifacts, not instructions; the fastest way to start is also the compliant one. When the new repo will hold personal data, serve multiple tenants, or call an AI model, name the production disciplines that will bind (atelier rules 27-34) in the wrap-up summary so the first features are designed with them, not retrofitted.

一个通过所有 gate 的目录，并提供一屏式摘要：选择的 variant、已复制的 assets 及其来源、已配置的 hooks、身份信息干净的文件内容（规则 26）、新增的 scripts、walking skeleton 的单一场景、inner-loop 结果，以及等待确认的首次 commit message。

Scaffold 应当生成能够 green 运行的最简单合规仓库：walking skeleton 只是一个切片，而不是一项功能。其后的所有内容都在主 atelier 标准下以 test-first 方式构建。此处不在范围内：brownfield adoption of an existing repo、deployment pipelines、Docker，以及选择 web framework。CI gate workflow 在范围内：

assets/ci.yml

assets/ci-next.yml

assets/ci-java-java.yml

会随 bootstrap 一同提供（它们是权威 gate 集合），只有超出 gate 的部分（deploy、environments）不在范围内。

此 skill 是该标准的 paved road（golden path）：由它诞生的仓库从一开始就能通过所有 gate，而不是之后再逐步迁移到合规状态。应交付真实 artifacts，而不是说明文档；最快的启动方式同时也是合规的启动方式。当新仓库将处理 personal data、服务多个 tenants 或调用 AI model 时，应在收尾摘要中明确列出将约束后续工作的 production disciplines（atelier 规则 27-34），确保首个 feature 从设计之初就遵循这些要求，而不是事后补加。