0620416869
All checks were successful
check / check (push) Successful in 7s
A golangci-lint result on a host running many concurrent workers does not reliably belong to the tree that asked for it. Two independent mechanisms, which have repeatedly been mistaken for one: The result cache is keyed on file content, not location, so two checkouts of the same commit hold byte-identical files, share cache entries, and one tree's findings are served for the other under the other tree's path. This produced a confirmed false green as well as the loud false reds. Moving workers from shared worktrees to their own clones does not address it — two clones collide exactly as two worktrees did — and removes only the foreign-path artefact that made the defect noticeable. The concurrency lock is $TMPDIR/golangci-lint.lock (pkg/commands/run.go, acquireFileLock), host-global and independent of GOLANGCI_LINT_CACHE, with a five-second acquire timeout, so it fails when the host is busiest. A private cache directory does not isolate it. Setting only the cache closes the contamination half and leaves runs failing red on a condition that is not a result at all. REPO_POLICIES.md now carries the canonical Go script/lint: both variables scoped into a .lint-cache/ directory inside the checkout, above any container-versus-host branch so every path reaching the linter gets them; --allow-serial-runners, which keeps the mutual-exclusion guard and queues rather than aborting, for the same-checkout overlap TMPDIR scoping cannot cover, with --allow-parallel-runners rejected because it deletes the guard; and a bounded retry that treats the lock error as VOID rather than as findings, exiting 75 on exhaustion so it is neither a pass nor a failure. Detection is on the stderr stream and never on exit status: findings go to stdout, so a finding quoting the lock message in source cannot be retried away, and the exit status is not a stable discriminator anyway. The interim void rule is recorded with the ../ clause that the original filter missed, and with its limit stated — it catches contamination that names foreign files, not contamination that suppresses findings. Both checklists gained the corresponding items, since a half-fix that sets only the cache reads as complete. GOCACHE was measured rather than assumed and does not need isolating: with the two variables scoped per checkout and GOCACHE shared at the host default, each checkout reported its own paths. Verified with the snippet extracted from the committed document and executed as a consuming repo would adopt it, each control paired against the pre-fix form: contamination reproduced on the pre-fix script and absent on the adopted one; a stub linter colliding twice then clearing, with the retry engaging and succeeding; exhaustion exiting 75 with a VOID message; a genuine finding whose text quotes the lock message reported as findings with no retry; and a real held lock failing the pre-fix script with exit 3 while the adopted script, inheriting the same environment, completed in one second.
prompts
prompts is an MIT-licensed collection of LLM prompts by @sneak, including development policy prompts and other useful prompts for working with large language models.
Quick Start
Existing Repo
Run from within the repo you want to bring up to standards. Clone the prompts repo once, then run both commands in order.
export TD="$(mktemp -d)"
git clone --depth 1 https://git.eeqj.de/sneak/prompts.git "$TD"
Repository structure and policies:
claude "Read $TD/prompts/REPO_POLICIES.md and
$TD/prompts/EXISTING_REPO_CHECKLIST.md, then bring this repo up to those
standards. Your scope is repo scaffolding and policy compliance:
Makefile, Dockerfile, .dockerignore, .gitignore, .editorconfig, CI
workflow, README sections, LICENSE, REPO_POLICIES.md, and any
language-specific config files (.golangci.yml, .prettierrc, etc.).
You must also run the formatter (make fmt) and fix any linter errors
(make lint) so that make check passes — this will touch source code,
but do not restructure, refactor, or rewrite any application logic.
Follow the policies yourself: work on a feature branch, never git add -A,
and make each logical change a separate commit (e.g. one commit for
formatting, one for linter fixes, one for README updates, one for each
new repo file added, etc.)."
Code style and conventions:
claude "Read $TD/prompts/CODE_STYLEGUIDE.md and whichever
language-specific styleguides in $TD/prompts/ apply to this repo
(CODE_STYLEGUIDE_GO.md, CODE_STYLEGUIDE_JS.md, CODE_STYLEGUIDE_PYTHON.md,
GO_HTTP_SERVER_CONVENTIONS.md). Then review the application code in this
repo and bring it into compliance with those coding standards. Your scope
is application code structure and style: naming, patterns, error
handling, project layout, and conventions described in the styleguides.
Do not modify repo scaffolding (Makefile, Dockerfile, CI workflow,
.gitignore, .editorconfig, etc.) — only application code. Work on a
feature branch, never git add -A, and make each logical change a
separate commit."
New Repo
Run from inside the directory where you want to create a new repo. Clone the prompts repo once, then run both commands in order.
export TD="$(mktemp -d)"
git clone --depth 1 https://git.eeqj.de/sneak/prompts.git "$TD"
Repository scaffolding:
claude "Read $TD/prompts/REPO_POLICIES.md and
$TD/prompts/NEW_REPO_CHECKLIST.md, then set up this new repo according
to those standards. Your scope is repo structure and required files:
README.md, LICENSE, REPO_POLICIES.md, Makefile, Dockerfile, .dockerignore,
.gitignore, .editorconfig, CI workflow, and language-specific config.
Run the formatter (make fmt) and fix any linter errors (make lint) so
that make check passes — this will touch source code, but do not
restructure, refactor, or rewrite any application logic. Follow the
policies yourself: work on a feature branch, never git add -A, and make
each logical change a separate commit (e.g. one commit for formatting,
one for linter fixes, one for README, one for each new repo file, etc.)."
Code style and conventions:
claude "Read $TD/prompts/CODE_STYLEGUIDE.md and whichever
language-specific styleguides in $TD/prompts/ apply to this repo
(CODE_STYLEGUIDE_GO.md, CODE_STYLEGUIDE_JS.md, CODE_STYLEGUIDE_PYTHON.md,
GO_HTTP_SERVER_CONVENTIONS.md). Then review the application code in this
repo and bring it into compliance with those coding standards. Your scope
is application code structure and style: naming, patterns, error
handling, project layout, and conventions described in the styleguides.
Do not modify repo scaffolding (Makefile, Dockerfile, CI workflow,
.gitignore, .editorconfig, etc.) — only application code. Work on a
feature branch, never git add -A, and make each logical change a
separate commit."
Getting Started
git clone https://git.eeqj.de/sneak/prompts.git
cd prompts
Prompts are stored as Markdown files in prompts/. Copy or reference them as
needed in your projects.
Entrypoints
This repository adheres to the
Scripts to Rule Them All
standard: normalized scripts in script/ are the entrypoints for the
development workflow, and the Makefile targets are thin shims that call them.
The scripts are POSIX sh (not bash) so they run in minimal containers such as
alpine. We provide:
script/bootstrap— install all dependencies (yarn install)script/setup— set up the repo for development after a fresh clone: runsscript/bootstrap, thenscript/install-precommitscript/projectname— output the project name (our own extension); used byscript/dockerfor the image tagscript/test— run the test suite (no tests defined here)script/lint— lint the markdown files with prettierscript/fmt— format all markdown files with prettier (writes)script/fmt-check— check formatting (read-only)script/check— run all checks:test,lint,fmt-check(our own extension)script/docker— build the Docker image, tagged viascript/projectname(byte-identical across repos); passes the sameCHECK_EPOCHnonce asscript/cibuildscript/cibuild— cd to the repo root, assignepoch="$(date +%s%N)$$", thendocker build --build-arg CHECK_EPOCH="$epoch" .(what CI runs; the image build runsscript/check, and the per-invocationCHECK_EPOCHnonce is what stops Docker serving that check from cache on an unchanged tree — a baredocker build .fails closed on purpose)script/precommit— run by the git pre-commit hook (our own extension); callsscript/checkscript/install-precommit— installs the git pre-commit hook (our own extension);make hooksshims to it
make hooks installs the pre-commit hook that runs script/precommit.
Rationale
LLM prompts, especially development policies, benefit from version control and a single authoritative source. This repo provides a central place to maintain, share, and evolve prompts across projects.
Design
The repository is a collection of Markdown files organized in the prompts/
subdirectory. Each file contains one or more related prompts or policy
documents. There is no build step or runtime component; the prompts are consumed
by copying them into other projects or referencing them directly.
Template Repos
These template repositories implement the policies defined in this repo and serve as starting points for new projects. They must be kept in sync when policies change.
- template-app-go — Go HTTP server template (Uber fx, chi, SQLite, session auth, Prometheus metrics)
- template-app-js — JavaScript SPA template (Vite, Tailwind CSS v4, nginx Docker deployment)
- template-app-python — Python web application template (FastAPI, uvicorn, pytest, black, ruff)
When updating policies in this repo, also update the template repos to match (Makefile targets, Dockerfile conventions, CI workflows, required files, etc.).
See Also
- clawpub — Real-world examples, rationale, and operational lessons from applying these policies with an OpenClaw AI agent. Includes detailed documentation on how the interlocking check system (CI → Docker → Makefile → tests/lint/fmt) works in practice, why checklists complement prose policies, and failure stories from production use.
TODO
- Add more prompt templates for common development tasks
License
MIT. See LICENSE.