robyn-config-backend-best-practices
Robyn backend scaffolding and architecture guidance for projects using robyn-config. Use when creating or evolving Robyn services, choosing DDD vs MVC, choosing SQLAlchemy vs Tortoise, adding entities with robyn-config add, scaffolding admin panel with robyn-config adminpanel, adding observability stack with robyn-config monitoring, auditing Robyn backend quality, or authoring and improving skill markdown for Robyn engineering workflows.
Robyn Config Backend Best Practices
Overview and intent
Use this skill to work effectively with robyn-config and production-oriented Robyn backend patterns.
This skill is optimized for seven task groups:
- scaffold a new service with
robyn-config create - extend an existing service with
robyn-config add - scaffold admin panel with
robyn-config adminpanel - add observability stack with
robyn-config monitoring - keep local skill installation synchronized with latest
robyn-configpackage releases - audit and improve architecture and operational readiness
- author high-quality skill files for Robyn engineering work
Do not load every reference file by default. Load only the files required for the current task.
Fast triage workflow
- Detect project metadata in
pyproject.toml:[tool.robyn-config].design(dddormvc)[tool.robyn-config].orm(sqlalchemyortortoise)[tool.robyn-config].package_manager(uvorpoetry)
- Classify requested work:
- bootstrap
- extension
- adminpanel scaffolding
- monitoring stack setup
- package release sync
- architecture or operations audit
- skill authoring
- Select references from the routing table in this file.
- Produce branch-specific guidance for design, ORM, and package manager.
- End with a validation checklist and concrete commands.
Workflow A: bootstrap from robyn-config create
- Select stack options: design, ORM, package manager.
- Generate service:
robyn-config create <service-name> --design <ddd|mvc> --orm <sqlalchemy|tortoise> --package-manager <uv|poetry> <destination>
- Confirm output baseline:
pyproject.tomlcontains[tool.robyn-config]src/applayout matches selected design- lock file matches package manager (
uv.lockorpoetry.lock)
- Execute ORM-specific migration bootstrap before app start.
- Run lint, type checks, and tests, then report exact failures with file paths.
Workflow B: evolve project with robyn-config add
- Ensure target project is a
robyn-configproject by checking[tool.robyn-config]. - Read optional path overrides under
[tool.robyn-config.add]. - Add module:
robyn-config add <entity-name> <project-path>
- Verify generated updates:
- new files in expected layer paths
- route registration inserted in the right registry file
- repository exports and tables updated
- no duplicate symbols or broken imports
- Regenerate migrations if schema changed.
- Run checks and confirm command rollback behavior if failures occur.
Workflow C: add admin panel with robyn-config adminpanel
- Ensure target project is a
robyn-configproject by checking[tool.robyn-config]. - Check whether
[tool.robyn-config.adminpanel].created = truealready exists; if yes, account for update confirmation behavior. - Run command:
robyn-config adminpanel [-u <admin-username>] [-p <admin-password>] <project-path>
- Verify generated behavior:
- admin module exists for the selected design and is registered in app startup.
/adminUI supports dark/light themes.- project models are auto-discovered and listed under
/admin/models. - CRUD flows are available for discovered model tables.
- admin auth bootstrap is configured for default or provided superadmin credentials.
- Verify dependencies and metadata updates in
pyproject.toml:- required dependencies:
jinja2,aiosqlite,pandas,openpyxl [tool.robyn-config.adminpanel].created = true
- required dependencies:
- Run checks and confirm command rollback behavior if failures occur.
Workflow D: add observability with robyn-config monitoring
- Ensure target project is a
robyn-configproject by checking[tool.robyn-config]. - Run command:
robyn-config monitoring <project-path>
- Verify generated artifacts:
docker-compose.monitoring.ymlat project root.compose/monitoring/alloy/config.alloy— Docker log discovery + Prometheus scrape withjob_name = "app".compose/monitoring/prometheus/prometheus.yml— minimal Prometheus config.compose/monitoring/grafana/datasources/loki.yamlandprometheus.yaml— provisioned datasources with fixed UIDs (uid: loki,uid: prometheus).compose/monitoring/grafana/provisioning/dashboards.yaml— dashboard provisioning config.compose/monitoring/grafana/dashboards/logs.json— Loki logs dashboard with search bar.compose/monitoring/grafana/dashboards/metrics.json— Prometheus metrics dashboard.metrics.pyinjected into the presentation layer and registered asGET /metrics.
- Verify
prometheus-clientwas installed (or added topyproject.tomldependencies as fallback). - Start the observability stack alongside the app:
docker compose up -d
docker compose -f docker-compose.monitoring.yml up -d
- Validate:
http://localhost:8000/metricsreturns Prometheus text output.- Grafana at
http://localhost:3000loads both dashboards without errors. - Logs panel shows data within 30 seconds of app activity.
- Metrics panel shows data within one scrape interval (15 s).
Workflow E: review and improve architecture and ops readiness
- Validate architecture boundaries for selected design.
- Validate runtime safety:
- settings and env overrides
- auth, session, CORS behavior
- transaction boundaries and error mapping
- Validate operations:
- migration startup order
- compose and local parity
- logging and debug posture
- Prioritize recommendations:
- P0 correctness and security
- P1 reliability and consistency
- P2 maintainability and performance
- Provide file-targeted, diff-ready changes.
Workflow F: author and update skill files for Robyn engineering
- Keep
SKILL.mdconcise and procedural. - Put deep detail into
references/and load on demand. - Write frontmatter with explicit trigger contexts.
- Reuse rule patterns from
react-best-practiceswhere useful. - Validate skill structure before delivering:
- no placeholder markers
- all referenced files exist
- no extra docs such as README or changelog inside skill folder
Workflow G: sync skills after a robyn-config package release
- Run:
./skills/robyn-config-backend-best-practices/scripts/update-if-new-robyn-config.sh
- Script behavior:
- checks installed
robyn-configversion vs latest PyPI version - if newer version exists, runs
python -m pip install --upgrade robyn-config - then runs
npx skills update - if already up to date, exits without changes
- checks installed
Reference routing table
Open only the file needed for the task:
references/robyn-config-src-analysis.md- Use for
robyn-configinternals and generation/injection behavior, including themonitoringcommand.
- Use for
references/robyn-backend-best-practices.md- Use for prioritized engineering guidance and review criteria.
references/robyn-config-workflows.md- Use for operator playbooks and command sequences, including monitoring stack setup and validation.
references/architecture-ddd-vs-mvc.md- Use for architecture selection and refactor planning.
references/orm-sqlalchemy-vs-tortoise.md- Use for ORM tradeoffs and migration/session behavior.
references/skill-authoring-patterns.md- Use for writing and validating high-quality skill markdown.
references/react-style-rule-system.md- Use for reusable rule-library design patterns and taxonomy.
scripts/update-if-new-robyn-config.sh- Use to check for a newer
robyn-configrelease and update local skills only when needed.
- Use to check for a newer
Output requirements
Always:
- Include concrete executable commands.
- Include design and ORM branch-specific instructions.
- Include package-manager-aware instructions (
uvandpoetry). - Include a validation checklist covering structure, behavior, and checks.
- State assumptions explicitly when repository context is incomplete.