backend-guidancelisted

# Backend Guidance This is a composable overlay, not a standalone workflow. Use alongside the matching principle skill (for example, `coding-guidance-cpp`) when the change touches backend code. Add `project-core-dev` only when repository-specific completion checks still need to be discovered or reported. Choose the activity before applying the rules below: - for implementation, make only the requested backend changes and validate them - for review, inspect and report prioritized findings with evidence; do not edit files or require findings to be fixed unless the user also asks for remediation Use this as the thin default backend overlay for ordinary backend work. If the task includes service-boundary refactors, repository or transaction work, queue or webhook reliability, stronger testing expectations, or explicit trust-boundary hardening, prefer `backend-systems-guidance`. Routing examples: - thin route handler that delegates to existing service logic -> use this skill - small message consumer bug fix with no retry or persistence redesign -> use this skill - new endpoint with authz, repository, transaction, retry, or observability changes -> use `backend-systems-guidance` - security audit of an endpoint or tenant membership/authorization boundary -> use `security` first; add `security-identity-access` when identity, session, or tenant authorization is central, and add the backend overlay only for implementation structure ## When to use The repo has serv