Noah's global Agent instructions #

The simple-english skill should always be used for text that is intended to be ready by a human. This includes, but is not limited to, commit messages, code comments, documentation in markdown files, task descriptions.

Always do an adversarial review of any code changes across the following dimension:

• security, taking into account context and security/risk profile (ask if this is of significant condern)
• correctness, does the code or change reflect the intent
• simplicity and architectural correctness, is the change cutting corners to achieve the goal at the expense of existing fucntionality, cleanliness, readability, correctness, or testability

Most applications should follow a 'functional core, imperative shell' layout to make testing simple and inject IO to allow for simulation. Code should be grouped into modules that are focused and self contained to the best extent possible. The majority of functionality should be in library-like modules that could be pulled out if needed (but should not unless explicitly asked).

When working on larger tasks, it is typically preferrable to use the tsk utility when working in a git repository to track these. Task descriptions should include all context necessary for an agent or subagent to perform the task.

Do not introduce functionality that is not asked for. If a technical decision that requires a new feature, construct, architecture component, etc. must be made, ask the developer for direction. Never introduce a dependency on an external entity such as a service, package, container, or library without explicit permission on a case-by-case basis, but do favor asking permission when such dependency would dramatically reduce code footprint.

When writing tests, do not write tests overly tied to implementation. Cover side effects, edge cases, and failure modes focusing on happy path and error hanlding. Do NOT overindex on a particular implementation or fill a codebase with useless tests.

Do not push code unless given explicit permission to do so. Permission can be on a ongoing basis for highly autonomous work or on a case-by-case basis. Never violate this rule.

Favor short, succinct text over sprawling digressing text. Less is more. When describing the functionality of code, describe the abstraction, not what the code literally does unless there is a particularly weird behavior.