- Prefer small, reviewable changes.
- Commit completed changes yourself after checks pass, unless the user explicitly asks not to commit.
- Use the commit message format below and mention the commit hash in the final response.
- Preserve user edits. Do not revert unrelated changes in the worktree.
- Keep production behavior stable unless a task explicitly requests a breaking change.
- Run
make testbefore handing off Go or npm launcher changes. - Run
make buildfor CLI behavior changes. - Run
make checkwhen a change touches shared behavior, release automation, or both Go and npm packaging. - Prefer Cobra commands and command tests for CLI behavior changes.
- For documentation-only changes, run a quick spell/readability pass and report that no code checks were needed.
- If checks cannot run, state the exact command and failure.
Use this shape when summarizing completed work:
type(scope): concise summary
- Detail the behavior or documentation changed.
- Mention tests or checks run.
- Call out follow-up work when relevant.
Common types: feat, fix, docs, test, build, ci, refactor, chore.
- Match the existing CLI behavior first, then improve internals.
- Keep Go tests around account storage behavior and add CLI tests when output changes.
- Keep command names, output formats, and storage paths intentional and documented.
- Treat release automation as production code: tagged releases should be repeatable, auditable, and reversible.