How do I install the Backend Service skill?

Run npx skillmds@latest add tmj-90/backend-service in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Backend Service safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Backend Service?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Backend Service free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Backend Service?

tmj-90 (@tmj-90) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Backend Service by tmj-90 — Agent Skill

Name: Backend Service
Author: tmj-90

Backend Service

Use when a ticket asks for backend business logic that isn't itself an endpoint or a migration — a service/use-case, a domain operation, a background job, or orchestration across repositories. Invoke for "add a service to do X", "implement the use-case", or "extract the business logic out of the handler".

tmj-90 7ddc8d9 2.5 KB Updated Sep 17, 2026

File contents

Add a backend service

Implement domain logic as a focused, testable service that keeps transport (HTTP) and persistence (DB) concerns at the edges, following the repo's layering.

Steps

Read the lore first. Call search_lore (Memory MCP) for the repo's layering (controller → service → repository), error model, transaction handling, and dependency-injection conventions. Honour any ADRs.
Find a sibling service and copy its shape — constructor/factory, injected collaborators, return/error types, and where it lives.
Keep the service transport-agnostic. It receives validated inputs and returns domain results or typed errors — no HTTP request/response objects, no SQL strings.
Depend on abstractions. Take repositories/clients via interfaces so the logic is unit-testable with fakes; favour immutable inputs and outputs.
Handle failure explicitly. Map domain failures to typed errors/results; never swallow exceptions or return ambiguous nulls.
Test the logic in isolation. Unit-test happy path, branches, and error cases with collaborators faked; add an integration test if it crosses real boundaries.
Verify + evidence. Run tests and lint, then record test_output via the record-evidence skill and submit for review.

Rules

One responsibility per service; keep methods small and the file cohesive.
No transport or storage details leaking into the service layer.
Immutable inputs/outputs; explicit error handling, no silent failures.
Pair with add-api-endpoint for the HTTP edge and add-db-migration for schema.

Capture lore

This skill is one of the places durable, reusable knowledge naturally surfaces: A service-layer convention or stack rule this repo follows — error-handling shape, transaction boundary, dependency-injection pattern, or a framework gotcha. That kind of fact is lore. Capture it via the lore-capture protocol in your brief (CLAUDE.factory.md, step 11 "Memory contribution"): call the Memory MCP suggest_lore once at the close of your work — reusable conventions, gotchas, decisions, and boundaries only, never per-ticket trivia.

---name: backend-servicedescription: Use when a ticket asks for backend business logic that isn't itself an endpoint or a migration — a service/use-case, a domain operation, a background job, or orchestration across repositories. Invoke for "add a service to do X", "implement the use-case", or "extract the business logic out of the handler".---# Add a backend serviceImplement domain logic as a focused, testable service that keeps transport (HTTP)and persistence (DB) concerns at the edges, following the repo's layering.## Steps1. **Read the lore first.** Call `search_lore` (Memory MCP) for the repo's layering (controller → service → repository), error model, transaction handling, and dependency-injection conventions. Honour any ADRs.2. **Find a sibling service** and copy its shape — constructor/factory, injected collaborators, return/error types, and where it lives.3. **Keep the service transport-agnostic.** It receives validated inputs and returns domain results or typed errors — no HTTP request/response objects, no SQL strings.4. **Depend on abstractions.** Take repositories/clients via interfaces so the logic is unit-testable with fakes; favour immutable inputs and outputs.5. **Handle failure explicitly.** Map domain failures to typed errors/results; never swallow exceptions or return ambiguous nulls.6. **Test the logic in isolation.** Unit-test happy path, branches, and error cases with collaborators faked; add an integration test if it crosses real boundaries.7. **Verify + evidence.** Run tests and lint, then record `test_output` via the `record-evidence` skill and submit for review.## Rules- One responsibility per service; keep methods small and the file cohesive.- No transport or storage details leaking into the service layer.- Immutable inputs/outputs; explicit error handling, no silent failures.- Pair with `add-api-endpoint` for the HTTP edge and `add-db-migration` for schema.## Capture loreThis skill is one of the places durable, reusable knowledge naturally surfaces:**A service-layer convention or stack rule this repo follows — error-handling shape, transaction boundary, dependency-injection pattern, or a framework gotcha.** That kind of fact is *lore*. Capture it via the **lore-captureprotocol in your brief** (`CLAUDE.factory.md`, step 11 "Memory contribution"):call the Memory MCP `suggest_lore` once at the close of your work — reusableconventions, gotchas, decisions, and boundaries only, never per-ticket trivia.

Frequently asked questions