This is the second tutorial.
It assumes you already finished tutorial-flask.md and have:
copilot-agent.nviminstalled- the chat UI working in Neovim
- a basic understanding of agent mode
This tutorial focuses on using agents to shape and refine an app.
You will build a Flask weather dashboard, then create a couple of simple agents so you can see how agent roles help refine the app.
In this walkthrough, you will create:
- a UI Design Agent
- a QA Agent
Then you will use those agents to improve the app in separate passes.
mkdir ~/flask-weather-dashboard && cd ~/flask-weather-dashboard
nvim .Inside Neovim:
:CopilotAgentChatPress <C-t> until you see 🤖 agent.
Send this prompt:
Build a Flask weather dashboard app in this directory.
Backend:
- Create a virtual environment and install flask
- Create a Flask app
- GET / serves the app
- GET /api/weather?city=<name> returns weather data
- Use wttr.in JSON output as the upstream weather source
- Return city, temperature_c, condition, humidity, wind_kph, and a 3-day forecast
- Handle empty city names and upstream failures cleanly
Frontend:
- Single-page app with vanilla JavaScript and CSS
- Search input for city lookup
- Current weather summary card
- 3-day forecast cards
- Clean responsive layout
- Keep the first version simple but pleasant
Also create requirements.txt and README.md.
Then ask:
Run the Flask app on port 5000
Open http://localhost:5000.
At this point you have a base weather dashboard.
Send this prompt:
Create two repo-local agents for this project in .github/agents:
1. ui-design.agent.md
- Focus on layout, visual polish, spacing, typography, responsive behavior, loading states, and overall UX
- Do not make backend architecture changes unless absolutely necessary for UI work
2. qa.agent.md
- Focus on test coverage, edge cases, regression checks, and validation
- Prefer pytest for backend tests
- Mock network calls instead of using live weather APIs in tests
Keep both agent files short, practical, and easy to understand.
Because the plugin uses Copilot config discovery, these agents become available to the session after they are created.
Note: you need to create a new session to trigger the agent discovery.
:CopilotAgentNewSessionOpen chat again if needed:
:CopilotAgentChatRun /agent and select UI Design Agent, then send:
Use the UI Design Agent to refine this weather dashboard.
Improve:
- the overall layout
- visual hierarchy
- spacing and typography
- search bar styling
- forecast card styling
- loading and empty states
- mobile responsiveness
Keep the app lightweight and stay with vanilla JS + CSS.
This gives the user a clear example of using an agent for a focused responsibility instead of a generic prompt.
Start a fresh session:
:CopilotAgentNewSessionRun /agent and select QA Agent, then send:
Use the QA Agent to add backend tests for this weather dashboard.
Cover:
- GET / returns HTML
- GET /api/weather without city returns 400
- GET /api/weather with a city returns normalized JSON
- upstream failures return a clean error response
Use pytest.
Mock wttr.in so the tests never hit the network.
Update requirements.txt if needed and run the tests.
Now the user sees the same app being refined by a different specialized agent.
Start another session:
:CopilotAgentNewSessionRun /agent and select UI Design Agent, then ask:
Refine the dashboard again:
- add a better hero area for the current weather
- make the background feel more dynamic
- improve the forecast card balance
- make error messages feel more polished
- improve the dashboard for narrow mobile screens
This is a good example of how agents become reusable project tools instead of one-off prompts.
The key idea is not just building a weather app.
It is learning how to:
- create small repo-local agents
- give each agent a narrow job
- use fresh sessions to let each agent work with a clear role
- refine an app in stages
That is the mental model you will use in the next tutorial too.