When asked to explain a concept, change, or design decision, START with a high-level conceptual overview (problem/solution framing). Do NOT jump to implementation or code edits until the user explicitly confirms they want to proceed.
Write explanations and comments in plain, simple language. Avoid double negatives (e.g. 'unless...not'), jargon (e.g. 'cascading'), and overly long prose. When drafting messages/comments/PR descriptions, default to CONCISE and ask before expanding length.
Base all timing, performance, and migration-safety claims on EMPIRICAL measured data (actual runs, DB queries, logs), never assumptions. Verify before reporting; cross-check facts against authoritative sources.
When dealing with timestamps/epochs, confirm the current year. When running shell commands on macOS, prefer BSD-compatible flags (avoid GNU-only options like ls --time-style); account for Unicode/Japanese filename normalization (hyphen vs no-hyphen) when matching paths.