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".
Allowed Tools
Provided by Plugin
tonone
Engineering + Product + Operations + Legal + Design + Data Science + Security Operations + Developer Experience + Infrastructure Specialist + AI Operations team — 100 agents as Claude Code specialists. Infrastructure, DevOps, backend, security, ML/AI, mobile, UX, analytics, growth, revenue, content, PR, customer success, finance, people, operations, support, contracts, compliance, IP, governance, regulatory, color systems, typography, motion, accessibility, design tokens, forecasting, feature engineering, model training, drift monitoring, vector search, LLM fine-tuning, pen testing, detection engineering, incident response, zero trust, API docs, SDK design, developer onboarding, Kubernetes, Terraform, FinOps, service mesh, edge computing, caching, queuing, multi-cloud, chaos engineering, model deployment, LLM evaluation, AI observability, guardrails, prompt engineering, embeddings, ranking, and more.
Installation
This skill is included in the tonone plugin:
/plugin install tonone@claude-code-plugins-plus
Click to copy
Instructions
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
.envfiles committed. - Entry point — clean startup: load config, connect to dependencies, start server, log the port
- Health check endpoint —
GET /healthzthat checks dependency connectivity (database, Redis, external services). Return200when healthy,503when 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.logorprintstatements. - 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.ymlfor local development with backing services.gitignoreappropriate for the language- Basic
Makefileor equivalent with:dev,build,test,lintcommands
Step 5: Present the Service
Show the generated project structure and explain:
- How to run locally (
make devor 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.