Focused code changes

Clean Changes

Scope

• Do the task and only the task. Re-read the request before finishing and remove anything it did not ask for.
• No drive-by refactors, renames, file moves, reformatting or comment rewrites in code you did not need to touch.
• If you spot an unrelated problem, mention it in your report instead of fixing it.
• Make the smallest change that solves the problem completely: update the callers, types, docs and tests it affects.

Follow the repository

• Read neighboring code first and copy its patterns: structure, naming, error handling, logging, imports, file layout, test style.
• Reuse existing helpers, components and utilities. Search before creating something new.
• Respect the formatter and linter config already present (Prettier, ESLint, EditorConfig, PHPCS, Black). Format only what you changed when the tool allows it.
• Stay within the language and framework versions the repo targets.
• Follow repository instruction files (README, CONTRIBUTING, AGENTS.md, CLAUDE.md) when present.

Dependencies

• Do not add a dependency for something the standard library or an existing dependency already does.
• When one is truly needed, add it with the repo's package manager so the lockfile updates, and state why in your report.
• Never upgrade or downgrade unrelated packages.

Code quality

• Clear names, small functions, no dead or commented-out code, no leftover debug output.
• Comments explain why, not what. No noise comments or banners.
• No TODO without context; do not silently leave work unfinished.
• Keep public APIs, config keys, schemas and file formats backward compatible unless the task says otherwise.
• Do not hand-edit generated files, vendored code or lockfiles.

Keep it green

• Run the repo's build, lint, typecheck and tests for what you changed, using the scripts it defines.
• Fix warnings and errors you introduced. Do not disable rules, add ignores or loosen config to pass.
• Leave no temporary files, local config or secrets behind.

Commit-sized units

• Shape the work so each logical change could be one reviewable commit with a message stating what and why.
• Keep mechanical changes (renames, moves) separate from behavior changes when both are needed.

Before you finish

• The diff contains only what the task needs; no unrelated edits.
• New code matches surrounding conventions and reuses existing helpers.
• No new dependency without a stated reason.
• Build, lint, typecheck and tests ran and pass, or failures are reported.
• No debug output, dead code or stray files left behind.