Spine service

Skill jeremylongshore/claude-code-plugins-plus-skills/plugins/ai-agency/tonone/skills/spine-service

425 plugins, 2,810 skills, 200 agents for Claude Code. Open-source marketplace at tonsofskills.com with the ccpi CLI package manager.

Install

npx -y skills add jeremylongshore/claude-code-plugins-plus-skills --skill spine-service

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

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".

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.2 KB, as published. Nobody here has run it

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.