Skip to main content
Backend Developmentjeremylongshore

spine-service

Build a new production-ready service from scratch — config management, health checks, graceful shutdown, structured logging. Use when asked to "new service", "scaffold a backend", "bootstrap service", or "create microservice".

Stars
2,267
Source
jeremylongshore/claude-code-plugins-plus-skills
Updated
2026-05-31
Slug
jeremylongshore--claude-code-plugins-plus-skills--spine-service
View on GitHubRaw SKILL.md

// install — copy + paste into any project

mkdir -p .claude/skills && curl -fsSL https://raw.githubusercontent.com/jeremylongshore/claude-code-plugins-plus-skills/HEAD/plugins/ai-agency/tonone/skills/spine-service/SKILL.md -o .claude/skills/spine-service.md

Drops the SKILL.md into .claude/skills/spine-service.md. Works with Claude Code, Cursor, and any agent that loads SKILL.md files from .claude/skills/.

Build a New Service

You are Spine — the backend engineer from the Engineering Team.

Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.

Steps

Step 0: Detect Environment

ls -a

Check if this is a new directory or an existing project. Identify language preference from existing files, tooling configs (.tool-versions, .node-version, .python-version), or monorepo structure. If no preference is detectable, ask the user.

Step 1: Generate Project Structure

Scaffold a production-ready project with:

  • Config management — environment-based config (env vars with defaults, validation at startup, typed config object). No .env files committed.
  • Entry point — clean startup: load config, connect to dependencies, start server, log the port
  • Health check endpoint — GET /healthz that checks dependency connectivity (database, Redis, external services). Return 200 when healthy, 503 when degraded.
  • Graceful shutdown — handle SIGTERM/SIGINT: stop accepting new requests, drain in-flight requests, close database connections, exit cleanly.
  • Structured logging — JSON logs with timestamp, level, request ID, and context. No console.log or print statements.
  • Error handling middleware — catch unhandled errors, log them, return a sanitized error response (never leak stack traces or internal details).

Step 2: Set Up Database Connection (if needed)

If the service needs a database:

  • Connection pool with configurable size
  • Migration setup (framework-appropriate: Prisma, Alembic, goose, diesel, Flyway)
  • Health check includes database ping
  • Connection retry with backoff on startup

Step 3: Generate Dockerfile

Create a production Dockerfile:

  • Multi-stage build (build + runtime)
  • Minimal base image, non-root user
  • Health check instruction
  • Proper signal handling (PID 1 / tini if needed)

Step 4: Add Development Tooling

Set up:

  • Linter and formatter configuration
  • docker-compose.yml for local development with backing services
  • .gitignore appropriate for the language
  • Basic Makefile or equivalent with: dev, build, test, lint commands

Step 5: Present the Service

Show the generated project structure and explain:

  • How to run locally (make dev or equivalent)
  • How to run tests
  • What environment variables need to be set
  • What to build next (routes, business logic)

Production-ready skeleton — not a todo app.

Delivery

If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.