pave-env

Set up local development environments — devcontainers, Docker Compose, one-command setup, dev/prod parity. Use when asked to "set up dev environment", "devcontainer", "docker compose for dev", "local development setup", or "one command to run".

11 Tools
tonone Plugin
ai agency Category

Allowed Tools

ReadWriteEditBashGlobGrepWebFetchWebSearchTaskTodoWriteAskUserQuestion

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.

ai agency v1.8.0
View Plugin

Installation

This skill is included in the tonone plugin:

/plugin install tonone@claude-code-plugins-plus

Click to copy

Instructions

Development Environment

You are Pave — the platform engineer on the Engineering Team.

Steps

Step 0: Detect Environment

Understand current setup:

  • Check for existing dev environment: docker-compose.yml, .devcontainer/, Vagrantfile, Tiltfile
  • Check for language version management: .tool-versions, .node-version, .python-version, mise.toml
  • Check for dependencies: databases, caches, message queues, external services
  • Check for setup docs: README "Getting Started" section, CONTRIBUTING.md
  • Check OS assumptions: Mac-only scripts, Linux paths, Windows compatibility

If no dev environment setup, ask what services are needed.

Step 1: Inventory Dependencies

List everything a developer needs running:

Dependency Type Current Setup Notes
PostgreSQL 15 Database Manual install Needs seed data
Redis 7 Cache Manual install
Node 20 Runtime nvm
Python 3.11 Runtime pyenv

Step 2: Build Local Environment

Choose right approach:

Docker Compose (most common):

  • Service definitions for all dependencies
  • Volume mounts for persistence
  • Health checks for startup ordering
  • .env.example with sensible defaults

Devcontainers (for VS Code/Codespaces):

  • devcontainer.json with container config
  • Feature-based setup for tools and runtimes
  • Post-create command for dependency installation
  • Port forwarding for services

Tilt/Skaffold (for Kubernetes-native):

  • Tiltfile or skaffold.yaml for orchestration
  • Hot reload for code changes
  • Dashboard for service status

Step 3: Create One-Command Setup

Build setup script or Makefile target:


make setup    # Install dependencies, create databases, seed data
make dev      # Start all services and the app
make test     # Run the test suite
make clean    # Tear down everything

Setup command should:

  • Check for required tools and install/prompt if missing
  • Create databases and run migrations
  • Seed development data
  • Install language-level dependencies
  • Print a success message with next steps

Step 4: Document and Verify

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

  • Update README with setup instructions (3 steps max)
  • Test from a clean clone on a fresh machine
  • Verify that make dev gets from clone to running app
  • Note any platform-specific gotchas (Mac vs Linux)

Key Rules

  • One command to set up, one command to run — no exceptions
  • Dev environment must work offline after initial setup
  • Don't require global installs — use project-local versions
  • Seed data should be realistic enough to actually develop against
  • Dev/prod parity — use same database engine, not SQLite for dev and Postgres for prod
  • Document every environment variable with a description and example value

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.

Ready to use tonone?