# Vinayaka

> Production readiness standards for zero production issues. Use when deploying, releasing, doing a pre-launch review, or when anyone asks "is this ready for prod".

- Skill: `arjuncrevathi/vinayaka` (Agent Skill)
- Install (CLI): `npx skillmds@latest add arjuncrevathi/vinayaka`
- Raw SKILL.md: https://api.skillmd.com/api/skills/arjuncrevathi/vinayaka/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: arjuncrevathi (https://skillmd.com/u/arjuncrevathi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/arjuncrevathi/vinayaka

---


# Vinayaka — Remover of Obstacles (Production Readiness)

Vinayaka clears every obstacle before launch so nothing blocks the path in production.

## Pre-deploy checklist (blocking)

- All required env vars exist in the target environment — verify against a checked-in schema (`pydantic-settings` / `zod`-parsed `process.env`), fail fast at boot if any are missing.
- DB migrations are reversible: every migration has a tested `down`, and is backward-compatible with the currently running code (expand → migrate → contract).
- Risky changes ship behind a feature flag, default off. Flag can be flipped without a deploy.
- Rollback plan documented in the PR/release notes: exact command, who runs it, and how long it takes. If rollback needs a migration reversal, rehearse it in staging.
- Staging mirrors prod: same runtime versions, same infra shape, realistic data volume. "Works in staging" means nothing if staging is a toy.

## Service hardening

- Liveness and readiness probes are separate: readiness checks dependencies (DB, cache, queue); liveness checks only the process. Never point liveness at the DB.
- Graceful shutdown: trap SIGTERM, stop accepting new requests, drain in-flight work (uvicorn `--timeout-graceful-shutdown`, `server.close()` in Node), then exit. Set terminationGracePeriod above your slowest request.
- Rate limiting on every public endpoint (per-user and per-IP), returning 429 with `Retry-After`.
- Input validation on all endpoints — every body, query param, and header parsed through pydantic/zod. Unvalidated input never reaches business logic (see `muruka`).
- Structured logs with request IDs; errors go to Sentry (or equivalent) with release tagging so a bad deploy is attributable in minutes.

## Deploy execution

- Deploy during low-traffic windows; never Friday evening, never right before the team goes offline.
- Roll out progressively where possible (canary or 10% → 100%).
- Monitor for 30 minutes post-deploy: error rate, p95 latency, and one core business metric. Whoever deployed watches the dashboards — the deploy is not done when CI goes green.
- Any sustained error-rate or latency regression → roll back first, debug after.

## AI-native specifics

- Configure a fallback model (or degraded non-LLM path) for provider outages; verify the failover actually triggers, in staging, before launch.
- Prompts are versioned artifacts: pin the prompt version and model ID per release so behavior changes are attributable and rollbackable.
- Output guardrails before anything user-facing or side-effecting: schema-validate LLM output, enforce max length, and moderate/filter unsafe content. On guardrail failure, retry once then fall back — never ship raw failure to the user.
- Set hard spend and token-rate limits per environment so a retry loop can't burn the API budget.

## Before every release — checklist

- [ ] Env vars validated at boot; migrations reversible and rehearsed
- [ ] Rollback command documented; risky paths behind a flag
- [ ] Readiness/liveness probes and graceful shutdown verified
- [ ] Rate limits + input validation on all public endpoints
- [ ] LLM fallback, prompt version pin, and output guardrails in place
- [ ] 30-minute post-deploy watch assigned to a named person