sneak
94b0a831a2
check / check (push) Failing after 3s
script/fmt and script/fmt-check follow the model scripts in the prompts repo: Go as before, plus prettier over every markdown file with 4-space tabs and proseWrap always. Prettier is pinned by hash in package.json and yarn.lock; script/bootstrap now installs node, yarn and prettier. The Dockerfile lint stage copies node and yarn from a node image pinned by hash and runs script/bootstrap, so its make fmt-check fails the build on unformatted markdown. Every markdown file is formatted once; wording is unchanged (CLAUDE.md's "*" list markers become "-"). Model: opus-5-5
94 lines
4.8 KiB
Markdown
94 lines
4.8 KiB
Markdown
# IMPORTANT RULES
|
|
|
|
- Claude is an inanimate tool. The spam that Claude attempts to insert into
|
|
commit messages (which it erroneously refers to as "attribution") is not
|
|
attribution, as I am the sole author of code created using Claude. It is
|
|
corporate advertising for Anthropic and is therefore completely unacceptable
|
|
in commit messages.
|
|
|
|
- Tests should always be run before committing code. No commits should be made
|
|
that do not pass tests.
|
|
|
|
- Code should always be formatted before committing. Do not commit unformatted
|
|
code.
|
|
|
|
- Code should always be linted and linter errors fixed before committing. NEVER
|
|
commit code that does not pass the linter. DO NOT modify the linter config
|
|
unless specifically instructed.
|
|
|
|
- The test suite is fast and local. When running tests, NEVER run individual
|
|
parts of the test suite, always run the whole thing by running "make test".
|
|
|
|
- Do not stop working on a task until you have reached the definition of done
|
|
provided to you in the initial instruction. Don't do part or most of the work,
|
|
do all of the work until the criteria for done are met.
|
|
|
|
- When you complete each task, if the tests are passing and the code is
|
|
formatted and there are no linter errors, always commit and push your work.
|
|
Use a good commit message and don't mention any author or co-author
|
|
attribution.
|
|
|
|
- Do not create additional files in the root directory of the project without
|
|
asking permission first. Configuration files, documentation, and build files
|
|
are acceptable in the root, but source code and other files should be
|
|
organized in appropriate subdirectories.
|
|
|
|
- Do not use bare strings or numbers in code, especially if they appear anywhere
|
|
more than once. Always define a constant (usually at the top of the file) and
|
|
give it a descriptive name, then use that constant in the code instead of the
|
|
bare string or number.
|
|
|
|
- If you are fixing a bug, write a test first that reproduces the bug and fails,
|
|
and then fix the bug in the code, using the test to verify that the fix
|
|
worked.
|
|
|
|
- When implementing new features, be aware of potential side-effects (such as
|
|
state files on disk, data in the database, etc.) and ensure that it is
|
|
possible to mock or stub these side-effects in tests when designing an API.
|
|
|
|
- When dealing with dates and times or timestamps, always use, display, and
|
|
store UTC. Set the local timezone to UTC on startup. If the user needs to see
|
|
the time in a different timezone, store the user's timezone in a separate
|
|
field and convert the UTC time to the user's timezone when displaying it. For
|
|
internal use and internal applications and administrative purposes, always
|
|
display UTC.
|
|
|
|
- When implementing programs, put the main.go in ./cmd/<program_name>/main.go
|
|
and put the program's code in ./internal/<program_name>/. This allows for
|
|
multiple programs to be implemented in the same repository without cluttering
|
|
the root directory. main.go should simply import and call
|
|
<program_name>.CLIEntry(). The full implementation should be in
|
|
./internal/<program_name>/.
|
|
|
|
- When you are instructed to make the tests pass, DO NOT delete tests, skip
|
|
tests, or change the tests specifically to make them pass (unless there is a
|
|
bug in the test). This is cheating, and it is bad. You should only be
|
|
modifying the test if it is incorrect or if the test is no longer relevant. In
|
|
almost all cases, you should be fixing the code that is being tested, or
|
|
updating the tests to match a refactored implementation.
|
|
|
|
- Always write a `Makefile` with the default target being `test`, and with a
|
|
`fmt` target that formats the code. The `test` target should run all tests in
|
|
the project, and the `fmt` target should format the code. `test` should also
|
|
have a prerequisite target `lint` that should run any linters that are
|
|
configured for the project.
|
|
|
|
- After each completed bugfix or feature, the code must be committed. Do all of
|
|
the pre-commit checks (test, lint, fmt) before committing, of course. After
|
|
each commit, push to the remote.
|
|
|
|
- Always write tests, even if they are extremely simple and just check for
|
|
correct syntax (ability to compile/import). If you are writing a new feature,
|
|
write a test for it. You don't need to target complete coverage, but you
|
|
should at least test any new functionality you add.
|
|
|
|
- Always use structured logging. Log any relevant state/context with the
|
|
messages (but do not log secrets). If stdout is not a terminal, output the
|
|
structured logs in jsonl format. Use go's log/slog.
|
|
|
|
- You do not need to summarize your changes in the chat after making them.
|
|
Making the changes and committing them is sufficient. If anything out of the
|
|
ordinary happened, please explain it, but in the normal case where you found
|
|
and fixed the bug, or implemented the feature, there is no need for the
|
|
end-of-change summary.
|