Creating an editing agent
In earlier posts I showed how to get started with AI in Visual Studio Code, how to use AI-assisted editing in VS Code, and how to create custom agents in VS Code. Those posts compared AI assistants such as GitHub Copilot, Claude Code, and OpenAI Codex.
In this post, I’ll show you how to build a simple editing agent in Visual Studio Code with GitHub Copilot. Then, I’ll use it to review a draft with suggested copy edits. An agent that quickly applies a style guide to a document and suggests edits for review can save you a lot of time, especially if your editing backlog suddenly increases. Running the agent in your IDE gives you inline edits and suggestions, while still letting you decide which changes to accept.
Prepare the Style Guide
Your organization may already have a style guide. If it’s in a PDF or on a website, convert it to plain text or Markdown before using it with your editing agent. Doing this makes the content easier for the agent to work with and can reduce AI credit usage. You can use an LLM to help with the conversion.
If your organization uses the Microsoft or Google style guides, both are available in Markdown on GitHub. You can download the source files here:
Create the Editing Agent
Next, create a reusable editing agent that applies your chosen style guide to a file and suggests edits for review.
I created a simple agent and saved it as style.agent.md in the .github/agents/ folder of my repository. The file uses plain-language instructions, plus optional YAML front matter for metadata such as the agent name and description. Once you add it to your repository, it appears in the agents menu at the bottom of the GitHub Copilot chat window.
style.agent.md
---
name: style-guide-agent
description: Applies the Google style guide.
tools: [read, agent, edit, search, web]
---
Apply the following Google style guide rules to any file or lines of text that I specify. Read the rules each time before suggesting edits, in case they have changed.
Suggest edits for grammar, clarity, and consistency with the style guide.
I would like to review and accept or reject each suggested change.
Suggest final text only. Do not use strikethrough, tracked-change markup, or inline suggestion formats (such as ~~deleted~~ added). Apply changes directly in the file unless I explicitly ask for review mode.
# Google Style Guide Rules
(The pasted content of the Google style guide in Markdown format, which is available at the following URL:
https://github.com/google/styleguide/blob/gh-pages/docguide/style.md)
Note: Downloading the Google style guide in Markdown format and copying it into your agent file will save you time and AI credits.
Test the Editing Agent
Then, choose a sample passage that needs work. I asked GitHub Copilot to generate one with common clarity and grammar issues, and I copied it into a new file named bad-paragraph.md. The original paragraph read:
To install the telemetry service you just run the setup thing and it should mostly work unless your computer is old or new in a weird way, then maybe do the manual process from the docs somewhere. The API key goes in the config but also maybe in env because both methods are supported except when one is ignored by the runtime for security reasons, which is normal. After deploy, check logs for ERR42 because it means either timeout, auth, DNS, memory pressure, or other networking, so if you see that then retry 2-3 times and clear cache and restart all pods even in single node mode. The dashboard latency number can be trusted except when sampling drops packets, so if it says green but users complain then increase buffer from 64 to 4096 and disable strict mode temporary, then circle back and harden later once traffic stabilizes.
Finally, I opened bad-paragraph.md in Visual Studio Code, selected the style-guide-agent in the GitHub Copilot chat panel, and prompted it to apply the style guide to the file.
The revised paragraphs read:
To install the telemetry service, run the setup script. If the default installer fails because of system incompatibility, follow the manual installation instructions in the documentation. Store the API key in either the configuration file or environment variables, and use one method consistently per environment.
After deployment, check logs for
ERR42. This error can indicate timeout, authentication, DNS, memory pressure, or network issues. If it appears, retry two or three times, clear the cache, and restart all pods, including single-node deployments.
Use dashboard latency as a useful signal, but validate it against user reports because sampling can drop packets. If the dashboard looks healthy while users still report slowness, increase the buffer from 64 to 4096, temporarily disable strict mode, and re-enable hardening after traffic stabilizes.
Running the agent took only seconds, and the improvement in clarity and coherence was noticeable right away. Of course, technical writers can still find more ways to improve this text, but the agent’s instructions are to copy-edit the text and apply style rules. You can add more instructions to include formatting rules, such as making bulleted or numbered lists where needed and adding headings.
Conclusion
Setting this up took less than ten minutes, but the real value shows up when you use the agent on real drafts. Start with one document, review each suggestion, and accept only the changes that match your voice and intent. As you do this, you’ll quickly see which rules are worth keeping and which ones need to be adjusted. After a few rounds, you can refine the agent into a dependable part of your editing workflow. Thanks for reading, and I’d love to hear how it works for you.