メニュー
Mirror .gitignore to .dockerignore. Use whenever a .gitignore entry is added or removed, or when auditing a bloated Docker build context.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | ignore-sync |
| description | Mirror .gitignore to .dockerignore. Use whenever a .gitignore entry is added or removed, or when auditing a bloated Docker build context. |
.dockerignore does not inherit from .gitignore. Anything git ignores but .dockerignore misses still enters the Docker build context (COPY . . in the prepare stage of web/next/Dockerfile and api/hono/Dockerfile), and on this repo that has meant gigabytes: web/next/.next alone hit 3GB, .turbo 23GB.
.gitignore is the source of truth; .dockerignore follows it. The two files are byte-identical except one line: the platform-tail label (# git overrides vs # docker overrides). Every ignore rule AND every shared ! un-ignore (e.g. !.yarn/patches) lives in the shared body: same entry, same section, same order, in both files, in the same commit.
The one sanctioned divergence is the labeled platform tail at the end of each file, for a git-only or docker-only override. Today both tails carry only !.env.example under their respective label.
Real .env* files never enter the Docker context. Each build mounts the host file as a required BuildKit secret (--mount=type=secret,id=dotenv,target=/app/.env,required=true; compose supplies it via secrets.dotenv.file: .env), so it bypasses the context, is validated in full during the build, and never lands in a layer. If a diff re-includes .env* to feed a builder-stage COPY, that is drift; sync it away.
diff -u .gitignore .dockerignore
Done when the ONLY difference is the tail label:
-# git overrides
+# docker overrides
Any other line is a missing sync.
Add a new shared workspace package under packages/*. Use when creating a new @packages/<name>, whether a bundled library other workspaces import or a build-only script package that runs during a build.
Orient in this repo: which file to edit for a change, how a change ripples across the stack, and how to search the code. Use at the start of a task in an unfamiliar area, or before a cross-cutting change.
Prefer Bun-native APIs, else Node built-ins with the node: prefix. Use when importing a Node built-in (fs, path, child_process, crypto, os, util), reading or writing files, spawning a process, or choosing between a Bun and a Node API.
Icebox a raised-but-undecided concern instead of forcing a plan-or-dismiss call: record it with no verdict so the context survives. Use when a review, PR, audit, or eval surfaces something real-maybe that should not be scheduled or closed yet, or when the user says to icebox or park an item.
Add a typed Hono API endpoint or WebSocket route: router, OpenAPI docs, validation envelope, and RPC client wiring. Use when adding or modifying routes in api/hono.
Start, restart, and verify the ZeroStarter dev stack. `bun run dev` serves portless named `.localhost` URLs (branch-prefixed in a worktree); resolve them with `bunx portless get`. Use when asked to run the app, when the API returns NOT_FOUND for routes that exist in source, or before browser testing.