SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsatelier-greenfield

atelier-greenfield

Deployment & operations

View repository

Updated 10-16 03:42

About this skill

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

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

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

  3. 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 the branch watchdog (check-branches.sh to scripts/, branches.yml to .github/workflows/, rule 38); the owner sets the host to rebase-only merges with automatic head-branch deletion, once (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.

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

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

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

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

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

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

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