Format and check markdown with prettier in make fmt and fmt-check (closes #110)
check / check (push) Failing after 3s
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
This commit is contained in:
@@ -1,95 +1,93 @@
|
||||
# IMPORTANT RULES
|
||||
|
||||
* Claude is an inanimate tool. The spam that Claude attempts to insert into
|
||||
- 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.
|
||||
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.
|
||||
- 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 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.
|
||||
- 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".
|
||||
- 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.
|
||||
- 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
|
||||
- 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 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.
|
||||
- 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.
|
||||
- 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 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 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 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.
|
||||
- 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.
|
||||
- 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.
|
||||
- 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 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.
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
Reference in New Issue
Block a user