A coding agent can produce a working web interface and still reach for an old workaround. It may add a JavaScript dependency for behavior the browser already provides, miss a keyboard interaction, or choose an API without checking browser support. The code can pass a quick visual check while leaving a developer to discover the compatibility or accessibility problem later.
On November 10, 2026, Chrome for Developers announced the stable 1.0 release of Modern Web Guidance, a collection of expert-reviewed skills and guides intended to give coding agents current web-platform advice. The project says its guides cover hundreds of use cases, include compatibility information, and have evaluation coverage through a public dashboard. Firefox and Edge are joining the effort, according to the announcement. Those are project claims, not a guarantee that any particular generated change is correct.
The interesting part is not that an agent can retrieve documentation. It is that the guidance can become a repeatable input to a development workflow: ask the tool for a relevant guide, let the agent propose a small change, and review the result against the actual task, browser support, and tests.
This walkthrough shows how to try that workflow without granting the agent permission to install packages or modify files automatically. I have not independently benchmarked Modern Web Guidance or used it in a production project. The commands and project details below are based on its public documentation and repository. Treat the tool as an additional reference, not an approval system.
What Modern Web Guidance does
The project has a standalone CLI for searching and retrieving guides, plus a new modernization workflow. Its stable 1.0 release was announced on November 10, 2026. The Modern Web Guidance 1.0 announcement says the project now has hundreds of expert-reviewed guides, browser compatibility information, an evaluation dashboard, and participation from Firefox and Edge. Those are project-reported details, not a guarantee that any particular generated change is correct.
The repository README describes local semantic search and says that guide lookup runs without network calls or API keys after the package is available. It also documents telemetry: anonymous usage information can include installation counts, the agent name, guide IDs, and search queries generated by the agent. The project says raw user prompts are not collected, and documents DISABLE_TELEMETRY=1 as an opt-out. Read the repository's current privacy notes before adopting it, especially if your environment has stricter telemetry requirements.
These details make it useful to separate three questions:
- Can it find relevant advice? Search and retrieval address this.
- Is that advice right for your app? Your code review, browser matrix, and tests address this.
- Should the agent apply the change? That remains a human decision, enforced through review and agent permissions.
The tool helps with the first question. It does not answer the other two for you.
Try the guides before installing anything
The quickest trial is a one-off guide search, then retrieve the result using its actual ID:
npx modern-web-guidance@latest search "animate a dialog modal backdrop"
npx modern-web-guidance@latest retrieve "<guide-id-from-search>"
The project README also documents an example guide ID, animate-to-from-top-layer. Search first rather than assuming every release or query returns the same recommendation. Read the retrieved guide and check that its fallback and browser-support advice fit your app.
Try modernization on a bounded directory. Version 1.0 adds a codebase scan for a limited set of recognizable legacy patterns. Begin with a small folder so you can review what it identifies before asking an agent to change anything:
npx modern-web-guidance@latest legacy-scan src/components
The project's modernization announcement says the scanner checks only the subset of its roughly 200 guides where legacy code can be identified deterministically. It is not a general audit of every web concern, and no findings do not prove the code is modern. Treat each match as a candidate: inspect the surrounding code, decide whether the old pattern is intentional, check browser support, then choose whether to change it.
If the trial is useful, the project README documents an interactive setup wizard for adding the skill to supported agents:
npx modern-web-guidance@latest install
For a repeatable team setup, review the files the installer adds and commit only the configuration your team intends to share. Check the README for the current update and agent-specific installation instructions. Using @latest is convenient for trying it, but it does not pin a release for a reproducible build environment.
A practical workflow: search, plan, review, test
For a new feature, use guide lookup before coding. For existing code, use the modernization workflow. In either case, ask the agent to show its evidence and plan before it edits. This gives you a chance to catch a mismatch before an agent changes several components or adds a dependency.
For a feature task, start with a scoped request such as:
We need a modal dialog that can be dismissed by clicking outside it.
Before changing files:
1. Search Modern Web Guidance for relevant dialog guidance.
2. Retrieve the best matching guide and explain why it applies.
3. Inspect the existing implementation and identify the smallest change.
4. Show the browser-support implications, accessibility concerns, and tests.
5. Do not edit files until I approve the plan.
For a legacy scan, use a different request:
Modernize src/components using Modern Web Guidance.
Verify each scanner finding against the surrounding code and discard
intentional fallbacks or false positives. Show me the findings and a
small, ordered plan. Do not edit files until I approve it.
After you approve a plan, ask for a small patch and a factual report:
Implement only the approved plan.
In your final report, include:
- the guide IDs and findings you used;
- files changed and why;
- any fallback or browser-support decision;
- tests run and their actual results;
- anything that remains unverified.
Do not claim a test passed unless you ran it.
These prompts are not a security boundary. A coding agent can still misunderstand instructions, and retrieved guidance can still be incomplete for your app. Enforce file access and command execution limits in the agent's own configuration. Keep secrets out of the workspace and inspect diffs before merging.
Make the output reviewable
Prefer a focused diff. Ask for one behavior at a time. If the agent proposes a broad refactor, ask it to separate the modernization from unrelated cleanup. Small diffs make it easier to see whether the retrieved guidance changed the implementation or merely encouraged extra code.
Ask for the alternative, not just the recommendation. For a browser API choice, have the agent identify the platform-native approach, the fallback if needed, and the compatibility evidence it relied on. Verify that evidence against the project's supported-browser policy. “Modern” does not mean “supported in every browser your users have.”
Review accessibility as behavior. For interactive controls, inspect keyboard access, focus movement, semantics, and reduced-motion preferences where relevant. A guide can help the agent remember platform patterns, but your application's specific interaction still needs human review and tests.
Keep test claims precise. Separate a test the agent suggested from one it actually ran. Record the command, result, and environment when those details matter. If the project has no automated test for the behavior, say so and add a manual verification step rather than treating a code diff as proof.
Check privacy before standardizing. The project documents anonymous telemetry fields and a DISABLE_TELEMETRY=1 opt-out. Decide whether that is acceptable for your organization and configure it deliberately. “Local search” describes how guide matching works; it should not be read as “the entire integration has no network activity.” The package still has to be obtained, and the agent platform may have its own network behavior.
Add it to a team workflow carefully
A team can begin with an opt-in pilot rather than making a new agent skill mandatory for every repository. Pick a small number of front-end tasks where browser behavior and accessibility matter. For each task, compare the proposed implementation with the existing approach and record whether the guidance changed the solution, reduced review comments, or introduced irrelevant complexity.
Do not treat an evaluation dashboard as a substitute for your own acceptance criteria. The Chrome announcement says the project has a public dashboard and expanded evaluation coverage, but your application has its own frameworks, support matrix, and design system. Check the evaluation setup and metric definitions before using any score to make a procurement or quality claim.
A useful adoption checklist:
- Scope: Name the task and component before asking the agent to search.
- Evidence: Record the guide ID and inspect the relevant guidance.
- Compatibility: Compare the proposal with your actual browser support policy.
- Accessibility: Review keyboard, focus, semantics, and motion behavior where applicable.
- Permissions: Keep install, file-write, and command execution under your existing approval controls.
- Privacy: Decide whether documented telemetry is acceptable and configure the opt-out if needed.
- Verification: Run the tests that matter and report only results that actually occurred.
- Maintenance: Re-check the tool's README and integrations when updating the package or agent.
Where it fits, and where it doesn't
Modern Web Guidance is most compelling when an agent is writing or modernizing browser-facing code and the relevant platform behavior has expert-curated guidance. It is less useful as a blanket instruction to “make the whole app modern,” or as a replacement for product requirements, browser testing, accessibility review, or framework-specific documentation.
The broader lesson is that coding agents need more than a prompt that says “use best practices.” A retrieval step can make useful, specific knowledge available at the moment of a task. But the quality loop still depends on scoped changes, explicit evidence, review, and verification. Treat the guide as a reference the agent must explain, not authority the agent can invoke to end a discussion.
I would start with one feature, test search and retrieval, and keep the agent in plan-first mode until the team understands the output and privacy behavior. Then measure the actual review experience instead of assuming that a new skill automatically makes generated code better.
I write about developer tools, AI-assisted engineering, and practical software workflows. Subscribe if you want more field guides like this.
Have you tried Modern Web Guidance or another documentation skill with a coding agent? What changed in your review process?
Top comments (0)