2 posts tagged with "vercel"

Meta description: Vercel released an open CLI that lets you install reusable "skills" into any AI coding agent — Claude Code, Cursor, Copilot, and 40+ more. Here's why it matters and how to use it.

The Problem: Every Agent Starts From Zero​

If you've used more than one AI coding agent — Claude Code, Cursor, Copilot, Windsurf, Codex — you've probably noticed something annoying: each one needs its own setup. Your carefully crafted instructions, tool configurations, and workflow rules don't transfer. Switch agents, start over.

And if you're a team? Multiply that pain. Every developer configures their own agent differently. Consistency is a pipe dream.

This is the problem Vercel's skills CLI was built to solve.

What Is Vercel Skills?​

Vercel Labs released an open-source CLI (15.5k ⭐ and climbing) that does for AI agents what npm did for JavaScript packages:

npx skills add vercel-labs/agent-skills

One command. That's it. The CLI pulls skill definitions from any GitHub repo and installs them into your coding agent's config directory.

A "skill" is just a SKILL.md file with YAML frontmatter — a name, a description, and instructions the agent follows when that skill is relevant. Think of it as a reusable prompt template that any supported agent can understand.

Why This Actually Matters​

1. Cross-Agent Portability​

The CLI supports 43+ coding agents out of the box — Claude Code, Cursor, GitHub Copilot, OpenClaw, Gemini CLI, Windsurf, Codex, Cline, Amp, and dozens more. Each agent stores skills in a different directory (.claude/skills/, .cursor/skills/, .copilot/skills/, etc.). The CLI handles the mapping automatically.

Install once, use everywhere. Your team can standardize on specific skills regardless of which agent each developer prefers.

2. The Shared Specification​

Skills follow the Agent Skills specification — a standardized format that any agent can adopt. This isn't a Vercel-only thing. It's an open ecosystem where:

• Anyone can create skills (just a SKILL.md in a repo)
• Anyone can publish skills (push to GitHub)
• Anyone can discover skills (via skills.sh)

The spec is deliberately simple: YAML frontmatter for metadata, Markdown for instructions. No build step, no compilation, no vendor lock-in.

3. Discovery and Distribution​

The skills.sh directory already lists skills from Microsoft Azure (4.4M+ installs), marketing skill packs, Convex integration skills, and hundreds of community contributions. It's early, but the growth curve looks familiar — much like npm's early days.

How It Works In Practice​

Installing Skills​

# From a GitHub repo
npx skills add vercel-labs/agent-skills

# A specific skill from a repo
npx skills add vercel-labs/agent-skills --skill frontend-design

# Install globally (available across all projects)
npx skills add vercel-labs/agent-skills -g

# Target specific agents
npx skills add vercel-labs/agent-skills -a claude-code -a cursor

Managing Skills​

# List what's installed
npx skills list

# Search for skills
npx skills find typescript

# Update to latest
npx skills update

# Create your own
npx skills init my-skill

Creating a Skill​

A skill is just a directory with a SKILL.md:

---
name: deploy-to-vercel
description: Deploys the current project to Vercel with proper env vars and preview URLs
---

# Deploy to Vercel

## When to Use
When the user asks to deploy or preview the project.

## Steps
1. Check for vercel.json or next.config
2. Run `vercel --prod` for production or `vercel` for preview
3. Share the deployment URL with the user

Push it to GitHub, and anyone can install it with npx skills add your-username/your-repo.

The Bigger Picture: Agent Infrastructure Is Maturing​

Vercel Skills isn't happening in isolation. It's part of a broader shift:

• MCP (Model Context Protocol) standardized how agents connect to external tools
• Agent Skills standardizes how agents acquire procedural knowledge
• Skills directories (like skills.sh) create a distribution layer

Together, these form the infrastructure layer that turns AI coding agents from "smart autocomplete" into "extensible development platforms."

The analogy to npm is intentional and instructive. npm didn't just make it easy to install packages — it created an ecosystem where small, composable modules could be shared, versioned, and combined. Agent skills are heading in the same direction.

What This Means for Developers​

If you're a solo developer: Stop rewriting the same agent instructions across projects. Package them as skills and install them everywhere.

If you're on a team: Create org-level skill repos. Standardize how your agents handle code review, deployment, testing, and documentation. New team members get consistent agent behavior from day one.

If you're building agent-powered tools: Adopt the Agent Skills spec. Your users can leverage the entire ecosystem instead of starting from scratch.

If you're a startup founder: Pay attention to how agent infrastructure is standardizing. The skills ecosystem is where the "plugin marketplaces" for AI agents will emerge. Being early means shaping the standards.

Getting Started​

# Browse available skills
npx skills find

# Install Vercel's official skill pack
npx skills add vercel-labs/agent-skills --all

# Create your first skill
npx skills init

The CLI is open source (MIT license), lightweight, and works with zero config. If you're already using an AI coding agent, there's no reason not to try it.

FAQ​

Q: What's the difference between a skill and a system prompt? A: A system prompt is global and static — it applies to every interaction. A skill is modular, activatable based on context, and can be shared across agents and teams. Think of system prompts as your bash profile, and skills as npm packages you install as needed.

Q: Do skills work with all AI coding agents? A: The CLI supports 43+ agents including Claude Code, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Codex, Cline, OpenClaw, and more. Basic skills (SKILL.md with instructions) work universally across all of them. Advanced features like allowed-tools and hooks are agent-specific.

Q: Can I create private skills for my team? A: Yes. You can install skills from private GitHub repos (if you have access), local paths, or any Git URL. Use npx skills add ./my-team-skills for local-only skills, or point to your private repo.

Q: Is this only for coding agents? A: Right now, yes — the ecosystem is focused on coding agents. But the SKILL.md format is general-purpose. As AI agents expand beyond coding (research agents, data agents, creative agents), the same specification could apply. The infrastructure is agent-agnostic; the current adoption is dev-tool-centric.

About the Author​

Arkin Julijanto is a startup founder and developer building Orbits Studio. He writes about AI tools, developer productivity, and the evolving agent ecosystem at arkin-dev.com.

Meta Description: Vercel confirmed a security breach via third-party OAuth compromise. Here's what every developer and founder needs to know about protecting their secrets and supply chain attacks.

The Wake-Up Call Every Founder Needed​

On April 19, 2026, Vercel—one of the most critical infrastructure platforms for modern web development—disclosed a security breach that should send shivers down every founder's spine. The attack wasn't some sophisticated zero-day exploit. It was a textbook supply-chain attack via a compromised OAuth application.

Think about it: one compromised Google Workspace account at a third-party AI tool (Context.ai) led to unauthorized access to Vercel's internal systems. The attacker didn't need to break Vercel's encryption or bypass their defenses—they walked in through a side door that no one thought to lock.

If you're deploying on Vercel, running a startup, or managing any cloud infrastructure, you need to understand what happened, why it matters, and what you should do right now.

How the Attack Unfolded: A Supply Chain Nightmare​

The breach began when a Vercel employee's Google Workspace account was compromised through Context.ai, a third-party AI platform. The attacker gained access via a malicious OAuth application:

OAuth App: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

From there, the attacker escalated their access within Vercel's internal systems. Here's where it gets interesting: they discovered environment variables that weren't marked as "sensitive" in Vercel's system.

Vercel has a feature to designate environment variables as sensitive, which ensures they're encrypted at rest. But variables marked as non-sensitive—the ones intended for configuration data—were stored unencrypted. The attacker enumerated these variables and used them to gain further access.

This is a classic privilege escalation attack disguised as a configuration issue. The problem wasn't that Vercel failed to encrypt sensitive data—they did. The problem was that what developers thought was "non-sensitive" configuration data turned out to be a pathway to deeper access.

Why This Attack Is So Dangerous​

This breach exposes a fundamental vulnerability in how we think about third-party integrations and OAuth security:

1. The Trust Chain Problem

We implicitly trust OAuth applications. When we click "Authorize" on a third-party tool, we're granting access to our Google Workspace, GitHub, or other accounts. If that tool is compromised, the attacker inherits all the access we've granted.

2. The Configuration Blind Spot

Developers often treat environment variables as either "sensitive" (API keys, database passwords) or "non-sensitive" (API endpoints, feature flags). But configuration data can be just as valuable—internal service URLs, project identifiers, and deployment targets can reveal a system's architecture.

3. The Supply Chain Ripple Effect

A breach at one third-party vendor (Context.ai) compromised a major platform (Vercel), which potentially exposed countless applications deployed by Vercel's customers. The attack surface expands exponentially through the supply chain.

What You Should Do Right Now​

If you're deploying on Vercel or using similar cloud platforms, here's your immediate action list:

1. Rotate All Secrets​

This is non-negotiable. Even if Vercel says you're not affected, assume you might be. Rotate:

• Database credentials
• API keys (Stripe, OpenAI, Twilio, etc.)
• OAuth tokens
• Private keys
• Any secret stored in environment variables

2. Review Your OAuth Permissions​

Go to your Google Workspace, GitHub, and other OAuth providers. Review every third-party application with access. Revoke anything you don't recognize or no longer use.

3. Audit Your Environment Variables​

Log into Vercel (or your platform of choice) and review every environment variable:

• Mark anything that could be used for access as "sensitive"
• Remove unused variables
• Audit the values—look for internal URLs, project IDs, or identifiers that could aid an attacker

4. Enable Vercel's Sensitive Variable Feature​

Vercel has a feature that encrypts sensitive environment variables at rest. Use it. For any variable that contains secrets, authentication data, or internal infrastructure details, mark it as sensitive.

5. Implement Secret Rotation Policies​

Don't wait for a breach. Rotate secrets regularly—every 90 days for high-risk credentials, every 6 months for others. Automate this where possible.

The Bigger Lesson: Defense in Depth Is Non-Negotiable​

Vercel did a lot of things right: they had encryption for sensitive data, defense-in-depth mechanisms, and a rapid incident response. But the attack still succeeded because one layer of defense—OAuth application security—was outsourced to a third party.

This is why security best practices matter:

• Zero Trust: Never assume any component is safe, even if it's from a trusted vendor
• Least Privilege: Grant the minimum access necessary
• Audit Regularly: You can't protect what you don't know about
• Assume Breach: Design your systems assuming an attacker already has some access

What Vercel Is Doing Right​

To Vercel's credit, they've handled this well:

• Immediate disclosure and transparent communication
• Clear guidance for affected customers
• Rolling out security updates (new environment variable overview, improved sensitive variable management)
• Confirmation that open-source projects (Next.js, Turbopack) remain safe

This is how security incidents should be handled. No hiding, no deflection—just facts, guidance, and action.

The Future of Cloud Security​

This breach isn't unique to Vercel. It could happen to any platform that relies on OAuth integrations. As we build more interconnected systems, the attack surface grows.

The future of cloud security lies in:

• OAuth hardening: More granular permissions, better auditing, automated revocation
• Secret management: Dedicated secret managers (AWS Secrets Manager, HashiCorp Vault) instead of environment variables
• Supply chain security: Security reviews for every third-party integration
• Automated rotation: Tools that automatically rotate secrets before they can be exploited

Conclusion​

The Vercel breach is a wake-up call, not a reason to abandon cloud development. The platform remains one of the best options for deploying modern applications—but this incident reminds us that security is a process, not a product.

Rotate your secrets. Review your OAuth apps. Audit your environment variables. And never assume that "non-sensitive" means "harmless."

The attacker didn't exploit a bug in Vercel's code—they exploited a blind spot in how we think about security. Close that blind spot before someone else walks through it.

FAQ Section​

Q: Was my Vercel project affected by the breach? A: Vercel states that only a "limited subset of customers" were affected. However, if you're not sure, the safest approach is to rotate all your secrets as a precaution.

Q: What's the difference between sensitive and non-sensitive environment variables in Vercel? A: Sensitive environment variables are encrypted at rest and have additional protections. Non-sensitive variables are stored unencrypted and intended for configuration data—but they can still contain valuable information for attackers.

Q: How often should I rotate my API keys and secrets? A: High-risk credentials (database passwords, production API keys) should be rotated every 90 days. Lower-risk credentials can be rotated every 6 months. Automate this process where possible.

Q: Is it safe to keep using Vercel after this breach? A: Yes. Vercel has responded transparently, patched the vulnerability, and implemented additional security measures. No platform is immune to attacks—what matters is how they respond, and Vercel's response has been exemplary.

Q: How can I check if a malicious OAuth app has access to my accounts? A: Go to your Google Workspace admin console, GitHub settings, or other OAuth providers. Look for applications you don't recognize or no longer use. Vercel has published the specific OAuth app ID to watch for: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

About the Author​

Arkin Julijanto is a founder and full-stack developer building Orbits Studio, a clip farming marketplace connecting creators with brands. He writes about development, security, and the founder journey. You can find him on Twitter @Arkinej.