luismori.

Vibe Coding Practice

Vibe Coding Cursor Claude Code OpenSpec Agent Skills MCP AI Coding Developer Tools

Advanced Vibe Coding: A Modern Agentic Workflow for Beginners

A practical guide to the full vibe-coding loop — explore with Ask mode and OpenSpec, install skills, generate with Plan mode or spec-driven tools, review with Bugbot and /simplify, verify in the browser with Playwright MCP, deploy with MCP, and capture lessons in custom skills.

18 min read

TL;DR

  • Vibe coding stops being beginner-friendly when you skip phases. A practical operating loop is not “one chat, one prompt, ship.” It is: explore → equip → build → review → verify → deploy → remember.
  • Start read-only. Use Cursor Ask mode or OpenSpec /opsx:explore when you are still figuring out what to build. Both are read-only exploration modes — they answer and explore without editing files.
  • Install skills on purpose. Public directories like skills.sh make SKILL.md workflows one command away — but treat community skills like open-source dependencies and inspect them first.
  • Choose your planning layer. For quick tasks, native Plan mode is fine. For work that should survive chat resets and team review, prefer OpenSpec or GitHub Spec Kit.
  • Review with agents, not vibes. Cursor Bugbot on PRs and Claude Code /simplify are useful cleanup passes — not replacements for tests or human judgment.
  • Verify in the browser before merge. Playwright MCP lets your agent smoke-test critical UI paths interactively; committed playwright test runs in CI for repeatability.
  • Use MCP for interactive deploys when it fits. Railway ships a ready-made remote MCP at mcp.railway.com. Cloudflare docs focus on hosting your own MCP servers — app deploy to Pages/Workers is still usually wrangler, git-connected builds, or CI.
  • Turn repeated lessons into skills. One high-leverage pattern I have seen is capturing what you corrected three times into a reusable SKILL.md — not chasing a clever one-off prompt.

What You Will Learn Here

  • The full modern vibe-coding workflow, phase by phase
  • Which built-in modes and commands to use in Cursor and Claude Code
  • When Ask mode beats Agent mode, and when OpenSpec beats Plan mode
  • How to discover and install skills safely from public registries
  • How spec-driven tools fit the same loop without heavy ceremony
  • How automated review agents like Bugbot and /simplify fit before merge
  • How Playwright MCP and CI Playwright tests fit as a browser verification layer
  • How MCP deployment works for Railway and Cloudflare (and where CI still matters)
  • How junior engineers and non-engineers can use the same workflow with different depth

This article is for junior engineers, career switchers, and non-engineers who already know the basics of vibe coding — describe an app, let an agent write code, deploy something — and want the next layer: fewer wrong turns, fewer scary diffs, and a workflow that scales past one weekend project.

If you need the beginner stack first, start with How to Create Your Vibe Coding App. For quality guardrails during generation, see How to Improve Code Quality During Vibe Coding.

On July 6, 2026, I reviewed Cursor docs for Ask, Plan, Agent, Debug, Bugbot, and subagents; Anthropic and Claude Code docs for Plan Mode and slash commands; OpenSpec docs and the repo’s OpenSpec skills; GitHub Spec Kit docs; Railway MCP docs; Cloudflare remote MCP docs; Playwright MCP docs; and the Vercel skills CLI repository behind skills.sh. Product behavior below is source-backed where cited. Workflow recommendations are my editorial synthesis for beginners who want a practical operating model, not a tool comparison essay.

The Workflow at a Glance

Think of advanced vibe coding as an operating system with six phases:

┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│  1. EXPLORE  │──▶│  2. EQUIP    │──▶│  3. BUILD    │
│ Ask / explore│   │ skills.sh    │   │ Plan / spec  │
└──────────────┘   └──────────────┘   └──────────────┘
        │                                      │
        │                                      ▼
┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ 6. REMEMBER  │◀──│ 5. DEPLOY    │◀──│ 4. REVIEW    │
│ custom skills│   │ MCP + CI     │   │ + VERIFY     │
└──────────────┘   └──────────────┘   │ Bugbot/MCP   │
                                      └──────────────┘

You do not need every phase on every task. A one-line CSS tweak can stay in Agent mode. A new feature that touches auth, database, UI, and deploy should walk the loop — including browser verify when users interact with the change.

Phase 1: Explore Before You Generate

The most common beginner mistake is opening Agent mode and saying “build me a SaaS.” The agent will happily produce a large diff before you agree on scope.

Use Ask mode when you want answers, not edits

Cursor’s docs describe Ask mode as read-only: the agent can search and explain your codebase, but it will not edit files. Open the Agent panel (Cmd+I / Ctrl+I), press Shift+Tab to cycle modes, and pick Ask.

Good Ask-mode prompts for non-engineers:

  • “Explain this repo like I’m a PM. What are the main parts?”
  • “What would break if I added user accounts?”
  • “Show me three ways to add a contact form, from simplest to most scalable.”

Cursor also documents Debug mode for tricky bugs that need runtime evidence. You do not need it on day one, but it is worth knowing the mode exists before you spend an hour arguing with Agent mode about a race condition.

Use OpenSpec explore when the idea is still fuzzy

If your repo already has OpenSpec installed, /opsx:explore is the spec-native version of “think first.” OpenSpec’s explore guide says the mode is for when you have a problem but not yet a plan. It is intentionally agnostic: no forced conclusion, no automatic code changes.

That pairs well with Ask mode:

Ask mode in Cursor
  -> understand the current codebase in plain language

/opsx:explore in chat
  -> turn understanding into options, trade-offs, and open questions

/opsx:propose
  -> only when you are ready to commit to a change folder in git

For a deeper comparison of Plan mode vs OpenSpec, see Replace Plan Mode with OpenSpec in Cursor and Claude Code.

Beginner rule: if you cannot explain the feature in one paragraph, you are still in Phase 1.

Phase 2: Equip the Agent with Skills

A skill is a small folder, usually centered on SKILL.md, that teaches an agent a repeatable procedure: review an API, write a changelog, run a deployment checklist, audit sources in an article, and so on.

Discover skills on skills.sh

skills.sh is a public directory for agent skills. The ecosystem is powered by the open-source Vercel skills CLI. The usual install command is:

npx skills add owner/repo

Useful flags from the CLI docs:

# Install globally (available across projects)
npx skills add owner/repo -g

# Target a specific agent
npx skills add owner/repo --agent cursor

# Search the ecosystem
npx skills find "deploy cloudflare"

Skills can install into project folders (good for team sharing) or global agent folders (good for personal workflows).

Treat public skills like dependencies

This is the advanced part beginners skip.

A February 2026 Snyk scan of 3,984 skills from ClawHub and skills.sh reported that 36.82% had at least one flagged security issue and 13.4% had at least one critical-level finding in Snyk’s severity model — including prompt injection, exposed secrets, and malicious payloads in some cases. Public directories are convenient; they are not curated like an app store.

Before you install a community skill:

  1. Read the SKILL.md and any bundled scripts.
  2. Prefer skills from authors or repos you recognize.
  3. Start with project scope, not global scope, when testing something new.
  4. Remove skills you no longer use.

For a company-scale version of the same idea, see How to Build a Company Skill Registry for AI Agents.

Non-engineer tip: you do not need to write skills on day one. Install one vetted skill that matches your repeated pain — deployment, PR prep, content review — and notice when the agent starts doing the right thing without you re-pasting instructions.

Phase 3: Build with a Plan, Not a Vibe

Once scope is clear, pick a planning layer.

Option A: Native Plan mode (fastest)

Cursor’s Plan mode researches the codebase, asks clarifying questions, creates a reviewable plan, and waits for approval before editing. Claude Code documents the same pattern with plan permission mode.

Use Plan mode when:

  • the change is small or medium
  • only you need the plan
  • you do not need durable specs in git

Option B: OpenSpec (a good fit when specs should live in git)

OpenSpec’s default loop is:

/opsx:explore   -> optional thinking
/opsx:propose   -> proposal + specs + design + tasks
/opsx:apply     -> implementation
/opsx:archive   -> merge decisions into openspec/specs/

Use OpenSpec when:

  • PMs or teammates need to review intent before code
  • the feature will take more than one agent session
  • you want “why did we choose this?” to live in git, not chat scrollback

See How to Get Started with OpenSpec for setup.

Option C: GitHub Spec Kit (a good fit when teams want formal requirements templates)

GitHub Spec Kit is another spec-driven layer. Its core path is:

/speckit.specify -> requirements
/speckit.plan    -> technical plan
/speckit.tasks   -> task breakdown
/speckit.implement -> execution

Spec Kit ships rich templates, quality gates like /speckit.clarify and /speckit.analyze, and broad agent integrations. It can feel heavier than OpenSpec’s default core profile, which is why I recommend it when your team already wants explicit requirements documents and checklists.

Practical mapping for beginners:

SituationStart here
”What does this code do?”Ask mode
”Fix this one bug”Agent or Debug mode
”Add a medium feature alone”Plan mode
”Add a feature with a PM/reviewer”OpenSpec propose/apply
”New product with formal requirements”Spec Kit

My editorial default for this article’s audience: Ask → Plan for solo work, Ask → OpenSpec for shared work. Spec Kit when your team already speaks in requirements and checklists.

Phase 4: Review with Modern Built-In Agents

Speed without review is how vibe coding turns into “it worked once on my laptop.”

Cursor Bugbot on pull requests

Cursor Bugbot reviews PR diffs and leaves inline comments on bugs, security issues, and quality problems. Cursor docs say it can run automatically on PR updates, or manually when someone comments cursor review or bugbot run.

Useful extras from Cursor’s docs and product pages:

  • Bugbot Rules via .cursor/BUGBOT.md for team-specific standards
  • Bugbot Autofix, which can spawn cloud agents to propose fixes on the PR
  • /review-bugbot or /review skills inside Cursor 3.7+ to run a Bugbot-style pass before you push

Cursor announced a May 2026 pricing change for Bugbot from seat-based billing to usage-based billing. Treat cost as a live detail and check Cursor’s current pricing page before adopting it team-wide.

Cross-model review pattern: generate code with one model, let Bugbot review with another. This may help surface issues a single model overlooks — treat it as a heuristic, not proof. See Cursor Subagents and Claude Code /simplify for a related workflow.

Claude Code /simplify for cleanup passes

Claude Code’s bundled /simplify command (v2.1.154+) reviews changed code for reuse, simplification, and efficiency — and applies fixes. From that version onward it is a cleanup-only pass; use /code-review when you want bug hunting. It is useful after implementation, not a substitute for tests or security review.

My recommended pre-PR loop for beginners:

1. Run unit tests and build locally
2. Playwright MCP: smoke critical UI paths (or run `npx playwright test`)
3. Ask the agent to explain what changed in plain language
4. Run /simplify or /review-bugbot
5. Fix only the findings you understand
6. Open the PR

If a review comment does not make sense, ask the agent to explain it in Ask mode before accepting the fix.

Phase 4b: Verify in the Browser

Static review and diff cleanup do not prove the UI still works. For web apps, add a browser verification layer between review and deploy.

Two layers: interactive MCP + CI tests

LayerToolWhen
Interactive smokePlaywright MCP in Cursor or Claude CodeBefore you open a PR; headed checks on changed UI
Durable regressionnpx playwright test in GitHub ActionsOn every PR and merge to main

Playwright MCP is Microsoft’s official MCP server. It drives a real browser using accessibility snapshots — no vision model required. The agent navigates, clicks, and can call verification tools like browser_verify_element_visible and browser_verify_text_visible.

Cursor config (.cursor/mcp.json):

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Claude Code:

claude mcp add playwright npx @playwright/mcp@latest

A practical pre-merge prompt:

Using Playwright MCP:
1. Start the dev server (or use the staging URL).
2. Verify /health returns 200.
3. Walk through login and the primary happy path.
4. Report broken flows with snapshots.
Do not claim the task is done until critical paths pass.

For repeatability, ask the agent to turn repeated smoke paths into committed tests:

# Local inspection (headed)
npx playwright test --headed

# CI gate (headless)
npx playwright test

See OpenSpec Development Workflow for how to wire Playwright into tasks.md quality gates, and Computer-Use Agents for QA for the hybrid pattern: let the agent handle fuzzy navigation, let Playwright assert the final state.

Limits to keep in mind:

  • Playwright MCP is great for interactive smoke tests; it does not replace a committed test suite in CI.
  • browser_run_code_unsafe runs arbitrary Playwright code and is RCE-equivalent — only enable it for trusted clients.
  • Cloud agents and headless CI may need --headless or a standalone MCP server (npx @playwright/mcp@latest --port 8931).

Phase 5: Deploy with MCP and CI

Describing deployment in chat without tooling is where agents hallucinate flags and env vars. MCP (Model Context Protocol) gives the agent structured tools instead of guesswork.

Railway remote MCP

Railway documents a hosted remote MCP server at https://mcp.railway.com. It uses OAuth in the browser, so you do not need to paste long-lived tokens into a config file for the basic setup.

Cursor example from Railway docs:

{
  "mcpServers": {
    "railway": {
      "url": "https://mcp.railway.com"
    }
  }
}

Claude Code example:

claude mcp add railway --transport http https://mcp.railway.com

Once connected, you can ask plain-language deployment questions: list services, redeploy, inspect variables, or hand complex tasks to Railway’s railway-agent tool.

Railway also documents railway skills install for curated Railway skills across Claude Code, Cursor, Codex, and OpenCode — a platform-native version of the skills.sh pattern.

Cloudflare: MCP hosting plus Pages/Workers deploy

Cloudflare’s official MCP docs focus on building and hosting remote MCP servers on Workers with Streamable HTTP transport, OAuth, and the Agents SDK McpAgent class. That is different from Railway’s ready-made remote MCP, but still useful in two ways:

  1. Platform MCP servers. You can deploy your own MCP server on Workers and connect Cursor or Claude Code to it for Cloudflare-specific tools.
  2. App deploy paths. Shipping your app to Cloudflare Pages or Workers is still often done with wrangler, git-connected Pages builds, or GitHub Actions — then you keep MCP config in .cursor/mcp.json so later agent sessions can manage the live project safely.

Community MCP servers for Cloudflare deploy also exist, but treat them like any other third-party skill: inspect the repo before connecting it to your editor.

For a repo-native example of Cloudflare app deployment in this devlog stack, see How to Create Your Vibe Coding App.

GitHub Actions as the safety net

MCP is great for interactive deploys. GitHub Actions is still the reliability layer: run tests, build the site, and deploy on merge. A simple pattern for beginners:

feature branch
  -> agent implements
  -> browser verify + Bugbot + human review
  -> merge to main
  -> GitHub Actions builds, tests, and deploys

Even non-engineers benefit from one workflow file that proves “main is always deployable.” Let the agent draft the workflow, then ask it to explain every step in Ask mode before you merge it.

Phase 6: Remember the Lesson as a Skill

The difference between intermediate and advanced vibe coding is memory.

Every time you:

  • paste the same instruction three times
  • reject the same kind of bad diff
  • explain the same deploy quirk
  • rewrite the same review checklist

…you have found a skill candidate.

Minimum viable custom skill

---
name: deploy-staging-checklist
description: Run the staging deploy checklist for this repo. Use before merging frontend changes or when asked to deploy to staging.
---

# Staging Deploy Checklist

1. Run `npm run build`
2. Confirm env vars in Railway service `web-staging`
3. Deploy with Railway MCP or `railway up`
4. Playwright MCP or `npx playwright test`: smoke-test `/health` and the login flow
5. Summarize what changed for the PR description

Save that as .cursor/skills/deploy-staging-checklist/SKILL.md or the equivalent path for your agent. Keep it short. Link to scripts if the procedure is long.

For UI-heavy repos, a companion skill helps:

---
name: ui-smoke-verify
description: Run browser smoke verification before merge. Use Playwright MCP for login, checkout, and /health.
---

# UI Smoke Verify

1. `npm run dev` or confirm staging URL
2. Playwright MCP: verify /health, login, and primary happy path
3. If UI changed, update `tests/e2e/` and run `npx playwright test`
4. Summarize pass/fail in the PR description

For a broader audit framework — when to use rules vs skills vs subagents — see Audit Your Daily AI Agent Workflow.

Advanced Tips for Junior Engineers and Non-Engineers

1. Match mode to risk

Low risk, small change      -> Agent
Understanding only          -> Ask
Multi-file feature          -> Plan or OpenSpec propose
Production bug              -> Debug
Shared feature with review  -> OpenSpec or Spec Kit
Before merge                -> Bugbot + browser verify + local tests
After implementation        -> /simplify

2. Keep diffs small

Large AI diffs are hard to review whether you are junior or not. Ask for one slice at a time:

  • schema first
  • API second
  • UI third
  • tests with each slice

3. Make the agent show its work

These prompts work well for non-engineers:

  • “Before editing, list the files you will touch and why.”
  • “Explain the trade-off in plain language before choosing an approach.”
  • “If you are unsure, ask me one question instead of guessing.”

4. Use subagents only when isolation helps

Cursor subagents shine when a side task would pollute the main thread: repo archaeology, parallel research, long terminal output. They are optional complexity. Do not start there.

5. Build a personal “done” checklist

Before you call a task finished:

  • I can explain what changed without reading the diff line by line
  • Tests or browser smoke verification passed
  • Review agent or human review completed
  • Deploy path is known and repeatable
  • Repeated instructions were captured as a skill or rule

A Sample Week for a Beginner Team

Monday
  Ask mode: map the repo and pick one feature slice
  /opsx:explore or Plan mode: agree on approach

Tuesday
  Install one public skill + one project rule
  /opsx:propose or Plan approval

Wednesday
  /opsx:apply or Agent mode implementation
  commit small chunks

Thursday
  Playwright MCP smoke on changed UI paths
  /simplify or /review-bugbot
  open PR, enable Bugbot

Friday
  merge after CI green (including headless Playwright if configured)
  deploy via Railway MCP, `wrangler`/Pages, or your CI pipeline
  write one custom skill from the week's corrections

That rhythm is deliberately boring. Boring is what makes vibe coding survive contact with real users.

What This Workflow Does Not Replace

Be honest about limits:

  • Skills and MCP do not remove security review. Public skills can be malicious. MCP tools can perform destructive actions if you approve them blindly.
  • Bugbot and /simplify do not replace tests. They catch useful issues; they do not prove correctness. Playwright MCP smoke tests are helpful, but CI should still run committed playwright test files for regression protection.
  • Spec-driven tools do not replace product judgment. They make disagreement visible earlier, which is only helpful if someone reads the artifacts.
  • Advanced workflow does not mean more tools. If Plan mode alone works for your task, use it.

Sources

Primary and official sources consulted on July 6, 2026:

Related articles in this devlog: