[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7BCZM91ZT0YBVCFQRHSRWDC":3,"skill-same:01M7BCZM91ZT0YBVCFQRHSRWDC":124},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":28,"commitSha":29,"skillDirectory":30,"forksCount":13,"repositoryHtmlUrl":31,"repositoryHomepageUrl":6,"ownerHtmlUrl":32,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":33,"install":34,"resources":47},"01M7BCZM91ZT0YBVCFQRHSRWDC","render-deploy",null,"Deploy applications to Render by analyzing codebases, generating render.yaml Blueprints, and providing Dashboard deeplinks. Use when the user wants to deploy, host, publish, or set up their application on Render's cloud platform.","vikasvardhanv\u002Fjerry_skills","vikasvardhanv","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F99010657?v=4","01M7B2B0VN78W7529RQX5BR6DZ","01M7B2B0WDNTXJHRK3QNPNWRP6",0,"MIT","https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: render-deploy\ndescription: Deploy applications to Render by analyzing codebases, generating render.yaml Blueprints, and providing Dashboard deeplinks. Use when the user wants to deploy, host, publish, or set up their application on Render's cloud platform.\nlicense: MIT\ncompatibility: Requires a Git repository on GitHub, GitLab, or Bitbucket for Blueprint\u002FMCP flows. Blueprint can reference a prebuilt image but render.yaml must live in the repo. Render CLI recommended for Blueprint validation; MCP or CLI required for operations.\nmetadata:\n  author: Render\n  version: \"1.1.0\"\n  category: deployment\n---\n\n# Deploy to Render\n\nRender supports **Git-backed** services and **prebuilt Docker image** services.\n\nThis skill covers **Git-backed** flows:\n1. **Blueprint Method** - Generate render.yaml for Infrastructure-as-Code deployments\n2. **Direct Creation** - Create services instantly via MCP tools\n\nBlueprints can also run a **prebuilt Docker image** by using `runtime: image`, but the `render.yaml` still must live in a Git repo.\n\nIf there is no Git remote, stop and ask the user to either:\n- Create\u002Fpush a Git remote (can be minimal if only the Blueprint is needed), or\n- Use the Render Dashboard\u002FAPI to deploy a prebuilt Docker image (MCP cannot create image-backed services).\n\n## When to Use This Skill\n\nActivate this skill when users want to:\n- Deploy an application to Render\n- Create a render.yaml Blueprint file\n- Set up Render deployment for their project\n- Host or publish their application on Render's cloud platform\n- Create databases, cron jobs, or other Render resources\n\n## Happy Path (New Users)\n\nUse this short prompt sequence before deep analysis to reduce friction:\n1. Ask whether they want to deploy from a Git repo or a prebuilt Docker image.\n2. Ask whether Render should provision everything the app needs (based on what seems likely from the user's description) or only the app while they bring their own infra. If dependencies are unclear, ask a short follow-up to confirm whether they need a database, workers, cron, or other services.\n\nThen proceed with the appropriate method below.\n\n## Choose Your Source Path\n\n**Git Repo Path:** Required for both Blueprint and Direct Creation. The repo must be pushed to GitHub, GitLab, or Bitbucket.\n\n**Prebuilt Docker Image Path:** Supported by Render via image-backed services. This is **not** supported by MCP; use the Dashboard\u002FAPI. Ask for:\n- Image URL (registry + tag)\n- Registry auth (if private)\n- Service type (web\u002Fworker) and port\n\nIf the user chooses a Docker image, guide them to the Render Dashboard image deploy flow or ask them to add a Git remote (so you can use a Blueprint with `runtime: image`).\n\n## Choose Your Deployment Method (Git Repo)\n\nBoth methods require a Git repository pushed to GitHub, GitLab, or Bitbucket. (If using `runtime: image`, the repo can be minimal and only contain `render.yaml`.)\n\n| Method | Best For | Pros |\n|--------|----------|------|\n| **Blueprint** | Multi-service apps, IaC workflows | Version controlled, reproducible, supports complex setups |\n| **Direct Creation** | Single services, quick deployments | Instant creation, no render.yaml file needed |\n\n### Method Selection Heuristic\n\nUse this decision rule by default unless the user requests a specific method. Analyze the codebase first; only ask if deployment intent is unclear (e.g., DB, workers, cron).\n\n**Use Direct Creation (MCP) when ALL are true:**\n- Single service (one web app or one static site)\n- No separate worker\u002Fcron services\n- No attached databases or Key Value\n- Simple env vars only (no shared env groups)\nIf this path fits and MCP isn't configured yet, stop and guide MCP setup before proceeding.\n\n**Use Blueprint when ANY are true:**\n- Multiple services (web + worker, API + frontend, etc.)\n- Databases, Redis\u002FKey Value, or other datastores are required\n- Cron jobs, background workers, or private services\n- You want reproducible IaC or a render.yaml committed to the repo\n- Monorepo or multi-env setup that needs consistent configuration\n\nIf unsure, ask a quick clarifying question, but default to Blueprint for safety. For a single service, strongly prefer Direct Creation via MCP and guide MCP setup if needed.\n\n## Prerequisites Check\n\nWhen starting a deployment, verify these requirements in order:\n\n**1. Confirm Source Path (Git vs Docker)**\n\nIf using Git-based methods (Blueprint or Direct Creation), the repo must be pushed to GitHub\u002FGitLab\u002FBitbucket. Blueprints that reference a prebuilt image still require a Git repo with `render.yaml`.\n\n```bash\ngit remote -v\n```\n\n- If no remote exists, stop and ask the user to create\u002Fpush a remote **or** switch to Docker image deploy.\n\n**2. Check MCP Tools Availability (Preferred for Single-Service)**\n\nMCP tools provide the best experience. Check if available by attempting:\n```\nlist_services()\n```\n\nIf MCP tools are available, you can skip CLI installation for most operations.\n\n**3. Check Render CLI Installation (for Blueprint validation)**\n```bash\nrender --version\n```\nIf not installed, offer to install:\n- macOS: `brew install render`\n- Linux\u002FmacOS: `curl -fsSL https:\u002F\u002Fraw.githubusercontent.com\u002Frender-oss\u002Fcli\u002Fmain\u002Fbin\u002Finstall.sh | sh`\n\n**4. MCP Setup (if MCP isn't configured)**\n\nIf `list_services()` fails, set up the Render MCP server. For detailed per-tool walkthroughs, see **render-mcp**.\n\n**Quick setup:** Add the Render MCP server to your AI tool's MCP config:\n- **URL:** `https:\u002F\u002Fmcp.render.com\u002Fmcp`\n- **Auth header:** `Authorization: Bearer \u003CYOUR_API_KEY>`\n- **API key:** `https:\u002F\u002Fdashboard.render.com\u002Fu\u002F*\u002Fsettings#api-keys`\n\nAfter configuring, restart your tool and retry `list_services()`. Then set your workspace with `list_workspaces()` \u002F `get_selected_workspace()`.\n\n**5. Check Authentication (CLI fallback only)**\n\nIf MCP isn't available, use the CLI instead and verify you can access your account:\n```bash\n# Check if user is logged in (use -o json for non-interactive mode)\nrender whoami -o json\n```\n\nIf `render whoami` fails or returns empty data, the CLI is not authenticated. The CLI won't always prompt automatically, so explicitly prompt the user to authenticate:\n\nIf neither is configured, ask user which method they prefer:\n- **API Key (CLI)**: `export RENDER_API_KEY=\"rnd_xxxxx\"` (Get from https:\u002F\u002Fdashboard.render.com\u002Fu\u002F*\u002Fsettings#api-keys)\n- **Login**: `render login` (Opens browser for OAuth)\n\n**6. Check Workspace Context**\n\nVerify the active workspace:\n```\nget_selected_workspace()\n```\n\nOr via CLI:\n```bash\nrender workspace current -o json\n```\n\nTo list available workspaces:\n```\nlist_workspaces()\n```\n\nIf user needs to switch workspaces, they must do so via Dashboard or CLI (`render workspace set`).\n\nOnce prerequisites are met, proceed with deployment workflow.\n\n---\n\n# Method 1: Blueprint Deployment (Recommended for Complex Apps)\n\n## Blueprint Workflow\n\n### Step 1: Analyze Codebase\n\nAnalyze the codebase to determine framework\u002Fruntime, build and start commands, required env vars, datastores, and port binding. Use the detailed checklists in [references\u002Fcodebase-analysis.md](references\u002Fcodebase-analysis.md).\n\n### Step 2: Generate render.yaml\n\nCreate a `render.yaml` Blueprint file following the Blueprint specification.\n\nComplete specification: [references\u002Fblueprint-spec.md](references\u002Fblueprint-spec.md)\n\n**Key Points:**\n- Always use `plan: free` unless user specifies otherwise\n- Include ALL environment variables the app needs\n- Mark secrets with `sync: false` (user fills these in Dashboard)\n- Use appropriate service type: `web`, `worker`, `cron`, `static`, or `pserv`\n- Use appropriate runtime: [references\u002Fruntimes.md](references\u002Fruntimes.md)\n\n**Basic Structure:**\n```yaml\nservices:\n  - type: web\n    name: my-app\n    runtime: node\n    plan: free\n    buildCommand: npm ci\n    startCommand: npm start\n    envVars:\n      - key: DATABASE_URL\n        fromDatabase:\n          name: postgres\n          property: connectionString\n      - key: JWT_SECRET\n        sync: false  # User fills in Dashboard\n\ndatabases:\n  - name: postgres\n    databaseName: myapp_db\n    plan: free\n```\n\n**Service Types:**\n- `web`: HTTP services, APIs, web applications (publicly accessible)\n- `worker`: Background job processors (not publicly accessible)\n- `cron`: Scheduled tasks that run on a cron schedule\n- `static`: Static sites (HTML\u002FCSS\u002FJS served via CDN)\n- `pserv`: Private services (internal only, within same account)\n\nService type details: [references\u002Fservice-types.md](references\u002Fservice-types.md)\nRuntime options: [references\u002Fruntimes.md](references\u002Fruntimes.md)\nTemplate examples: [assets\u002F](assets\u002F)\n\n### Step 2.5: Immediate Next Steps (Always Provide)\n\nAfter creating `render.yaml`, always give the user a short, explicit checklist and run validation immediately when the CLI is available:\n1. **Authenticate (CLI)**: run `render whoami -o json` (if not logged in, run `render login` or set `RENDER_API_KEY`)\n2. **Validate (recommended)**: run `render blueprints validate`\n   - If the CLI isn't installed, offer to install it and provide the command.\n3. **Commit + push**: `git add render.yaml && git commit -m \"Add Render deployment configuration\" && git push origin main`\n4. **Open Dashboard**: Use the Blueprint deeplink and complete Git OAuth if prompted\n5. **Fill secrets**: Set env vars marked `sync: false`\n6. **Deploy**: Click \"Apply\" and monitor the deploy\n\n### Step 3: Validate Configuration\n\nValidate the render.yaml file to catch errors before deployment. If the CLI is installed, run the commands directly; only prompt the user if the CLI is missing:\n\n```bash\nrender whoami -o json  # Ensure CLI is authenticated (won't always prompt)\nrender blueprints validate\n```\n\nFix any validation errors before proceeding. Common issues:\n- Missing required fields (`name`, `type`, `runtime`)\n- Invalid runtime values\n- Incorrect YAML syntax\n- Invalid environment variable references\n\nConfiguration guide: [references\u002Fconfiguration-guide.md](references\u002Fconfiguration-guide.md)\n\n### Step 4: Commit and Push\n\n**IMPORTANT:** You must merge the `render.yaml` file into your repository before deploying.\n\nEnsure the `render.yaml` file is committed and pushed to your Git remote:\n\n```bash\ngit add render.yaml\ngit commit -m \"Add Render deployment configuration\"\ngit push origin main\n```\n\nIf there is no Git remote yet, stop here and guide the user to create a GitHub\u002FGitLab\u002FBitbucket repo, add it as `origin`, and push before continuing.\n\n**Why this matters:** The Dashboard deeplink will read the render.yaml from your repository. If the file isn't merged and pushed, Render won't find the configuration and deployment will fail.\n\nVerify the file is in your remote repository before proceeding to the next step.\n\n### Step 5: Generate Deeplink\n\nGet the Git repository URL:\n\n```bash\ngit remote get-url origin\n```\n\nThis will return a URL from your Git provider. **If the URL is SSH format, convert it to HTTPS:**\n\n| SSH Format | HTTPS Format |\n|------------|--------------|\n| `git@github.com:user\u002Frepo.git` | `https:\u002F\u002Fgithub.com\u002Fuser\u002Frepo` |\n| `git@gitlab.com:user\u002Frepo.git` | `https:\u002F\u002Fgitlab.com\u002Fuser\u002Frepo` |\n| `git@bitbucket.org:user\u002Frepo.git` | `https:\u002F\u002Fbitbucket.org\u002Fuser\u002Frepo` |\n\n**Conversion pattern:** Replace `git@\u003Chost>:` with `https:\u002F\u002F\u003Chost>\u002F` and remove `.git` suffix.\n\nFormat the Dashboard deeplink using the HTTPS repository URL:\n```\nhttps:\u002F\u002Fdashboard.render.com\u002Fblueprint\u002Fnew?repo=\u003CREPOSITORY_URL>\n```\n\nExample:\n```\nhttps:\u002F\u002Fdashboard.render.com\u002Fblueprint\u002Fnew?repo=https:\u002F\u002Fgithub.com\u002Fusername\u002Frepo-name\n```\n\n### Step 6: Guide User\n\n**CRITICAL:** Ensure the user has merged and pushed the render.yaml file to their repository before clicking the deeplink. If the file isn't in the repository, Render cannot read the Blueprint configuration and deployment will fail.\n\nProvide the deeplink to the user with these instructions:\n\n1. **Verify render.yaml is merged** - Confirm the file exists in your repository on GitHub\u002FGitLab\u002FBitbucket\n2. Click the deeplink to open Render Dashboard\n3. Complete Git provider OAuth if prompted\n4. Name the Blueprint (or use default from render.yaml)\n5. Fill in secret environment variables (marked with `sync: false`)\n6. Review services and databases configuration\n7. Click \"Apply\" to deploy\n\nThe deployment will begin automatically. Users can monitor progress in the Render Dashboard.\n\n### Step 7: Verify Deployment\n\nAfter the user deploys via Dashboard, verify everything is working.\n\n**Check deployment status via MCP:**\n```\nlist_deploys(serviceId: \"\u003Cservice-id>\", limit: 1)\n```\nLook for `status: \"live\"` to confirm successful deployment.\n\n**Check for runtime errors (wait 2-3 minutes after deploy):**\n```\nlist_logs(resource: [\"\u003Cservice-id>\"], level: [\"error\"], limit: 20)\n```\n\n**Check service health metrics:**\n```\nget_metrics(\n  resourceId: \"\u003Cservice-id>\",\n  metricTypes: [\"http_request_count\", \"cpu_usage\", \"memory_usage\"]\n)\n```\n\nIf errors are found, proceed to the **Post-deploy verification and basic triage** section below.\n\n---\n\n# Method 2: Direct Service Creation (Quick Single-Service Deployments)\n\nFor simple deployments without Infrastructure-as-Code, create services directly via MCP tools.\n\n## When to Use Direct Creation\n\n- Single web service or static site\n- Quick prototypes or demos\n- When you don't need a render.yaml file in your repo\n- Adding databases or cron jobs to existing projects\n\n## Prerequisites for Direct Creation\n\n**Repository must be pushed to a Git provider.** Render clones your repository to build and deploy services.\n\n```bash\ngit remote -v  # Verify remote exists\ngit push origin main  # Ensure code is pushed\n```\n\nSupported providers: GitHub, GitLab, Bitbucket\n\nIf no remote exists, stop and ask the user to create\u002Fpush a remote or switch to Docker image deploy.\n\n**Note:** MCP does not support creating image-backed services. Use the Dashboard\u002FAPI for prebuilt Docker image deploys.\n\n## Direct Creation Workflow\n\nUse the concise steps below, and refer to [references\u002Fdirect-creation.md](references\u002Fdirect-creation.md) for full MCP command examples and follow-on configuration.\n\n### Step 1: Analyze Codebase\nUse [references\u002Fcodebase-analysis.md](references\u002Fcodebase-analysis.md) to determine runtime, build\u002Fstart commands, env vars, and datastores.\n\n### Step 2: Create Resources via MCP\nCreate the service (web or static) and any required databases or key-value stores. See [references\u002Fdirect-creation.md](references\u002Fdirect-creation.md).\n\nIf MCP returns an error about missing Git credentials or repo access, stop and guide the user to connect their Git provider in the Render Dashboard, then retry.\n\n### Step 3: Configure Environment Variables\nAdd required env vars via MCP after creation. See [references\u002Fdirect-creation.md](references\u002Fdirect-creation.md).\n\nRemind the user that secrets can be set in the Dashboard if they prefer not to pass them via MCP.\n\n### Step 4: Verify Deployment\nCheck deploy status, logs, and metrics. See [references\u002Fdirect-creation.md](references\u002Fdirect-creation.md).\n\n---\n\nFor service discovery, configuration details, quick commands, and common issues, see [references\u002Fdeployment-details.md](references\u002Fdeployment-details.md).\n\n---\n\n# Post-deploy verification and basic triage (All Methods)\n\nKeep this short and repeatable. If any check fails, fix it before redeploying.\n\n1. Confirm the latest deploy is `live` and serving traffic\n2. Hit the health endpoint (or root) and verify a 200 response\n3. Scan recent error logs for a clear failure signature\n4. Verify required env vars and port binding (`0.0.0.0:$PORT`)\n\nDetailed checklist and commands: [references\u002Fpost-deploy-checks.md](references\u002Fpost-deploy-checks.md)\n\nIf the service fails to start or health checks time out, use the basic triage guide:\n[references\u002Ftroubleshooting-basics.md](references\u002Ftroubleshooting-basics.md)\n\nOptional: If you need deeper diagnostics (metrics\u002FDB checks\u002Ferror catalog), suggest installing the\n`render-debug` skill. It is not required for the core deploy flow.\n","# Deploy to Render\n\nRender supports **Git-backed** services and **prebuilt Docker image** services.\n\nThis skill covers **Git-backed** flows:\n1. **Blueprint Method** - Generate render.yaml for Infrastructure-as-Code deployments\n2. **Direct Creation** - Create services instantly via MCP tools\n\nBlueprints can also run a **prebuilt Docker image** by using `runtime: image`, but the `render.yaml` still must live in a Git repo.\n\nIf there is no Git remote, stop and ask the user to either:\n- Create\u002Fpush a Git remote (can be minimal if only the Blueprint is needed), or\n- Use the Render Dashboard\u002FAPI to deploy a prebuilt Docker image (MCP cannot create image-backed services).\n\n## When to Use This Skill\n\nActivate this skill when users want to:\n- Deploy an application to Render\n- Create a render.yaml Blueprint file\n- Set up Render deployment for their project\n- Host or publish their application on Render's cloud platform\n- Create databases, cron jobs, or other Render resources\n\n## Happy Path (New Users)\n\nUse this short prompt sequence before deep analysis to reduce friction:\n1. Ask whether they want to deploy from a Git repo or a prebuilt Docker image.\n2. Ask whether Render should provision everything the app needs (based on what seems likely from the user's description) or only the app while they bring their own infra. If dependencies are unclear, ask a short follow-up to confirm whether they need a database, workers, cron, or other services.\n\nThen proceed with the appropriate method below.\n\n## Choose Your Source Path\n\n**Git Repo Path:** Required for both Blueprint and Direct Creation. The repo must be pushed to GitHub, GitLab, or Bitbucket.\n\n**Prebuilt Docker Image Path:** Supported by Render via image-backed services. This is **not** supported by MCP; use the Dashboard\u002FAPI. Ask for:\n- Image URL (registry + tag)\n- Registry auth (if private)\n- Service type (web\u002Fworker) and port\n\nIf the user chooses a Docker image, guide them to the Render Dashboard image deploy flow or ask them to add a Git remote (so you can use a Blueprint with `runtime: image`).\n\n## Choose Your Deployment Method (Git Repo)\n\nBoth methods require a Git repository pushed to GitHub, GitLab, or Bitbucket. (If using `runtime: image`, the repo can be minimal and only contain `render.yaml`.)\n\n| Method | Best For | Pros |\n|--------|----------|------|\n| **Blueprint** | Multi-service apps, IaC workflows | Version controlled, reproducible, supports complex setups |\n| **Direct Creation** | Single services, quick deployments | Instant creation, no render.yaml file needed |\n\n### Method Selection Heuristic\n\nUse this decision rule by default unless the user requests a specific method. Analyze the codebase first; only ask if deployment intent is unclear (e.g., DB, workers, cron).\n\n**Use Direct Creation (MCP) when ALL are true:**\n- Single service (one web app or one static site)\n- No separate worker\u002Fcron services\n- No attached databases or Key Value\n- Simple env vars only (no shared env groups)\nIf this path fits and MCP isn't configured yet, stop and guide MCP setup before proceeding.\n\n**Use Blueprint when ANY are true:**\n- Multiple services (web + worker, API + frontend, etc.)\n- Databases, Redis\u002FKey Value, or other datastores are required\n- Cron jobs, background workers, or private services\n- You want reproducible IaC or a render.yaml committed to the repo\n- Monorepo or multi-env setup that needs consistent configuration\n\nIf unsure, ask a quick clarifying question, but default to Blueprint for safety. For a single service, strongly prefer Direct Creation via MCP and guide MCP setup if needed.\n\n## Prerequisites Check\n\nWhen starting a deployment, verify these requirements in order:\n\n**1. Confirm Source Path (Git vs Docker)**\n\nIf using Git-based methods (Blueprint or Direct Creation), the repo must be pushed to GitHub\u002FGitLab\u002FBitbucket. Blueprints that reference a prebuilt image still require a Git repo with `render.yaml`.\n\n```bash\ngit remote -v\n```\n\n- If no remote exists, stop and ask the user to create\u002Fpush a remote **or** switch to Docker image deploy.\n\n**2. Check MCP Tools Availability (Preferred for Single-Service)**\n\nMCP tools provide the best experience. Check if available by attempting:\n```\nlist_services()\n```\n\nIf MCP tools are available, you can skip CLI installation for most operations.\n\n**3. Check Render CLI Installation (for Blueprint validation)**\n```bash\nrender --version\n```\nIf not installed, offer to install:\n- macOS: `brew install render`\n- Linux\u002FmacOS: `curl -fsSL https:\u002F\u002Fraw.githubusercontent.com\u002Frender-oss\u002Fcli\u002Fmain\u002Fbin\u002Finstall.sh | sh`\n\n**4. MCP Setup (if MCP isn't configured)**\n\nIf `list_services()` fails, set up the Render MCP server. For detailed per-tool walkthroughs, see **render-mcp**.\n\n**Quick setup:** Add the Render MCP server to your AI tool's MCP config:\n- **URL:** `https:\u002F\u002Fmcp.render.com\u002Fmcp`\n- **Auth header:** `Authorization: Bearer \u003CYOUR_API_KEY>`\n- **API key:** `https:\u002F\u002Fdashboard.render.com\u002Fu\u002F*\u002Fsettings#api-keys`\n\nAfter configuring, restart your tool and retry `list_services()`. Then set your workspace with `list_workspaces()` \u002F `get_selected_workspace()`.\n\n**5. Check Authentication (CLI fallback only)**\n\nIf MCP isn't available, use the CLI instead and verify you can access your account:\n```bash\n# Check if user is logged in (use -o json for non-interactive mode)\nrender whoami -o json\n```\n\nIf `render whoami` fails or returns empty data, the CLI is not authenticated. The CLI won't always prompt automatically, so explicitly prompt the user to authenticate:\n\nIf neither is configured, ask user which method they prefer:\n- **API Key (CLI)**: `export RENDER_API_KEY=\"rnd_xxxxx\"` (Get from https:\u002F\u002Fdashboard.render.com\u002Fu\u002F*\u002Fsettings#api-keys)\n- **Login**: `render login` (Opens browser for OAuth)\n\n**6. Check Workspace Context**\n\nVerify the active workspace:\n```\nget_selected_workspace()\n```\n\nOr via CLI:\n```bash\nrender workspace current -o json\n```\n\nTo list available workspaces:\n```\nlist_workspaces()\n```\n\nIf user needs to switch workspaces, they must do so via Dashboard or CLI (`render workspace set`).\n\nOnce prerequisites are met, proceed with deployment workflow.\n\n---\n\n# Method 1: Blueprint Deployment (Recommended for Complex Apps)\n\n## Blueprint Workflow\n\n### Step 1: Analyze Codebase\n\nAnalyze the codebase to determine framework\u002Fruntime, build and start commands, required env vars, datastores, and port binding. Use the detailed checklists in [references\u002Fcodebase-analysis.md](references\u002Fcodebase-analysis.md).\n\n### Step 2: Generate render.yaml\n\nCreate a `render.yaml` Blueprint file following the Blueprint specification.\n\nComplete specification: [references\u002Fblueprint-spec.md](references\u002Fblueprint-spec.md)\n\n**Key Points:**\n- Always use `plan: free` unless user specifies otherwise\n- Include ALL environment variables the app needs\n- Mark secrets with `sync: false` (user fills these in Dashboard)\n- Use appropriate service type: `web`, `worker`, `cron`, `static`, or `pserv`\n- Use appropriate runtime: [references\u002Fruntimes.md](references\u002Fruntimes.md)\n\n**Basic Structure:**\n```yaml\nservices:\n  - type: web\n    name: my-app\n    runtime: node\n    plan: free\n    buildCommand: npm ci\n    startCommand: npm start\n    envVars:\n      - key: DATABASE_URL\n        fromDatabase:\n          name: postgres\n          property: connectionString\n      - key: JWT_SECRET\n        sync: false  # User fills in Dashboard\n\ndatabases:\n  - name: postgres\n    databaseName: myapp_db\n    plan: free\n```\n\n**Service Types:**\n- `web`: HTTP services, APIs, web applications (publicly accessible)\n- `worker`: Background job processors (not publicly accessible)\n- `cron`: Scheduled tasks that run on a cron schedule\n- `static`: Static sites (HTML\u002FCSS\u002FJS served via CDN)\n- `pserv`: Private services (internal only, within same account)\n\nService type details: [references\u002Fservice-types.md](references\u002Fservice-types.md)\nRuntime options: [references\u002Fruntimes.md](references\u002Fruntimes.md)\nTemplate examples: [assets\u002F](assets\u002F)\n\n### Step 2.5: Immediate Next Steps (Always Provide)\n\nAfter creating `render.yaml`, always give the user a short, explicit checklist and run validation immediately when the CLI is available:\n1. **Authenticate (CLI)**: run `render whoami -o json` (if not logged in, run `render login` or set `RENDER_API_KEY`)\n2. **Validate (recommended)**: run `render blueprints validate`\n   - If the CLI isn't installed, offer to install it and provide the command.\n3. **Commit + push**: `git add render.yaml && git commit -m \"Add Render deployment configuration\" && git push origin main`\n4. **Open Dashboard**: Use the Blueprint deeplink and complete Git OAuth if prompted\n5. **Fill secrets**: Set env vars marked `sync: false`\n6. **Deploy**: Click \"Apply\" and monitor the deploy\n\n### Step 3: Validate Configuration\n\nValidate the render.yaml file to catch errors before deployment. If the CLI is installed, run the commands directly; only prompt the user if the CLI is missing:\n\n```bash\nrender whoami -o json  # Ensure CLI is authenticated (won't always prompt)\nrender blueprints validate\n```\n\nFix any validation errors before proceeding. Common issues:\n- Missing required fields (`name`, `type`, `runtime`)\n- Invalid runtime values\n- Incorrect YAML syntax\n- Invalid environment variable references\n\nConfiguration guide: [references\u002Fconfiguration-guide.md](references\u002Fconfiguration-guide.md)\n\n### Step 4: Commit and Push\n\n**IMPORTANT:** You must merge the `render.yaml` file into your repository before deploying.\n\nEnsure the `render.yaml` file is committed and pushed to your Git remote:\n\n```bash\ngit add render.yaml\ngit commit -m \"Add Render deployment configuration\"\ngit push origin main\n```\n\nIf there is no Git remote yet, stop here and guide the user to create a GitHub\u002FGitLab\u002FBitbucket repo, add it as `origin`, and push before continuing.\n\n**Why this matters:** The Dashboard deeplink will read the render.yaml from your repository. If the file isn't merged and pushed, Render won't find the configuration and deployment will fail.\n\nVerify the file is in your remote repository before proceeding to the next step.\n\n### Step 5: Generate Deeplink\n\nGet the Git repository URL:\n\n```bash\ngit remote get-url origin\n```\n\nThis will return a URL from your Git provider. **If the URL is SSH format, convert it to HTTPS:**\n\n| SSH Format | HTTPS Format |\n|------------|--------------|\n| `git@github.com:user\u002Frepo.git` | `https:\u002F\u002Fgithub.com\u002Fuser\u002Frepo` |\n| `git@gitlab.com:user\u002Frepo.git` | `https:\u002F\u002Fgitlab.com\u002Fuser\u002Frepo` |\n| `git@bitbucket.org:user\u002Frepo.git` | `https:\u002F\u002Fbitbucket.org\u002Fuser\u002Frepo` |\n\n**Conversion pattern:** Replace `git@\u003Chost>:` with `https:\u002F\u002F\u003Chost>\u002F` and remove `.git` suffix.\n\nFormat the Dashboard deeplink using the HTTPS repository URL:\n```\nhttps:\u002F\u002Fdashboard.render.com\u002Fblueprint\u002Fnew?repo=\u003CREPOSITORY_URL>\n```\n\nExample:\n```\nhttps:\u002F\u002Fdashboard.render.com\u002Fblueprint\u002Fnew?repo=https:\u002F\u002Fgithub.com\u002Fusername\u002Frepo-name\n```\n\n### Step 6: Guide User\n\n**CRITICAL:** Ensure the user has merged and pushed the render.yaml file to their repository before clicking the deeplink. If the file isn't in the repository, Render cannot read the Blueprint configuration and deployment will fail.\n\nProvide the deeplink to the user with these instructions:\n\n1. **Verify render.yaml is merged** - Confirm the file exists in your repository on GitHub\u002FGitLab\u002FBitbucket\n2. Click the deeplink to open Render Dashboard\n3. Complete Git provider OAuth if prompted\n4. Name the Blueprint (or use default from render.yaml)\n5. Fill in secret environment variables (marked with `sync: false`)\n6. Review services and databases configuration\n7. Click \"Apply\" to deploy\n\nThe deployment will begin automatically. Users can monitor progress in the Render Dashboard.\n\n### Step 7: Verify Deployment\n\nAfter the user deploys via Dashboard, verify everything is working.\n\n**Check deployment status via MCP:**\n```\nlist_deploys(serviceId: \"\u003Cservice-id>\", limit: 1)\n```\nLook for `status: \"live\"` to confirm successful deployment.\n\n**Check for runtime errors (wait 2-3 minutes after deploy):**\n```\nlist_logs(resource: [\"\u003Cservice-id>\"], level: [\"error\"], limit: 20)\n```\n\n**Check service health metrics:**\n```\nget_metrics(\n  resourceId: \"\u003Cservice-id>\",\n  metricTypes: [\"http_request_count\", \"cpu_usage\", \"memory_usage\"]\n)\n```\n\nIf errors are found, proceed to the **Post-deploy verification and basic triage** section below.\n\n---\n\n# Method 2: Direct Service Creation (Quick Single-Service Deployments)\n\nFor simple deployments without Infrastructure-as-Code, create services directly via MCP tools.\n\n## When to Use Direct Creation\n\n- Single web service or static site\n- Quick prototypes or demos\n- When you don't need a render.yaml file in your repo\n- Adding databases or cron jobs to existing projects\n\n## Prerequisites for Direct Creation\n\n**Repository must be pushed to a Git provider.** Render clones your repository to build and deploy services.\n\n```bash\ngit remote -v  # Verify remote exists\ngit push origin main  # Ensure code is pushed\n```\n\nSupported providers: GitHub, GitLab, Bitbucket\n\nIf no remote exists, stop and ask the user to create\u002Fpush a remote or switch to Docker image deploy.\n\n**Note:** MCP does not support creating image-backed services. Use the Dashboard\u002FAPI for prebuilt Docker image deploys.\n\n## Direct Creation Workflow\n\nUse the concise steps below, and refer to [references\u002Fdirect-creation.md](references\u002Fdirect-creation.md) for full MCP command examples and follow-on configuration.\n\n### Step 1: Analyze Codebase\nUse [references\u002Fcodebase-analysis.md](references\u002Fcodebase-analysis.md) to determine runtime, build\u002Fstart commands, env vars, and datastores.\n\n### Step 2: Create Resources via MCP\nCreate the service (web or static) and any required databases or key-value stores. See [references\u002Fdirect-creation.md](references\u002Fdirect-creation.md).\n\nIf MCP returns an error about missing Git credentials or repo access, stop and guide the user to connect their Git provider in the Render Dashboard, then retry.\n\n### Step 3: Configure Environment Variables\nAdd required env vars via MCP after creation. See [references\u002Fdirect-creation.md](references\u002Fdirect-creation.md).\n\nRemind the user that secrets can be set in the Dashboard if they prefer not to pass them via MCP.\n\n### Step 4: Verify Deployment\nCheck deploy status, logs, and metrics. See [references\u002Fdirect-creation.md](references\u002Fdirect-creation.md).\n\n---\n\nFor service discovery, configuration details, quick commands, and common issues, see [references\u002Fdeployment-details.md](references\u002Fdeployment-details.md).\n\n---\n\n# Post-deploy verification and basic triage (All Methods)\n\nKeep this short and repeatable. If any check fails, fix it before redeploying.\n\n1. Confirm the latest deploy is `live` and serving traffic\n2. Hit the health endpoint (or root) and verify a 200 response\n3. Scan recent error logs for a clear failure signature\n4. Verify required env vars and port binding (`0.0.0.0:$PORT`)\n\nDetailed checklist and commands: [references\u002Fpost-deploy-checks.md](references\u002Fpost-deploy-checks.md)\n\nIf the service fails to start or health checks time out, use the basic triage guide:\n[references\u002Ftroubleshooting-basics.md](references\u002Ftroubleshooting-basics.md)\n\nOptional: If you need deeper diagnostics (metrics\u002FDB checks\u002Ferror catalog), suggest installing the\n`render-debug` skill. It is not required for the core deploy flow.\n",{"name":5,"license":14,"metadata":23,"description":7,"compatibility":27},{"author":24,"version":25,"category":26},"Render","1.1.0","deployment","Requires a Git repository on GitHub, GitLab, or Bitbucket for Blueprint\u002FMCP flows. Blueprint can reference a prebuilt image but render.yaml must live in the repo. Render CLI recommended for Blueprint validation; MCP or CLI required for operations.","main","1eb986d0b0ecc180291597e08eb5a58288843536","skills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy","https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills","https:\u002F\u002Fgithub.com\u002Fvikasvardhanv","2026-08-25 13:16:33",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add vikasvardhanv\u002Fjerry_skills --skill render-deploy",{"tool":40,"command":41},"bunx","bunx skills add vikasvardhanv\u002Fjerry_skills --skill render-deploy",{"tool":43,"command":44},"pnpm","pnpm dlx skills add vikasvardhanv\u002Fjerry_skills --skill render-deploy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002FSKILL.md",true,[48,54,60,64,68,72,76,80,84,88,92,96,100,104,108,112,116,120],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"agents\u002Fopenai.yaml","REFERENCE","参考文档",264,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Fagents\u002Fopenai.yaml",{"path":55,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":58,"sourceHtmlUrl":59},"assets\u002Fdocker.yaml","ASSET","资产文件",1398,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Fassets\u002Fdocker.yaml",{"path":61,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":62,"sourceHtmlUrl":63},"assets\u002Fgo-api.yaml",848,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Fassets\u002Fgo-api.yaml",{"path":65,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":66,"sourceHtmlUrl":67},"assets\u002Flogo.svg",1894,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Fassets\u002Flogo.svg",{"path":69,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":70,"sourceHtmlUrl":71},"assets\u002Fnextjs-postgres.yaml",870,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Fassets\u002Fnextjs-postgres.yaml",{"path":73,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":74,"sourceHtmlUrl":75},"assets\u002Fnode-express.yaml",619,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Fassets\u002Fnode-express.yaml",{"path":77,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":78,"sourceHtmlUrl":79},"assets\u002Fpython-django.yaml",2538,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Fassets\u002Fpython-django.yaml",{"path":81,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":82,"sourceHtmlUrl":83},"assets\u002Fstatic-site.yaml",1352,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Fassets\u002Fstatic-site.yaml",{"path":85,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fblueprint-spec.md",16013,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Freferences\u002Fblueprint-spec.md",{"path":89,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fcodebase-analysis.md",2300,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Freferences\u002Fcodebase-analysis.md",{"path":93,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fconfiguration-guide.md",11735,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Freferences\u002Fconfiguration-guide.md",{"path":97,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fdeployment-details.md",5345,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Freferences\u002Fdeployment-details.md",{"path":101,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fdirect-creation.md",2786,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Freferences\u002Fdirect-creation.md",{"path":105,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Ferror-patterns.md",833,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Freferences\u002Ferror-patterns.md",{"path":109,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Fpost-deploy-checks.md",1025,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Freferences\u002Fpost-deploy-checks.md",{"path":113,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Fruntimes.md",9849,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Freferences\u002Fruntimes.md",{"path":117,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":118,"sourceHtmlUrl":119},"references\u002Fservice-types.md",11338,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Freferences\u002Fservice-types.md",{"path":121,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":122,"sourceHtmlUrl":123},"references\u002Ftroubleshooting-basics.md",1361,"https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fopenai\u002Fplugins\u002Frender\u002Fskills\u002Frender-deploy\u002Freferences\u002Ftroubleshooting-basics.md",[125,132,139,146,153,160],{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":18},"01M7BESR1CJ3H5SP9XM8KYJZ9W","syllabus","Generates a curated supplementary reading list from any course syllabus using Consensus academic search. Grill-me intake (syllabus input format + course audience + year range) plus a grouping forcing-options checkpoint before any search runs — so the reading list matches the course's level and recency need. Parses the syllabus to extract topics and learning outcomes, searches Consensus for recent peer-reviewed papers per topic, and produces a professionally formatted .docx with clickable Consensus links, plain-language summaries calibrated to audience level, and Bloom-higher-order discussion questions tied to course learning goals. Use when the user uploads a syllabus, course outline, or curriculum document and wants supplementary readings (e.g., 'create a reading list from this syllabus', 'find recent papers for my course') — even casual mentions with a syllabus attached should trigger this skill.","https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fresearch\u002Fsyllabus\u002Fskills\u002Fsyllabus\u002FSKILL.md",[],[],{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":18},"01M7BES1YA6R97W7QPMFFM1PED","pulse","Multi-source recency research skill that takes the pulse of any topic across Reddit, Hacker News, the open web, and optionally X\u002FTwitter within a configurable recent window (default 30 days). Forcing intake clarifies topic specificity, angle (trend\u002Fsentiment\u002Fproblems\u002Fopportunities\u002Fcomparison), time window, and platform scope before searching. Returns a synthesized briefing with citations, engagement metrics, and cross-platform pattern analysis. Use when the user requests multi-source recency intelligence on a topic (e.g., 'pulse on [topic]', 'what's happening with [topic]', 'what are people saying about [topic]', 'current conversation about [topic]', 'take the pulse of [topic]', 'trending: [topic]', 'find me info on [topic]'), and for competitor research, trend discovery, tool comparisons, and audience sentiment analysis.","https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fresearch\u002Fpulse\u002Fskills\u002Fpulse\u002FSKILL.md",[],[],{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":18},"01M7BERNHYGY035AR00VRT03KE","patent","Patent prior-art and landscape intelligence skill — not generic patent help. Commits to one of five sub-use-cases via forcing intake (novelty search \u002F freedom-to-operate \u002F competitive landscape \u002F acquisition diligence \u002F litigation prior-art) before any search runs. Searches Google Patents, Espacenet, USPTO, and optionally Lens.org for citation-graph signals. Output is an editable Word document (.docx) with verdict, ranked closest art (claim-text extracted), CPC-class-aware landscape, family-resolved hits, geographic coverage, FTO flags where applicable, strategy recommendations, and full audit log. Use when the user asks for patent searching or analysis (e.g., 'prior art search for [invention]', 'freedom to operate analysis for [product]'). Produces search signal, not legal advice — always recommends consulting a patent attorney before filing or licensing decisions. Trademark, copyright, and trade-secret questions are out of scope.","https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fresearch\u002Fpatent\u002Fskills\u002Fpatent\u002FSKILL.md",[],[],{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":18},"01M7BERCK1EAKTWW7R436WAR0J","notebooklm","Browser automation skill for controlling Google's NotebookLM. Use when the user wants anything done in NotebookLM (e.g., 'open NotebookLM', 'check my [name] notebook', 'ask my notebook about X', 'add [source] to NotebookLM', 'generate a Video Overview from my notebook', 'use NotebookLM Studio'). Handles reading and querying notebooks, adding sources (URLs, text, files, YouTube links, synthesized content), generating Studio outputs (Audio\u002FVideo Overviews, Mind Maps, Reports incl. Briefing Doc\u002FStudy Guide\u002FFAQ, Flashcards, Quiz, slide decks, infographics — discover the exact set from the live Studio panel; the UI evolves fast), and creating new notebooks. Requires browser automation environment — fails gracefully when unavailable.","https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fresearch\u002Fnotebooklm\u002Fskills\u002Fnotebooklm\u002FSKILL.md",[],[],{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":18},"01M7BEQZAZAQRTXFJRY7RHV3TY","litreview","Academic literature orientation skill that searches papers via free keyless APIs (PubMed E-utilities + OpenAlex) by default — with the Consensus MCP as an optional enhancement lane when connected — builds a strategic search plan using PICO (default) or SPIDER \u002F Decomposition \u002F hybrid as fallbacks, and synthesizes findings into a formatted Word (.docx) research guide. Grill-me intake (research question specificity + framework hint + tentative depth) before the recon search; a second forcing checkpoint after Phase 2 confirms framework + sub-areas + depth before searches consume budget. Configurable depth (5\u002F10\u002F20 queries) controls coverage vs. speed. Output is a 'launching pad' — an orientation guide that lets a researcher dive in confidently, not a finished review. Use when the user starts literature-oriented research (e.g., 'litreview on [topic]', 'literature review on [topic]', 'I'm starting a literature review on X', 'I'm writing a paper on X', 'help me research X', 'I'm doing research on X', 'can you help me research X'). Do NOT use for single one-off paper searches wanting a quick list — that's a plain PubMed\u002FOpenAlex (or Consensus) query.","https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fresearch\u002Flitreview\u002Fskills\u002Flitreview\u002FSKILL.md",[],[],{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":18},"01M7BEQKJ45K31QK5VRAQSVJCJ","grants","NIH grant research skill for clinical researchers. Grill-me intake (research idea + career stage + preliminary data + environment + submission posture + known institute targets) locks down the funding strategy before any search runs. Runs a 5-facet Consensus positioning analysis (with draft Significance\u002FInnovation language), maps the research to the right NIH institutes and study sections via RePORTER, finds NOSIs and funded overlap, and produces an editable Word document (.docx) with budget\u002Fscope-aware mechanism recommendations, submission timelines, and a mandatory program officer recommendation. Use when the user asks about research funding or makes any grant-related request (e.g., 'grants for [topic]', 'find grants for my research idea', 'what grants match my research', 'help me find NIH funding', 'grant opportunities for my research'). NIH-only scope — non-NIH funders (PCORI, DOD CDMRP, VA, foundations) are out of scope and flagged at intake.","https:\u002F\u002Fgithub.com\u002Fvikasvardhanv\u002Fjerry_skills\u002Fblob\u002Fmain\u002Fskills\u002Fresearch\u002Fgrants\u002Fskills\u002Fgrants\u002FSKILL.md",[],[]]