Claude

claude.md

Style

• Don't use too many comments unless there is something non-obvious going on.
• In general, use DTOs over arrays of data when consuming data from APIs. Saloon has first-party support for casting responses to DTOs, if you need help understanding it, check their documentation.
• When implementing DTOs, use the simplest approach that works - plain PHP objects are often sufficient.
• Follow existing code formatting and naming conventions in the project.
• Check if the project has a code formatter/linter and use it before submitting changes.

Acceptance criteria

• If you are building a new feature or refactoring, be absolutely certain to run the tests before telling me you are done.
• When the tests relating to your feature are passing, make sure to also run the entire test suite to ensure you didn't break other tests.
• It's usually a good idea to run the whole test suite FIRST to make sure you know if you introduced new bugs if there are failing tests at the end.
• If you receive the following error: "Illuminate\Foundation\ViteException: Unable to locate file in Vite manifest", run npm run build. If that doesn't work, ensure npm dependencies are installed with npm install.
• Verify library namespaces by examining actual source files before making changes.
• When adding new dependencies, ensure they're compatible with the existing project and properly documented.
• Write tests for new functionality and ensure they pass along with existing tests.

Token saving strategies

• We are stingy. We don't want to use too many tokens.
• Group any new tests that you add and run the group to save on tokens.
• ALWAYS run the tests in parallel. The output from parallel test runs is much more succinct as it doesn't include test names on successes.
• ALWAYS run tests with --stop-on-failure and --stop-on-error to save on tokens.
• NEVER assume that just because a few focused tests are passing, that you are off the hook for other failing tests. Our test suite must always be in a 100% passing state at the end of a feature development. If your code broke unrelated tests, that is your problem to fix. If you want help deciding how to fix those, you should ask instead of assuming.
• Be concise in your explanations - focus on what's important rather than explaining obvious details.
• When running commands, use focused commands that return just the information needed.

Procedure

When asked to do a task, try to determine if it's a minor task or a substantial task.

Minor tasks: Involve changes to 1-2 files, don't introduce new dependencies, and have a well-defined scope. Substantial tasks: Involve multiple files, architecture changes, new dependencies, or significant refactoring.

For minor tasks (that involve a few small edits to one or two files), just go ahead and do them.

For substantial tasks:

1. Do any research you need to do to understand what you need to do.
   • Examine actual code and dependencies before assuming library usage patterns
   • Use commands like find and head to verify namespace structures
   • Make small targeted verifications before broad changes
   • Read package documentation when working with external libraries
2. Come up with a sequence of changes you want to make, and describe them in a simple numbered list.
3. Ask me to approve your approach, or offer feedback.
4. If I give feedback, rework your plan.
5. Repeat until I approve your plan.
6. Execute your plan incrementally, verifying each step works before proceeding.
7. Follow explicit instructions precisely - if told to run a specific command, do so immediately.
8. When encountering errors, diagnose the root cause rather than applying superficial fixes.
9. After completing the task, verify your work with appropriate tests.