onboard-db-commune

Onboard AMSA applications into the shared db_commune PostgreSQL setup.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/Ascenseurs-Menetrey-SA/amsa-claude-skills --skill onboard-db-commune
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: onboard-db-commune
Source: https://github.com/Ascenseurs-Menetrey-SA/amsa-claude-skills/tree/main/onboard-db-commune
Command: npx skills add https://github.com/Ascenseurs-Menetrey-SA/amsa-claude-skills --skill onboard-db-commune

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Onboard-db-commune helps you safely connect an AMSA application to the shared PostgreSQL database db_commune, including diagnosis, required code conversion, Alembic bootstrap, and cleanup of isolated database configuration.

Core Features & Use Cases

  • Smart diagnosis first: classifies the app’s current database setup (SQLite vs PostgreSQL async/sync, Alembic presence) and determines which phases to run.
  • Dual-mode conversion: for SQLite or PostgreSQL sync setups, updates the app to use async PostgreSQL while keeping dev-friendly SQLite behavior when required.
  • Production-grade schema safety: enforces fail-secure schema scoping via MetaData(schema=...) so tables land in the correct {app_name} schema rather than drifting into public.
  • db_commune infrastructure wiring: provisions roles, schemas, grants, PgBouncer aliases, secrets/health checks, and validates CI/CD expectations for password provisioning.
  • Final verification & reporting: produces a phase-by-phase validation report and highlights CI/CD risks and blocked fixes.

Quick Start

Run the onboarding by calling: /onboard-db-commune planning_projets /path/to/app planning_projets_db_commune_dir

Frequently Asked Questions about onboard-db-commune

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate a FastAPI application from SQLite to a shared PostgreSQL database?

Migrating a FastAPI application from SQLite to a shared PostgreSQL database involves diagnosing the current setup, converting to async PostgreSQL while keeping dev-friendly SQLite behavior, and bootstrapping Alembic to manage schema migrations securely.

What is the best way to enforce multi-tenant schema isolation in a shared PostgreSQL setup?

The best way to enforce multi-tenant schema isolation in a shared PostgreSQL setup is by applying fail-secure schema scoping via MetaData(schema=...), ensuring application tables land in the correct app-specific schema instead of drifting into public.

How do I initialize Alembic migrations for an existing PostgreSQL sync application?

To initialize Alembic migrations for an existing PostgreSQL sync application, the system converts the app to async PostgreSQL, runs the Alembic bootstrap phase to establish migration infrastructure, and cleans up any isolated database configurations.

Does CI/CD deployment require PgBouncer wiring for PostgreSQL role passwords?

CI/CD deployment requires PgBouncer wiring for effective database connectivity, and the system validates specific expectations for role password provisioning to ensure secure infrastructure access during deployment pipelines.

Can I use this workflow to provision database roles and schemas for multiple AMSA apps?

Yes, you can use this workflow to provision database roles, schemas, and grants for multiple AMSA apps by routing infrastructure setup via the migration-db workflow, ensuring each app connects safely to the shared db_commune PostgreSQL database.

When should I not use fail-secure schema scoping for PostgreSQL async migrations?

You should not bypass fail-secure schema scoping when migrating PostgreSQL async setups, as skipping MetaData(schema=...) risks tables drifting into the public schema, compromising multi-tenant safety and shared database integrity.