Instructions to llm agents

Documentation

Read design.md to get an overview of huxtable's architecture. Read agent-notes.md to read the notes of previous llms.

Writing code, tests and docs

Use short branch names. Start with "feature", "bugfix", "refactor" or "chore".

Don't change the API without asking first.

If you find a user-visible bug, then consider writing a test for it. Title the test "Bugfix: ..." and put it in the most relevant existing test file. Then use it to confirm you've fixed the bug.

If you write a new function, give it Roxygen documentation. If it's internal, use the `@noRd` tag, and keep it simple and developer-focused. Similarly, if you edit an existing internal function, take the chance to document it.

If you understand more about the architecture of huxtable, update `design.md`. For more general notes that might be useful to you or future llms working on the project, write in `agent-notes.md`. Don't forget to add any suggested changes to the PR.

If you've written user-visible Roxygen, run `devtools::document()`. You can ignore errors due to missing packages ("flextable", "lmtest") unless you're working on those particular parts of the system. If you are, then just install the missing packages.

Testing your work

At the end of any task, if you've made changes, run the tests in tests/testthat to make sure everything is still working. If there are errors due to your code, fix them before completing. You don't have to run every test; in particular those in test-yy-end-to-end.R and test-zz-fuzz.R may take a long time so you may want to skip those, or even just run a single test file if you're confident. (Github will run a full suite of tests later.) But if you make big architectural changes, run all or almost all tests. You can filter out fuzz tests using: `devtools::test(filter = "^(?!.*fuzz)", perl = TRUE)`.

Installing extra components

You can install quarto, typst, or latex by running the ./install-*.sh files in your home directory. They are not installed automatically to save setup time. Install them if you need to test the relevant features.

typst documentation is available in easy-to-read format on https://github.com/typst/typst/tree/main/docs. It may be useful to clone the repository into /workspace.

Not all packages in Suggests: in the DESCRIPTION file are installed. You can install them if you need to. But, if tests break because a suggested package is not installed, then that is a bug and you should probably fix it by using `skip_if_not_installed()` - in a separate PR if possible.

If you need to install big, well-known packages like dplyr, try to install them via `apt-get --no-install-recommends install r-cran-dplyr` before using `install.packages()` from R.

If you want to build vignettes, you'll need the R.rsp package. Alternatively, don't build vignettes when you build the package, by passing the `--no-build-vignettes` flag to `devtools::build()`.

Documenting your work

If you make important user-visible changes, add an item to NEWS.md. Follow the formatting of the existing entries. Run `devtools::document()` afterwards, because the news is copied into the help file `?huxtable-news`.

* Do not update NEWS.md for unimportant changes, like tweaks to documentation. * Do not update NEWS.md for bugfixes to a feature that has been introduced in the same release. i.e. don't mention bugfixes unless the bug was already visible to users of a previous version of the package.