claude-webdev-skills

Polls a pull request on a fixed interval until it reaches a terminal state — approved, changes-requested, merged, or closed — then either notifies you or hands off to /webdev:merge-pr. Use when the user says "watch the PR", "poll PR #X", "tell me when it's approved", "keep checking the PR", "let me know when review comes back", or "auto-merge when it's approved". Takes a PR (number/URL), a check interval, and an on-approval action (notify | merge). Built on ScheduleWakeup: each poll re-arms the next and the loop ends itself on a terminal state or a safety cap. Silence is never reported as approval.

Commits completed work the right way — staging the right files, running tests and the formatter first, a hostile pre-push self-review, a conventional-commits message, push, and (by default) opening a PR. Use when the user says "commit", "let's commit", "commit these changes", "I'm ready to commit", or "commit and push". Trigger any time work is complete and ready to commit — don't wait to be asked about best practices.

Resolves the project's toolchain — package manager, test runner, formatter/linter, framework, and dev/run command — so other webdev skills issue the right commands on any stack. Auto-detects JS/TS and PHP; every other stack is supported through an explicit .claude/webdev.json override. Use at the start of any workflow that needs to run tests, format code, install dependencies, or start the dev server. Other webdev skills invoke this first. Honors an explicit .claude/webdev.json override before falling back to filesystem detection.

Triage and fix a failing CI check on a PR or branch. Use when the user says "CI is failing", "the build is red", "checks failed", "fix the pipeline", "why did CI fail", or any time a PR's checks are red after a push. Reads the failing run's logs via gh, finds the first real error, classifies the failure (caused by this branch / pre-existing on base / flaky or infra), reproduces it locally, fixes the cause, and watches the checks go green. For review COMMENTS on a PR use /webdev:review-pr — the two chain naturally when a PR is both red and commented.

Deep-dive review of a single specific merged PR to catch issues that slipped through code review — bugs, missing tests, inconsistencies, doc gaps. Use when the user wants to review a particular PR after merge or spot-check a specific merge. Trigger on "review PR #123", "check what that PR changed", "post-merge review", "did anything slip through on PR #X". Unlike /webdev:qa-review (which audits all recent merges broadly), this skill focuses on one PR in depth.

Broad QA review of recently merged functionality (not one specific PR). Use when the user wants to review recent work, smoke-test merged features, or audit the latest additions. Trigger on "review recent changes", "QA the latest merge", "smoke test", "review what was merged", "anything need fixing?", "check the recent work", "full review". For a deep-dive on a single PR, use /webdev:post-merge-review instead.

Runs the project's test suite at the smallest scope that proves the change. Use when the user asks to "run tests", "check tests", "make sure tests pass", or before committing or opening a PR. Also trigger automatically after code changes that could affect existing functionality. Resolves the test command via /webdev:detect-stack, so it works on any stack (vitest, jest, phpunit, pest, …).

Proves a change works by exercising the RUNNING app, not just the test suite — start the dev server, drive the changed behavior, observe the result. Use before committing user-facing work (UI, routes, forms, emails-to-preview, API responses), or when the user asks "does it actually work?", "check it in the browser", "try it out", "verify the change". Tests prove the behaviors that have tests; this proves the behavior a user will actually hit. Complements /webdev:run-tests — it does not replace it.

Merges a pull request the safe way — verify approvals, green checks, and resolved threads first, pick the repo's merge method, merge, then clean up via sync-main. Use when the user says "merge it", "merge the PR", "land it", "squash and merge", "it's approved — merge", or after /webdev:review-pr reports merge-ready. This skill MERGES; to address review comments use /webdev:review-pr, to fix a red check use /webdev:fix-ci. Never merges on its own initiative — merging is often a deploy.

Drives a new piece of work from start to finish — branch, pre-implementation inventory (when warranted), implementation, tests, and commit/PR — by chaining the atomic webdev skills. Use when building any new feature, endpoint, page, component, or integration. Trigger when the user says "add a feature", "build X", "implement Y", "create a new Z", or when starting any non-trivial new functionality. NOT for defects: if the request is fixing broken/incorrect existing behavior ("fix the bug", "implement a fix for issue #N", an error report), use /webdev:fix-bug instead — its reproduce-first, failing-test discipline must not be bypassed. Also useful mid-feature as a checklist to confirm nothing was missed.

Opens a GitHub pull request with a structured, reviewable body. Use whenever the user says "open a PR", "create the PR", "push and open a PR", "ship it", or any time work is committed and pushed to a working branch but the PR isn't open yet. Also invoked automatically as the final step of /webdev:commit after a successful push. Produces a PR description in a four-section shape (Summary / Decisions baked in / Test plan / Follow-ups) with checkbox-formatted verification steps.

Produce a written inventory of what already exists and could break BEFORE writing any code, for non-trivial work. Use whenever the task involves consolidating / splitting / renaming / deleting routes, components, exports, or services with multiple call sites; reusing existing shared infrastructure (rate limiters, middleware, queues, caches, hooks, services) on a new surface; code that runs in more than one execution context (logged-in/out, server/client, prod/test, per tenant/locale/role); changing a uniqueness/scoping invariant; or introducing or tightening a value-shape rule (slug/identifier/status/enum format). Auto-invoke from /webdev:new-feature when triggers match. Skip for single-file bug fixes, isolated new features, copy/style tweaks, and docs-only changes.

Address and resolve GitHub pull request review comments end to end. Use whenever the user shares a PR URL and asks to "address comments", "fix the feedback", "resolve the review", "handle the bot comments", or pastes a PR URL with "fix this PR". Handles the full loop: read comments → verify each claim → sweep for siblings → fix → test → self-review → commit & push → reply inline → resolve threads → wait and recheck for new comments and CI status. Works with any automated reviewer (Codex, Copilot, CodeRabbit) and human reviewers alike.

Drives a bug fix end to end with the reproduce → failing test → fix discipline. Use when the user reports broken behavior: "fix this bug", "X is broken", "X stopped working", "users are seeing Y", pastes an error/stack trace, or points at a defect issue ("fix issue #N"). Bug-shaped work differs from feature-shaped work: you must see it fail before you change anything, and the proof of the fix is a test that goes red → green. For new functionality use /webdev:new-feature; for a red CI check use /webdev:fix-ci.

Creates a properly-named git branch before starting any new work. Use at the start of every coding session, feature, bug fix, or task. Trigger whenever the user mentions starting something new, working on an issue, fixing a bug, or any time work is about to begin and no feature branch exists yet. If the user jumps straight into changes without a branch, pause and run this first. Phrases like "let's work on X", "can you fix Y", "start on issue #Z", or "I want to add A" are all signals to run this skill. This skill ONLY creates the branch: for a defect report ("can you fix Y", a broken behavior), branching is step 0 — continue with /webdev:fix-bug afterward; for new functionality, continue with /webdev:new-feature.

Returns the local repo to a verifiably clean state on the latest default branch before starting the next task. Use after a PR is merged and deployed, when switching context between tasks, or any time you want to confirm the base is up to date and stale local branches are cleaned up. Trigger phrases: "sync main", "clean up", "back to main", "fresh start", "start the next thing", "we just deployed", "PR is merged what's next". This skill does NOT create a branch — chain to /webdev:new-branch when ready to start work.

The guided, beginner-friendly way to take a change from idea to merged PR. Same workflow as /webdev:new-feature, but it explains each step in plain language, confirms before anything irreversible, and assumes you're new to git, branches, and pull requests. Use when the user says "help me ship this", "I'm new to this", "walk me through it", "how do I get my change live", or seems unsure about the git/PR workflow. For experienced users who just want the workflow run, prefer /webdev:new-feature.

Orient someone in an unfamiliar codebase — what it is, the stack, where things live, the entry points, how to run/test/build it, and where to start reading. Use when the user says "explain this codebase", "help me understand this project", "give me a tour", "what is this", "where do I start", "how does this app work", or has just cloned a repo they don't know. Read-only — it explains, it doesn't change anything.

Guardrails for risky operations — classify blast radius and reversibility, then confirm, back up, or proceed accordingly. Use before anything destructive or hard to undo: force-pushing, deleting files or branches, dropping/resetting a database, running migrations, bulk find-and-replace, rewriting git history, or editing generated/vendored files. Trigger when the user says "is this safe?", "be careful here", "don't break anything", or when you (Claude) are about to run an irreversible command. Especially useful for people new to git and the shell.

First-run setup for a project — detects the stack, scaffolds a CLAUDE.md and an optional .claude/webdev.json, and explains what it configured. Use when the user installs this plugin in a new project, says "set up webdev here", "configure this project", "get started", "initialize", or when other webdev skills can't resolve the toolchain cleanly. Safe by default: never overwrites an existing CLAUDE.md without showing a diff and asking first.