oe-backend-prod-hardening

shami-ah's avatarfrom shami-ah

Production hardening review for the OpenEvent backend. Use when scanning for LLM smells, noisy prints, swallowed exceptions, dev-only defaults, fallback diagnostic leakage, and inconsistent error/logging patterns; produce a prioritized, PR-sized cleanup plan.

⭐0stars🔀1forks📁View on GitHub🕐Updated Jan 8, 2026⬇️1downloads
[Code Review]

When & Why to Use This Skill

This Claude skill automates production hardening reviews for backend systems by identifying critical code smells such as diagnostic leaks, improper error handling, and insecure defaults. It streamlines the transition from development to production-ready code by generating a prioritized, actionable cleanup plan organized into manageable pull requests, ensuring system reliability and security.

Use Cases

  • Pre-deployment Audit: Automatically scanning the backend codebase for noisy print statements and swallowed exceptions to ensure production stability and clean logs.
  • Security & Privacy Hardening: Identifying and mitigating instances where internal system diagnostics or 'dev-only' configurations might be exposed to end-users, preventing sensitive data leakage.
  • Technical Debt Management: Systematically transforming inconsistent error handling and logging patterns into structured, ops-visible events through a prioritized pull request roadmap.
nameoe-backend-prod-hardening
descriptionProduction hardening review for the OpenEvent backend. Use when scanning for LLM smells, noisy prints, swallowed exceptions, dev-only defaults, fallback diagnostic leakage, and inconsistent error/logging patterns; produce a prioritized, PR-sized cleanup plan.

oe-backend-prod-hardening

Audit workflow (tight + actionable)

  1. Scan for runtime smells:

    • rg -n "print\\(" backend
    • rg -n "except Exception\\s*:\\s*(pass)?$" backend
    • rg -n "OE_FALLBACK_DIAGNOSTICS|FALLBACK" backend
    • rg -n "ENABLE_DANGEROUS_ENDPOINTS" backend

  2. Classify findings:

    • User-visible (must not leak diagnostics)
    • Ops-visible (structured logs, trace events)
    • Dev-only (move to scripts / gated)

  3. Convert into a PR ladder:

    • One concern per PR: logging, error handling, config defaults, MCP bootstrap, etc.

Canonical reference

  • Add/maintain items in docs/internal/BACKEND_REFACTORING_PLAN_DEC_2025_ADDENDUM.md.