An agentic workflow is the disciplined form of what’s often called “vibe coding”: giving a coding agent a task and the context it needs, then letting it plan, edit, and test across your codebase while you review the results. When it’s done well, the productivity gains can be dramatic. In his vibe-coding WebRTC post, Philipp Hancke describes getting changes merged into libWebRTC, Firefox, and even Pion, work that used to wait on finding a free week to dig into unfamiliar code. But it only worked because those codebases have heavy guardrails: tests, consistent tooling, and reviewers who reject anything sloppy. The agent moves fast; the engineering practice around it is what makes that speed safe.
We saw the same lesson when we folded AI into our QA team at WebRTC.ventures, and it echoes the practices in Context Engineering Best Practices for Voice AI Agents. (For background on agentic development and agent harnesses, start with my earlier post on the AgilityFeat blog: Terminal Agents, Context Files, and Why Your AI Harness Is More Important Than Your AI Model.)
This post puts that understanding to work, drawing on what we have learned shipping real systems at WebRTC.ventures. I will walk through the workflows I use when building real-time applications: the context file that anchors a project, custom skills that turn session context into tests and reviews, and habits that came out of daily use.
Writing an AGENTS.md for a WebRTC Project
A clean, cohesive top level AGENTS.md or CLAUDE.md is the agent’s starting context, which makes it a natural place to lay out the project: the type of application, the stack, how it is set up, and any other services it leans on. LLMs already know WebRTC fundamentals, so there is no need to teach them the basics. Over-explaining only bloats the context and invites the kind of confident, sloppy output you are trying to avoid. Telling the agent what you are building and what you are building it with is usually all a good context file needs. Beyond that, we avoid duplicating anything that already lives elsewhere in the project, and link out to the relevant docs or code instead.
Here is what that looks like for a multi-party broadcast platform:
# Agent Instructions: RealTime Studio
## What we're building
A multi-party live broadcast platform: presenters join a real-time WebRTC
call, a server-side layout engine composites their feeds into a single
program stream, and that stream is recorded and distributed to viewers.
## Stack
- **Front end**: TypeScript, React/Next.js presenter and producer consoles.
- **API**: Node/TypeScript GraphQL server; issues call tokens, owns session
and participant state.
- **Signaling**: WebSocket service with a Redis-backed fan-out for
real-time presence and control events.
- **Media**: a managed LiveKit WebRTC SFU carries the live call; a
headless-browser layout engine (Xvfb + FFmpeg) renders the composited
program feed.
- **Infra**: AWS behind Terraform: EKS for services, CloudFront for
delivery, CloudWatch for logs.
- **E2E**: Playwright tests covering the front end across the stack.
## Repos
- `api`: GraphQL API, session/token logic, deploy manifests.
- `signaling`: WebSocket presence and control fan-out.
- `media-server`: headless compositor (browser + FFmpeg + media server).
- `web`: presenter/producer front end.
- `infra`: Terraform for AWS, EKS, and delivery.
- `e2e`: Playwright E2E test repo, includes context and instructions.
## Where truth lives
- Code, Terraform, and Kubernetes manifests are the source of truth.
- Treat `plans/` as proposals and most of `docs/` as supporting context,
not a contract, unless a doc is explicitly the maintained integration
agreement.
- When docs and code disagree, follow the code and flag the mismatch.
- Don't copy operational facts into new docs; link the source file instead.
## Conventions
- One branch per ticket; use isolated worktrees for parallel cross-repo
work.
- Region, namespaces, and service config live in Terraform and
`api/config/`, read them there rather than hard-coding values.
## Guardrails
- Never commit secrets, tokens, or credentials. Read them from the existing
config sources, never inline them.
- The call path is latency-sensitive. Flag anything that adds blocking work
to signaling or media handling rather than shipping it quietly.
- Verify connectivity across network types, not just on a local network.
Confirm the TURN and relay paths keep working for the call scenarios this
app supports.
- Don't touch infra (Terraform, EKS, CloudFront) without explicit sign-off.
Propose the change in `plans/` first.
- Stop and ask before changes that span repos or touch session/token logic.
Do not guess at the contract.
- A task is not done on a green compile. Run the relevant tests first (see
below) and report anything you could not cover.
## Further context
Detailed guides live in `docs/agent/`. Read the relevant one before you
start, so this file can stay short:
- `docs/agent/writing-features.md`: how we structure and ship a feature
across the repos.
- `docs/agent/running-tests.md`: running unit, integration, and Playwright
E2E suites locally and in CI.
- `docs/agent/signaling.md`: the WebSocket protocol and message shapes.
- `docs/agent/review.md`: the review checklist and conventions we expect.The point is not this exact file, but the pattern behind it. Tell the agent what you are building and what you are building it with, set the few guardrails that actually matter for your system, and link out to the detail instead of inlining it. The guardrails are where the project shows through. A live media app, for example, cares about keeping the call path clear and staying reliable across networks. Each project will have different priorities, and those project-restraints are the part a model can’t infer on its own.
Custom Claude Code Skills for E2E Tests and Code Review
Custom skills built for your project are where agentic development really starts to pay off. The model already knows a lot; add the right context and instructions, MCP servers, and knowledge of the project internals, and you get solid, repeatable workflows.
Take a feature or a bug fix. You might run a classic prompting session, or you might try loop engineering, a newer approach that some people swear by and others are still skeptical of. (That is distinct from the internal loop an agentic harness runs.) The field moves fast, so staying flexible matters more than picking a camp. Either way, one skill I find enormously helpful generates Playwright E2E tests straight from the session context.
By the end of a session the agent has built up solid context: the application as a whole, and deep knowledge of the work it just did. That can include the relevant APIs from the API server, or the manual steps it took if you had it spin up a browser through the Playwright MCP to test exactly what changed. That is the best moment to keep the context alive and turn it into a test, and to capture any documentation that would otherwise be lost if it is not already in the code.
The skill itself is simple. It points at the E2E repo, asks the agent to capture the work just done, follow the existing conventions, and write useful, non-duplicated tests for the new feature or fix. That saves you from catching up on tests later, from skipping the manual QA notes, and from the regressions that slip in when something ships untested. It works just as well for unit and integration tests.
The nice part is the flexibility. You can reference the skill in a prompt and steer it somewhere slightly different, for example:
Use the fundamentals and knowledge from the /gen-e2e-test skill to write
any integration tests that may be missing for this feature, and write up
some notes for QA with their testing steps.Here is what that skill can look like:
---
name: gen-e2e-test
description: Generate Playwright E2E tests from the current session context.
Use right after implementing a feature or bug fix, while the agent still has
context on what changed, which APIs were touched, and how it was manually
verified.
---
# Generate E2E Test
Turn the work just completed in this session into Playwright end-to-end
tests.
## Steps
1. Review what changed this session: the feature or fix, the APIs or
signaling messages involved, and any manual steps used to verify it
(including anything run through the Playwright MCP browser).
2. Read the existing tests in the E2E repo and match their conventions:
structure, fixtures, naming, and helpers. Reuse shared setup instead of
repeating it.
3. Cover only the new behaviour. Do not duplicate cases already handled
elsewhere.
4. Prefer existing page objects and helpers over inline selectors.
5. Run the new tests and confirm they pass before finishing. Note anything
you could not cover and why.
## Notes
- Keep each test focused on a single behaviour.
- If the work relied on something not obvious from the code, like a timing
assumption or a tricky negotiation step, leave a short comment so the next
person sees it.Code Review Skill
Another skill worth tailoring is code review. Claude Code already ships a /code-review skill that works well and covers things like security checks, but it gets much better when you wrap it with your own context. You create a custom skill that references the built-in one and adds your project’s context, guidelines, and testing notes to steer the review.
I run two variants. One is for self-reviews before I commit or push, and the other is for peer reviews of other developers’ code.
- The peer review variant pairs with the top level context file, so a prompt like
/peer-review the branch <branch_name> for repo <repo_name>is enough, and the skill just uses git directly without needing extra dependencies like gh. I have the peer reviews written out to markdown files in a set directory so I can edit them and keep what I want, then apply them more manually and comment directly on the PR on GitHub. - For the self review, I have it prompt me on what to act on when it finds something. Neither takes much to set up, since they are mostly wrapping the Claude skill, and they are a real help when you are context switching all day.
Testing WebRTC Conditions with the Playwright MCP
Agentic development goes well beyond writing and reviewing code. As I mentioned, a lot of the value is in having the agent turn its session context into tests, and into information you can hand to other teams. Capturing what was done, cleaning it up, and making it readable for the next person is a real productivity win. It works even better when another team keeps their own context or skills for how they like to receive this kind of information. You can match their format every time without having to remember the details yourself, and the two teams can collaborate on the shared context and skills to smooth out the handoff.
Having the agent test through the Playwright MCP is great, too. I was recently working on a connectivity indicator and asked the agent to simulate bad network and CPU conditions. It did this by wrapping the getStats() method and injecting poor stats to fake the degraded connection. I prompted the agent to take screenshots which I would use after watching it work in real time. I sent the screenshots to QA and the product team so they knew what to expect and could weigh in on the design and UX.
I also like having agents generate SVG images for slides when I am presenting on something I built. With the code and the surrounding context feeding the prompt, the results come out surprisingly sharp.
Engineering Practice Makes Agentic Workflows Fast and Safe
Agentic development has opened up a whole new level of productivity for us at WebRTC.ventures! Features land with tests already written, reviews come pre-drafted, and session context gets captured instead of lost.
The pattern behind all of it is the one from the top of this post: the agent moves fast, and the proper engineering practices around it make that speed safe. A clear context file, a few project-specific skills, and guardrails that force tests and review are what turn the speed into shipped work.
If you want WebRTC developers who already work this way inside your team, we offer staff augmentation for real-time projects through WebRTC.ventures, and for other projects through our parent company, AgilityFeat. The same context files and skills that make an agent productive also make an embedded engineer productive from week one.
