Sync skills from skills-v1.0.0 and bump to 0.2.0

CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## 0.2.0 - 2026-10-08
+
+### Changed
+
+- Vendored all 21 Render skills from `render-oss/skills` release `skills-v1.0.0` instead of `main`: shared, single-sourced reference content across skills, doc retrieval that does not require `curl`, and the Render Workflows skill updated for SDK 1.x.
+
+### Removed
+
+- Reference files replaced by shared references: `render-deploy/references/blueprint-spec.md`, `render-disks/references/sizing-and-snapshots.md`, `render-networking/references/troubleshooting.md`, `render-scaling/references/instance-types.md`, and `render-web-services/references/deploy-lifecycle.md`.
+
 ## 0.1.0 - 2026-08-03
 
 Initial GitHub release of the Render integration for the Pi coding agent.

README.md

@@ -19,7 +19,7 @@ MCP package or MCP support prerequisite to install.
 For a reproducible install pinned to this release:
 
 ```bash
-pi install https://github.com/render-oss/render-pi-plugin@v0.1.0
+pi install https://github.com/render-oss/render-pi-plugin@v0.2.0
 ```
 
 ## What you get (v1)

package.json

@@ -1,6 +1,6 @@
 {
   "name": "@render/pi-render",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Render integration for the Pi coding agent — deployment skills and lazy hosted MCP access.",
   "keywords": [
     "pi-package"

skills/.sync-source

@@ -1,4 +1,4 @@
 source: https://github.com/render-oss/skills
-ref: main
-commit: 1b36c1643c1e6105c73ca19cb387fc916d1da4fc
+ref: skills-v1.0.0
+commit: 3a3a422f6074469327708a8c447ada9b6a739747
 note: generated by scripts/sync-skills.sh; do not edit vendored skills by hand.

skills/render-background-workers/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Sets up and configures background workers on Render for queue-based job
   processing. Use when the user needs to process async jobs, consume from a
   queue, run Celery/Sidekiq/BullMQ/Asynq/Oban workers, handle graceful
-  shutdown with SIGTERM, wire a worker to Key Value (Redis), or choose between
+  shutdown with SIGTERM, wire a worker to Key Value, or choose between
   workers and cron jobs for background work.
   Trigger terms: background worker, async jobs, queue consumer, Celery,
   Sidekiq, BullMQ, Asynq, Oban, job processing, SIGTERM, graceful shutdown.
@@ -29,6 +29,10 @@ This skill explains **worker** services on Render: processes that **consume jobs
 
 Per-framework setup and signal-handling detail: `references/queue-framework-setup.md`, `references/graceful-shutdown.md`.
 
+Before deploying, restarting, or changing shutdown behavior, read `references/deployments.md`.
+Before configuring or troubleshooting a worker's outbound private-network connection, read `references/private-networking.md`.
+When choosing between a worker, cron job, and Workflow, read `references/service-types.md`.
+
 ## How Workers Work
 
 - **Long-running services** with **no inbound (HTTP) traffic**. Render does not expose a public URL or internal hostname for workers the way it does for web or private services—**workers cannot receive private network traffic directed at them**.
@@ -39,11 +43,11 @@ Per-framework setup and signal-handling detail: `references/queue-framework-setu
 
 | Framework | Language | Queue backend | Notes |
 |-----------|----------|---------------|--------|
-| Celery | Python | Redis / Key Value | Most common Python task queue |
-| Sidekiq | Ruby | Redis / Key Value | Standard for Rails |
-| BullMQ | Node.js | Redis / Key Value | Modern Node queue (Redis-based) |
-| Asynq | Go | Redis / Key Value | Go async task processing |
-| Oban | Elixir | **Postgres** (not Redis) | Queue stored in the database |
+| Celery | Python | Key Value | Most common Python task queue |
+| Sidekiq | Ruby | Key Value | Standard for Rails |
+| BullMQ | Node.js | Key Value | Modern Node queue |
+| Asynq | Go | Key Value | Go async task processing |
+| Oban | Elixir | **Postgres** (not a Key Value queue) | Queue stored in the database |
 
 ## Pairing with Key Value
 
@@ -61,13 +65,12 @@ See `references/queue-framework-setup.md` for minimal app + YAML examples.
 | Always-on queue consumer | **Background Worker** | Polls continuously; long-lived process |
 | Periodic scheduled task | **Cron Job** | Runs on a schedule, **exits**; **12h max** per run |
 | Distributed parallel compute | **Workflow** | Each run gets its own instance; fan-out patterns |
-| High-volume or bursty jobs | **Workflow** | Scales per run; **no idle instance cost** between runs |
+| High-volume or bursty jobs | **Workflow** | Scales per run without a continuously running worker instance |
 
 ## Graceful Shutdown
 
-- Before stopping an instance, Render sends **`SIGTERM`**, then waits up to **`maxShutdownDelaySeconds`** (**1–300**, **default 30**) before **`SIGKILL`**.
 - Workers should: **(1)** stop accepting new jobs, **(2)** finish the current job or **checkpoint** progress, **(3)** close connections, **(4)** exit **0**.
-- Set **`maxShutdownDelaySeconds`** to at least your **longest safe job duration** (see Dashboard or Blueprint).
+- Follow `references/deployments.md` for Render's current drain, signal, and shutdown-delay behavior.
 
 Language- and framework-specific handlers: `references/graceful-shutdown.md`.
 
@@ -81,6 +84,7 @@ services:
     name: jobs
     plan: starter
     region: oregon
+    maxmemoryPolicy: noeviction
     ipAllowList: []
 
   - type: worker
@@ -106,10 +110,26 @@ Optional: **`maxShutdownDelaySeconds`** on the worker service for longer drainin
 |--------|------|
 | Celery, Sidekiq, BullMQ, Asynq, Oban setup + YAML | `references/queue-framework-setup.md` |
 | SIGTERM, `maxShutdownDelaySeconds`, per-language patterns | `references/graceful-shutdown.md` |
+| Deploy lifecycle, shutdown, restart, and verification | `references/deployments.md` |
+| Private-network scope, internal addresses, and troubleshooting | `references/private-networking.md` |
+| Service-type selection and execution models | `references/service-types.md` |
 
 ## Related Skills
 
 - **render-deploy** — First deploy, CLI, service creation
 - **render-blueprints** — Full `render.yaml` schema, `fromService`, projects
 - **render-networking** — Private URLs, what can call what
 - **render-scaling** — Worker plans, instance counts, limits
+
+<!-- shared:documentation-retrieval -->
+## Current documentation retrieval
+
+Whenever this skill directs you to consult current Render documentation:
+
+1. Retrieve the linked Markdown document directly with an available URL-fetching tool or HTTP client, such as `curl`. Do not substitute web-search summaries for the document.
+2. Confirm that retrieval succeeded and returned the expected document, then read its contents. Saving a file or printing its path is not sufficient.
+3. If the request fails or your tool cannot read the Markdown response, open and read the linked HTML version instead.
+4. If neither version can be retrieved, disclose that the current reference is unavailable and follow any topic-specific fallback in the skill. Use bundled guidance only for stable constraints, and do not guess at changeable platform details.
+
+When a task requires multiple references, apply this workflow to each one and distinguish the documents you verified from those that remain unavailable.
+<!-- /shared:documentation-retrieval -->

skills/render-background-workers/references/deployments.md

@@ -0,0 +1,50 @@
+<!-- shared:deployments -->
+## Deployments and health checks
+
+A Render deploy is asynchronous. A successful trigger means only that Render accepted or queued the deploy; it does not mean the new version is live. Before triggering a deploy, confirm the workspace, service, intended source commit or image, and current live deploy. Capture the new deploy ID, monitor it to a terminal state, and do not report success until its status is `live` and the deployed workload has been verified.
+
+Before configuring or troubleshooting deployments and health checks, fetch the current Render references:
+
+- [deploys.md](https://render.com/docs/deploys.md) (HTML: <https://render.com/docs/deploys>)
+- [health-checks.md](https://render.com/docs/health-checks.md) (HTML: <https://render.com/docs/health-checks>)
+
+Using the documentation-retrieval workflow in the root `SKILL.md`, retrieve and read both references.
+
+Read the relevant sections of both documents. Confirm current service-type support, command timeouts, health-check thresholds, rollout behavior, and configuration syntax rather than relying on remembered values.
+
+Automatic deployment behavior depends on the service's source and settings. A service linked to a branch through a connected Git provider can deploy on each commit, wait for supported CI checks, or require manual triggers. Services that pull a prebuilt image and services linked by a public Git repository URL require manual deploys; moving a mutable image tag does not itself trigger one. When manually deploying a historical commit, verify whether that trigger method changes automatic-deploy settings. If automatic deploys remain enabled, a later branch update can replace the selected commit.
+
+The normal lifecycle is build command, optional pre-deploy command, then start command and readiness checks. If a command fails or times out, the deploy fails and later steps do not run. A pre-deploy command runs after the build on a separate instance before the new version is deployed. Neither the build nor pre-deploy instance can access an attached persistent disk, and pre-deploy filesystem changes do not carry into the running service. Use pre-deploy for release tasks such as database migrations, not for producing runtime artifacts. Pre-deploy commands are supported for paid web services, private services, and background workers.
+
+Render normally deploys services without downtime by starting the new version before retiring the current one. Web and private services continue routing traffic to the current instances until the new instances are ready. Multi-instance services roll out one instance at a time; if a replacement does not become healthy, Render cancels the rollout and retains or restores the previous version. Attaching a persistent disk disables zero-downtime deploys, so plan explicitly for an interruption.
+
+A workflow deployment has a different completion model. It builds and caches the image used by future task runs and includes a task-registration step, but it does not execute those tasks. After a workflow deploy succeeds, verify that the expected task definitions are registered. Trigger and monitor a task run separately only when execution is intended. For workflow-specific deployment behavior, fetch the current workflow overview:
+
+Using the documentation-retrieval workflow in the root `SKILL.md`, retrieve and read the [Markdown reference](https://render.com/docs/workflows.md) or its [HTML version](https://render.com/docs/workflows).
+
+Health checks apply to web services and private services. Both use TCP socket checks by default. Only web services support a configured HTTP health-check path. Render sends an HTTP `GET`; any `2xx` or `3xx` response received within five seconds succeeds, while other status codes, timeouts, and connection failures fail. Private services support TCP checks only.
+
+For a new deploy, all new instances must pass their checks at the same time within the current readiness window, documented as 15 minutes, before Render routes traffic to them. For a running service, consecutive failures currently remove an instance from routing after 15 seconds and restart it after 60 seconds. Treat these thresholds as platform behavior, not user-tunable health-check interval settings, and verify them in the fetched reference before relying on exact timing.
+
+Design an HTTP health endpoint to represent readiness for production traffic. Keep it fast and side-effect free. Check critical dependencies only when losing that dependency should make the entire instance unavailable; otherwise a transient dependency failure can unnecessarily remove healthy application capacity. Verify the configured path, response status, response time, listening port, and `0.0.0.0` binding when checks fail.
+
+After traffic moves, Render gives the previous instance a drain period, then sends `SIGTERM`. The application should stop accepting new work, finish or safely abandon in-flight work, close connections, and exit within its shutdown delay. Ensure the actual application process receives the signal: container entrypoints and shell wrappers should use `exec` or explicitly forward signals. Render sends `SIGKILL` if the process remains running after the delay. The documented default shutdown delay is 30 seconds and the usual maximum is 300 seconds, but support varies by service configuration; confirm the current reference and Blueprint or API validation before setting `maxShutdownDelaySeconds`.
+
+A service restart is a special deploy of the same commit and user-defined environment-variable values as the current running instance. It does not incorporate configuration changes saved after that deploy. Use a standard deploy when pending configuration must take effect.
+
+Only one deploy runs at a time for a service. A workspace's overlapping-deploy policy determines whether a new trigger waits or cancels the in-progress deploy. Do not assume the policy or wait for every intermediate revision: inspect the workspace setting and identify the deploy that actually became live.
+
+Treat rollback as a new deploy based on a retained previous build artifact, not as restoration of the entire service to an earlier point in time. It does not reverse database migrations, messages, external writes, or other side effects from the release, so confirm that the previous application version remains compatible with current external state. Disks and their data are not rolled back, some settings continue using current configuration, mutable image tags can resolve to a different image, and eligible artifacts are retained only for a limited period. Before rolling back, fetch the current rollback reference:
+
+Using the documentation-retrieval workflow in the root `SKILL.md`, retrieve and read the [Markdown reference](https://render.com/docs/rollbacks.md) or its [HTML version](https://render.com/docs/rollbacks).
+
+Read which configuration comes from the target deploy and which remains current. After the rollback is created, inspect the service's resulting automatic-deploy setting instead of assuming whether it remains enabled, and deliberately restore the intended setting after the underlying issue is resolved.
+
+Deploy hooks are secret credentials that authorize deploys. Never print, commit, or expose their full URLs. Before using one, fetch the current deploy-hook reference:
+
+Using the documentation-retrieval workflow in the root `SKILL.md`, retrieve and read the [Markdown reference](https://render.com/docs/deploy-hooks.md) or its [HTML version](https://render.com/docs/deploy-hooks).
+
+Distinguish an immediately started deploy from a queued one, and continue monitoring the resulting deploy rather than treating the HTTP response as completion.
+
+After a deploy becomes live, verify the behavior appropriate to the service type: make a request to a web or private service, confirm a worker is processing work, confirm a cron job or workflow invocation completes, and inspect recent runtime logs for new errors. If a deploy fails, diagnose the first failed lifecycle stage before retrying.
+<!-- /shared:deployments -->

skills/render-background-workers/references/graceful-shutdown.md

@@ -4,17 +4,13 @@ Render stops worker instances during **deploys**, **manual restarts**, and **sca
 
 ## Platform behavior
 
-1. Render sends **`SIGTERM`** to your process.
-2. The platform waits up to **`maxShutdownDelaySeconds`** (**1–300**, **default 30**).
-3. If the process is still running, Render sends **`SIGKILL`** (not catchable).
-
-Configure **`maxShutdownDelaySeconds`** in the **Dashboard** (service settings) or in **`render.yaml`** on the worker service. Set it to cover your **longest job** you are willing to let complete during shutdown (plus buffer for flushing metrics, closing DB pools, etc.).
+Follow [deployments.md](deployments.md) for Render's current drain, signal, and shutdown-delay behavior. Set the available shutdown delay to cover the longest job you are willing to let complete, plus time for cleanup.
 
 ## General pattern
 
 1. **Stop accepting new jobs** — stop the consumer loop, pause polling, or drain the framework’s internal fetch.
 2. **Finish the current job** or **checkpoint** durable progress so another worker can resume safely.
-3. **Close connections** — Redis/Postgres pools, HTTP clients.
+3. **Close connections** — Key Value/Postgres pools, HTTP clients.
 4. **Exit with code 0** when done.
 
 ## Python