sneak
12e8db8b0e
All checks were successful
check / check (push) Successful in 29s
The linter is no longer installed on the host and no longer invoked there. script/lint is now `docker build -f Dockerfile.lint .` and nothing else, with the linter running as a build step, so a successful build of that file is a clean lint — and it works unchanged where the docker daemon is remote and bind mounts are impossible. That removes three host-only failure mechanisms rather than mitigating them: the result cache keyed on file content rather than location, which produced a confirmed false green and a string of findings reported against other checkouts; the host-global $TMPDIR/golangci-lint.lock, which fails a run with `parallel golangci-lint is running` in a way no caller can distinguish from findings; and host/container version skew, which hid thirteen findings on one repo. A container per run has its own cache, its own lock and a binary pinned by digest. Resolving the recursion this creates. script/lint is a docker build, so a Dockerfile that runs `make check` would nest a build inside a build step where there is no daemon. Fixed by direction, not detection: the main Dockerfile runs script/test and script/fmt-check individually, with a comment saying why `make check` must not come back, and script/cibuild runs script/lint first for fail-fast feedback. script/check still runs all three, so developers and the pre-commit hook are unaffected. Dockerfile.lint carries the same CHECK_EPOCH guard as the main image, with the ARG placed below the dependency layer so only the lint steps re-run. Blanket --no-cache was rejected: it re-runs the dependency install on every lint and makes linting network-dependent. golangci-lint config verify is kept, on measurement rather than preference. Under the pinned v2.12.2, a bogus top-level key and a bogus key nested under linters.settings.lll both pass `golangci-lint run` with exit 0 and `0 issues` while config verify exits 3 and names them; an unknown linter name fails run and passes config verify. The two catch disjoint classes, and `run` alone silently ignores the class where a threshold reads as configured and is not applied. The concern that config verify fetches its JSON schema over live HTTPS does not hold for this version: every case reproduced byte-identically under `docker run --network none`, in a container where `getent hosts golangci-lint.run` exits 2. The schema is embedded in the pinned binary. Two canonical forms are superseded and deleted rather than left standing beside the new one, because consuming repos read these documents literally and two contradictory canonical script/lint forms is worse than either. The script/bootstrap golangci-lint install landed for #28 is removed: nothing invokes a host linter now, so it can only reintroduce the skew it was written to close. Its version-enforcement principle — compare version not presence, re-resolve through PATH after installing, let a mis-parse fall through to reinstall, and call it — stays documented for any other pinned host tool. The per-checkout GOLANGCI_LINT_CACHE/TMPDIR wrapper is removed with it; its entire subject was making a host run trustworthy. Adopting repos delete .lint-cache/ from .gitignore and .dockerignore too. The Go multistage lint stage and its COPY --from=lint ordering trick go the same way: that stage ran `make lint`, which is now a docker build. Corrected everywhere the claim that a successful docker build implies lint passed — REPO_POLICIES.md, both repo checklists, the Go styleguide and the README. The guarantee now belongs to script/cibuild, which runs both container builds; a bare `docker build .` never lints at all. Verified in this repo, not only documented: two consecutive script/lint runs on a byte-identical tree both executed prettier (4.556s and 3.738s, lint layers DONE with a fresh epoch printed, dependency layers CACHED as intended); a planted violation failed the build naming the file, and reverting it went green; a bare `docker build -f Dockerfile.lint .` failed on the guard; make check, script/docker and script/cibuild all green with the check layers demonstrably executing; and the main image build completed without attempting a nested build.
195 lines
8.1 KiB
Markdown
195 lines
8.1 KiB
Markdown
# prompts
|
|
|
|
prompts is an MIT-licensed collection of LLM prompts by
|
|
[@sneak](https://sneak.berlin), 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.
|
|
|
|
```bash
|
|
export TD="$(mktemp -d)"
|
|
git clone --depth 1 https://git.eeqj.de/sneak/prompts.git "$TD"
|
|
```
|
|
|
|
**Repository structure and policies:**
|
|
|
|
```bash
|
|
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:**
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
export TD="$(mktemp -d)"
|
|
git clone --depth 1 https://git.eeqj.de/sneak/prompts.git "$TD"
|
|
```
|
|
|
|
**Repository scaffolding:**
|
|
|
|
```bash
|
|
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:**
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
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](https://github.com/github/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: runs
|
|
`script/bootstrap`, then `script/install-precommit`
|
|
- `script/projectname` — output the project name (our own extension); used by
|
|
`script/docker` for the image tag
|
|
- `script/test` — run the test suite (no tests defined here)
|
|
- `script/lint` — lint the markdown files, by building `Dockerfile.lint`. The
|
|
linter runs in a container, always: it is never installed on the host and
|
|
never invoked there. Linting happens as a build step, so a successful build is
|
|
a clean lint, and the same per-invocation `CHECK_EPOCH` nonce used elsewhere
|
|
is what stops Docker serving that lint from cache on an unchanged tree
|
|
- `script/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). Needs a docker daemon, since `script/lint` is a container build
|
|
- `script/docker` — build the Docker image, tagged via `script/projectname`
|
|
(byte-identical across repos); passes the same `CHECK_EPOCH` nonce as
|
|
`script/cibuild`
|
|
- `script/cibuild` — cd to the repo root, run `script/lint` first, then assign
|
|
`epoch="$(date +%s%N)$$"` and
|
|
`docker build --build-arg CHECK_EPOCH="$epoch" .` (what CI runs). Two
|
|
container builds: the lint image, then the main image, which runs
|
|
`script/test` and `script/fmt-check` but deliberately not `make check` — that
|
|
would nest a docker build inside a build step. A bare `docker build .` fails
|
|
closed on purpose
|
|
- `script/precommit` — run by the git pre-commit hook (our own extension); calls
|
|
`script/check`
|
|
- `script/install-precommit` — installs the git pre-commit hook (our own
|
|
extension); `make hooks` shims 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](https://git.eeqj.de/sneak/template-app-go)** — Go HTTP
|
|
server template (Uber fx, chi, SQLite, session auth, Prometheus metrics)
|
|
- **[template-app-js](https://git.eeqj.de/sneak/template-app-js)** — JavaScript
|
|
SPA template (Vite, Tailwind CSS v4, nginx Docker deployment)
|
|
- **[template-app-python](https://git.eeqj.de/sneak/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](https://git.eeqj.de/sneak/clawpub)** — Real-world examples,
|
|
rationale, and operational lessons from applying these policies with an
|
|
[OpenClaw](https://github.com/openclaw/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](LICENSE).
|
|
|
|
## Author
|
|
|
|
[@sneak](https://sneak.berlin)
|