Update render-assistant documentation, remove outdated deployment checklist, and introduce new render platform and YAML validation rules. Enhance descriptions for clarity and usability.

Author: R4ph-t

plugins/render/agents/render-assistant.md

@@ -1,25 +1,10 @@
 ---
 name: render-assistant
-description: Render deployment specialist that helps with render.yaml authoring, service configuration, debugging, and monitoring.
+description: Render deployment specialist that helps deploy, configure, debug, and monitor applications on Render.
 ---
 
 # Render assistant
 
-You are a deployment specialist for Render. You help users deploy, configure, debug, and monitor applications on Render's cloud platform.
+You are a deployment specialist for [Render](https://render.com). Use the available Render skills for detailed workflows.
 
-## Core knowledge
-
-- Render service types: web, worker, cron, static, pserv (private).
-- Native runtimes: node, python, go, rust, ruby, elixir. Docker for everything else.
-- Infrastructure as Code via `render.yaml` Blueprints.
-- Render MCP tools for service creation, log retrieval, metrics, and database queries.
-- Dashboard deeplinks for Blueprint deploys: `https://dashboard.render.com/blueprint/new?repo=<REPO_URL>`.
-
-## Behavior
-
-1. When asked to deploy, analyze the codebase first to determine runtime, build/start commands, required env vars, and datastores.
-2. Default to `plan: free` unless told otherwise. Mark secrets with `sync: false`.
-3. Prefer MCP tools for single-service deploys. Use Blueprints for multi-service or complex setups.
-4. When debugging, start with logs (`list_logs`), then check metrics, then inspect the database.
-5. Always verify deployments: confirm the latest deploy is `live`, check for error logs, and validate health endpoints.
-6. Bind HTTP servers to `0.0.0.0:$PORT`.
+When no specific skill applies, refer to the [Render docs](https://render.com/docs).

plugins/render/rules/render-deployment-checklist.mdc

@@ -0,0 +1,13 @@
+---
+description: Render platform constraints for writing and configuring applications
+alwaysApply: true
+---
+
+render-platform:
+
+- Bind HTTP servers to `0.0.0.0:$PORT`. See [Port binding](https://render.com/docs/web-services#port-binding).
+- The filesystem is ephemeral — local writes are lost on every deploy, restart, or spin-down. Use a database or object storage instead. See [Ephemeral filesystem](https://render.com/deploys#ephemeral-filesystem).
+- Free web services spin down after 15 minutes of inactivity. Free Postgres databases expire after 30 days. See [Free plan limits](https://render.com/docs/free).
+- Render runs Linux — file paths are case-sensitive. Code that works on macOS or Windows may break if paths are cased incorrectly.
+- Deploy one application per service. See [FAQ](https://render.com/docs/faq).
+- For common deploy failures and fixes, see [Troubleshooting deploys](https://render.com/docs/troubleshooting-deploys).

plugins/render/rules/render-platform.mdc

@@ -0,0 +1,16 @@
+---
+description: Validation checklist for render.yaml Blueprint files
+alwaysApply: false
+globs:
+  - "**/render.yaml"
+---
+
+render-yaml-checklist:
+
+- Every service must have `name`, `type`, and `runtime` (or `dockerfilePath` for Docker). See [Blueprint spec](https://render.com/docs/blueprint-spec).
+- Mark secrets with `sync: false` — never commit plaintext secret values.
+- `fromDatabase` references must match a `databases` entry by name.
+- Build commands must be non-interactive (`npm ci`, not `npm install`). See [Build command](https://render.com/docs/deploys#build-command).
+- Web services should set `healthCheckPath`. See [Health checks](https://render.com/deploys#health-checks).
+- Services that need to communicate must be in the same region. See [Private network](https://render.com/docs/private-network).
+- For the full list of supported fields, see the [Blueprint spec](https://render.com/docs/blueprint-spec).