backend-expert

Backend Expert

Write code like a backend expert with years of development experience:Conciseness first, one path. By default assume the project already has an HTTP framework, client, middleware, storage access, and related Agent Skills—reuse first, then act. Language syntax and version features are left to skills/langs/, this skill does not cover them.

For positive and negative examples and typical garbage patterns, see references/(open the corresponding file as needed, do not blindly read the whole folder).

Priority

1. Explicit user requirements > this skill (for example, the user explicitly asks for compatibility with an old interface, or for a complete authentication middleware).
2. When the user has not requested it, follow the hard rules below.

Hard Rules

1. Consistent field names → field-by-field copying prohibited When handler DTO / domain object / storage model fields are consistent, batch alignment is mandatory (use the project's existing mapper / copy / constructor). Prohibit dst.A = src.A style field-by-field assignment; prohibit copying another set of create body and another set of update body because of this. Create and update usually share the same set of fields, and the difference is mostly just id(or id held separately as a path parameter and not included in the body)—see references/dto-mapping.md。

2. Not named → adding on the side is prohibited If the user has not requested it, prohibit: complete authentication middleware shells, generic repository interfaces, pagination frameworks, outbox, feature flag shells, "future extension points", and redundant comments.

1. Search before writing (must have evidence) Before adding a client, middleware, abstraction, or dependency, you must first search: existing project client / middleware → installed dependencies → existing Agent Skill. If it cannot be found and a new dependency is truly needed, ask the user first. Do not casually introduce new libraries.

2. One path Requirement changes are the norm. By default, change the caller and the implementation, and keep a single implementation; prohibit piling up compatibility code for the sake of "less breakage" (except when the user explicitly requests it).

3. After changes, always subtract (Pass B)

   • Pass A: minimal implementation
   • Pass B: delete unused code, dead code, unreferenced DTOs/routes/middleware; merge duplicates; remove unrequested capabilities Pass B must be completed before finishing; be able to point out what was deleted, or clearly state "nothing to delete".

4. Structure follows the project's existing layering/framework Write it the way the project splits handler / service / store. Prohibit adding another forwarding-only layer for the sake of "clean architecture". If a layer contains nothing except return next() → delete the layer, see references/pass-through-layers.md。

5. Write less when possible Prohibit multiple parallel implementations of the same semantics. Only extract common code when real duplication is ≥3 places or the user explicitly requests it; prohibit premature abstraction and excessive defensiveness.

Mandatory Workflow

• Search existing: client / middleware / dependency / Skill (when adding capabilities)
• Pass A: minimal implementation (one path)
• Pass B: delete leftovers, remove unrequested capabilities
• If the project has lint/typecheck/test: run them on the files related to the changes; if unused does not pass, it is not complete

Reference Materials

Topic	File
DTO field-by-field bloat	references/dto-mapping.md
Dead code and leftovers	references/dead-code.md
Over-engineering and over-defensiveness	references/over-engineering.md
Compatibility pile-up	references/compatibility.md
Reinventing the wheel and adding dependencies recklessly	references/reinvent-wheel.md
Layers that only forward	references/pass-through-layers.md