sneak 51ee510ed8
All checks were successful
check / check (push) Successful in 23s
Gate the build on Docker lint and test phases (closes #40, closes #30)
Per the owner ruling on issue 40, linting and testing are phases of the
main Dockerfile rather than a separate lint file. script/lint and
script/test build one phase each by name with caching disabled, and the
final stage copies a harmless file from each so the image cannot be built
unless both passed. A stage that is not the last is built only when
something depends on it or --target names it, so the gates are invoked by
name and the edges kept. script/check runs the gates and builds no image
of its own; script/cibuild bootstraps first, because CI runs it alone and
fmt-check is native. fmt and fmt-check source nvm for the pinned node
before calling yarn, which bootstrap installs but leaves off its caller's
PATH. Every build in script/ is tagged and uncached. Issue 30 closes too:
a container has its own lint cache and lock.

Model: opus-5
2026-09-08 05:55:15 +00:00

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: 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/testdocker build --no-cache --target test -t prompts-test ., building the test phase of the Dockerfile (no tests defined here)
  • script/lintdocker build --no-cache --target lint -t prompts-lint ., building the lint phase, which runs prettier over the markdown files
  • script/fmt — format all markdown files with prettier (writes; native, not in a container)
  • script/fmt-check — check formatting (read-only; native)
  • script/check — run all checks: test, lint, fmt-check (our own extension); builds no image of its own
  • script/dockerdocker build --no-cache --build-arg VERSION="$version" -t prompts ., the tag coming from script/projectname (byte-identical across repos)
  • script/cibuild — cd to the repo root, run script/bootstrap, run script/check, compute version from git describe, then docker build --no-cache --build-arg VERSION="$version" -t prompts . (what CI runs; it bootstraps because CI checks out and runs this alone while script/fmt-check is native, and the version is computed on the host because .dockerignore excludes .git)
  • 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 — 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.

Author

@sneak

Description
No description provided
Readme MIT 2.1 MiB
Languages
Shell 83%
Dockerfile 13.5%
Makefile 3.5%