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).

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.

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.

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.

atelier-greenfield

NPX Install

Tags

SKILL.md Content

Greenfield

When to use

How to run

Output