Improving AI with domain expertise

AI agents are generalists, but when it comes to professional Flutter development, “general” isn’t enough. To build production-grade apps, you need an assistant that understands the nuance of localization, the latest Dart language features, and how to add integration tests.

Today, we’re introducing Agent Skills for Flutter and Dart — a new way to give your AI tools domain-specific expertise.

Beyond the knowledge gap

One of the primary challenges in AI development is the “knowledge gap.” Flutter and Dart can launch new features more quickly than LLMs can update their fixed training data. As a part of how we are thinking about AI, we are looking for ways to not only address the knowledge gap but also ensure the agent applies that knowledge to achieve the task accurately and efficiently following the most optimal workflows.

A little over a year ago, Model Context Protocols (MCP) were the way to provide more AI domain-specific expertise. While MCP gives an agent access to specialized tools, an Agent Skill teaches the agent how to use those tools for a specific task. Think of it this way: MCP provides the hammer and nails (the tools), while a Skill provides the blueprint and the professional know-how to build the house.

Skills improve context efficiency through “progressive disclosure”. This is similar to how deferred loading works in Flutter, where apps can load libraries when needed, coding agents load Skills when they are relevant to what you’re trying to do .

For Flutter and Dart, these Skills provide tailored instructions for common workflows, and enhance the tools provided in the Dart MCP server to reduce the knowledge gap, which improves accuracy and lowers token usage.

A task-oriented approach

Our early experimentation revealed that Skills that only provide documentation don’t add as much value as we initially assumed. Since Flutter’s comprehensive and well written documentation is open-sourced, modern models are already highly capable of finding relevant information for most questions and tasks.

So, we pivoted to creating Skills that are “task-oriented”. Every skill in our GitHub Flutter Skills or Dart Skills repositories focuses on developer tasks like building adaptive layouts- by providing instructions for agents to reliably complete the task. We have conducted extensive manual evaluations to define our initial set of launched skills, and are working on an automated evaluation pipeline that we will share soon.

Using the Skills

To start using these Skills in your workflow, first install the Skill set in your project directory:

npx skills add flutter/skills - skill '*' - agent universal
npx skills add dart-lang/skills - skill '*' - agent universal

You will be asked to select the Skills you want to install. Pick all or select the specific ones you might find most useful.

Then choose the agent that you prefer to develop with.

Now, prompt your AI agent as usual. Here are 5 ways you can use these Skills today:

Skill #1: flutter-add-integration-test

Configures Flutter Driver for app interaction and converts MCP actions into permanent integration tests.

Add an integration test for the checkout flow in my app

Skill #2: flutter-setup-localiztion

Adds localization support to your Flutter project

Set up localization in my app

Skill #3: flutter-build-responsive-layout

Uses LayoutBuilder, MediaQuery, or Expanded/Flexible to create a layout that adapts to different screen sizes.

Ensure that the checkout screen uses repsonsive layout

Skill #4: dart-use-pattern-matching

Refactors code to use Dart’s pattern matching language capabilities where appropriate

Refactor my code so that it uses pattern matching where possible

Skill #5: dart-collect-coverage

Uses the coverage package to collect unit test coverage and generate an LCOV report.

Collect test coverage for my project

For more prompt examples, check out the readme Flutter Skills or Dart Skills repositories on GitHub.

Tell us what you think

These initial core Skills, designed to handle the most common Flutter development hurdles, are just the beginning. We want to build the future of AI-assisted development with you, our community. As you use these Skills and create new ones for your projects, file issues (Dart Skills repo, Flutter Skills repo), and let us know what additional work you’d like to see. We look forward to helping improve your productivity as you use these Skills!

Introducing Skills for Dart and Flutter was originally published in Flutter on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a quiet but growing backlash against the cloud-everything model that dominated the last decade of software. Not a rejection of the internet but a recognition that not every tool needs a server, an account, or a subscription to work. Local-first software is the answer. Your data lives on your machine, works offline, and doesn’t phone home.

Simple QR Code Maker was built from the start with those values in mind.

What Is “Local-First”?

A local-first app keeps your data on your device and processes everything on your hardware. It doesn’t upload your inputs to a server to do its job. It doesn’t require a login. It works when you’re on a plane, in a basement, or on a spotty conference Wi-Fi. Your data is yours; readable, moveable, and not subject to a vendor deciding to sunset their service.

The contrast: most web-based QR generators ask you to type a URL into a box, send it to their server, generate an image, and return it. Every URL you paste is logged. You’re often nudged toward a “dynamic QR” feature that routes through their redirector domain, meaning if they go down or change their pricing, your printed QR codes stop sending your users where you want them to go.

Simple QR Code Maker’s Local-First Architecture

Every core feature of Simple QR Code Maker runs entirely on your Windows PC.

QR code generation and decoding use ZXing.Net, an open-source library that runs entirely in-process. No network call, no API key, no rate limit. You type, it generates, instantly.

Image processing like background removal (powered by new Windows AI APIs), perspective correction for scanned photos, grayscale and contrast adjustments for hard-to-decode images runs on your GPU and CPU via Magick.NET, also fully offline.

Your history, settings, and brand presets are stored as plain JSON files in your local app data folder. There’s no account to sync to. The files are human-readable. If you want to look at them, open them in Notepad.

Backup and restore is built in: the Settings page lets you export your entire history, brand definitions, and settings as a .zip file. You own the archive. Import it on another machine, keep it on a USB drive, or just tuck it away. The app merges imports intelligently so you don’t lose existing entries.

Even the Warnings Encode Local-First Values

One of the more opinionated features of the app is the redirector warning. When you type a URL that points to a known link-shortener or QR redirect service such as bit.ly, tinyurl.com, qrco.de, and a dozen others, the app flags it.

Why? Because those services are the opposite of local-first for your audience. A QR code pointing to bit.ly/abc123 encodes a dependency on a third-party server. If that service changes its terms, goes offline, or decides to monetize your link, every physical printout that carries that QR code breaks. The warning nudges you toward encoding the real destination URL directly, a QR code that will work ten years from now without any middleman.

You can mark specific domains as safe if you have a legitimate use (your company’s preferred URL shortener, for instance), and that allow-list is stored locally too.

What Local-First Buys You

• Privacy by default. The app never sees your URLs, your logos, or your history. They don’t leave your machine.
• Works anywhere. No internet required for any feature. Generate QR codes on a plane, decode them in a server room, print them at the venue.
• Permanence. Your QR codes encode the real destination. They’ll work as long as the destination URL works, not as long as a SaaS vendor’s business does.
• Portability. Your data is a JSON file. Copy it, back it up, read it, write tools against it.
• No subscriptions. The app is free on the Microsoft Store. There’s no cloud tier to upgrade to, because there’s no cloud.

The Tradeoff Worth Acknowledging

Local-first means there’s no sync. If you generate QR codes on your work laptop and want the history on your home desktop, you export a backup and import it on the other machine. It’s a few more clicks than automatic cloud sync, but you’re the one in control of where your data goes and when.

For most QR code use cases like designing assets for print, generating codes for events, encoding contact info or Wi-Fi credentials, that’s a perfectly fine tradeoff. You’re not collaborating in real-time on a QR code with a distributed team. You’re making a thing, saving it, and using it.

Building Software That Respects Your Machine

Simple QR Code Maker is a native WinUI 3 app targeting x64 and ARM64 Windows. It uses your OS’s built-in storage APIs, renders at native resolution, and integrates with system print dialogs. It’s a Windows app the way Windows apps used to be built, not a web page crammed into an Electron shell phoning home to keep the lights on.

That philosophy, use the platform, keep data local, don’t require a server, is increasingly rare. But it makes for software that’s faster, more private, more reliable, and more honest about what it actually needs from you.

Which, for a tool that makes QR codes, is just the URL you want to encode.

Want to try it? Simple QR Code Maker is available on the Microsoft Store.

Joe

p.s. in addition to being a local first app, Simple QR Code Maker is open source on GitHub!

Do you struggle with interviews? You're not alone! You can have the best interview notes in the world, but when you start having that vocal conversation, you might end up a deer in the headlights, freezing and forgetting everything you thought you prepared for.

There's good news though!

With modern AI tools like LiveKit, you can have a voice conversation with an AI agent, mocking a real interview experience. Imagine uploading a job description and your resume and being immediately paired with an expert (the agent) to ask you real questions for the job and providing feedback on how you answer and present yourself.

In this tutorial we'll explore using LiveKit and TypeScript, paired with various LLM models and Apache Tika, to establish a very realistic interview coaching experience.

The post Build a Real-Time Voice Interview Coach with TypeScript and LiveKit appeared first on The Polyglot Developer.

Back in the day when we wrote actual code instead of poking at an AI, I had a general rule for when to refactor repeated code. Do it once, fine. Do it a second time, fine. Do it a third time - refactor.

It’s ok to have blocks of identical code in two places, but once I added it to a third place, I’d refactor it to a shared location, such as base class or helper function. Some might say this doesn’t follow DRY principles as I should refactor it the second time, but I find it a good balance between pragmatism and clean code. It’s too easy to stress over clean code and over complete everything to avoid code duplication, ending up making your code harder to understand.

So how does this apply to AI? I’m going to ignore code duplication here, cos the AI is very good at duplicating code. Instead let’s consider how we prompt the AI to do certain tasks.

A typical example is I often ask Copilot or Claude to check its work. I use a prompt like:

Review your work. Check for:

- compliance with the original spec for this work
- unit test coverage
- consistency with the rest of the code base including style, naming, commenting, and architecture
- code reuse, and compliance with DRY principles
- does the code pass the linter
- does the code work

Do multiple passes over all the code changes made using this review plan. When you identify areas that do not pass this review, fix them, then re-run the review.

Work until this review passes.

The goal of this is to ensure that Copilot (or Claude, or your coding assistant of choice) takes time to review the changes it has made to ensure they are appropriate, they work, and they confirm to any standards you have for your code. The ‘multiple passes’ request is to get the agent to review, fix, then re-review. This usually ends up with better quality code after the agent has finished.

My 3 strikes rule not only applies to code, but to prompts as well. The first time I asked my agent to review code, I used a prompt like this. Same with the second time. Once I realized there was a patter here in how I want the coding agent to behave, it was time to create a skill.

What are skills?

Skills are instructions that are written in plain text or markdown, that provide reusable directions to your agent. You can think of this as analogous to components or packages you use with code. Instead of installing a package from nuget, PyPi, or npm, you add a markdown file that your agent reads.

These skills can be project level, so installed in the same folder as your project, or at a user level so they apply to any session with your coding agent. For example, if you use GitHub Copilot, you can put skills into ~/.copilot/skills to be used in any coding agent session, or in the .github/skills folder in your project to use them just for a single project.

Skills consist of a directory with the name of the skill, containing a file called skill.md, along with additional files or folders that contain more reference information for the skill. The skill.md file contains front matter with the name and description of the skill. This is used by the coding agent to determine when it should use this skill. The rest of this file contains the instructions for the skill, including an example of the kind of prompt a user would use that should trigger this skill.

Building a code review skill

How do you build a skill? Well the easiest way is to use your coding agent to convert the prompt into a skill. These agents understand skills, so are great at creating them. I asked copilot:

I want to create a user level skill that reviews my code. A typical prompt I use to review code is:

Review your work. Check for:

- compliance with the original spec for this work
- unit test coverage
- consistency with the rest of the code base including style, naming, commenting, and achitecture
- code reuse, and compliance with DRY principles
- does the code pass the linter
- does the code work

Do multiple passes over all the code changes made using this review plan. When you identify areas that do not pass this review, fix them, then re-run the review.

Work until this review passes.

Convert this to a user level skill

This was enough for Copilot to create me a skill in my home folder, with the following content:

---
name: review-work
description: Review code changes against a multi-criteria checklist (spec compliance, test coverage, consistency, DRY, linter, runtime correctness), fix issues found, and re-run the review until it passes. Use when the user asks to "review your work", "review the code", "do a review pass", or similar.
---

# Review Work

Review the code changes you have made in this session against the checklist below. Make multiple passes. When a pass surfaces issues, fix them, then run the review again. Repeat until a full pass produces no findings.

## Review checklist

For every pass, evaluate the changes against each of these criteria:

1. **Spec compliance** — Do the changes implement what was originally asked? Re-read the original request/spec and verify every requirement is met. Flag missing pieces, scope creep, or anything that drifted from intent.
2. **Unit test coverage** — Are the new/changed code paths covered by unit tests? Are edge cases tested? Are the tests meaningful (asserting behavior, not just running code)?
3. **Consistency with the codebase** — Match the surrounding code's style, naming conventions, commenting patterns, and architectural choices. Don't introduce a new pattern when an existing one fits.
4. **Code reuse / DRY** — Is anything duplicated that should be extracted? Is there an existing helper, utility, or abstraction this code should use instead of reimplementing?
5. **Linter** — Run the project's linter(s). The code must pass with no new warnings or errors.
6. **Does the code work** — Run the tests. Run the build. Where applicable, exercise the feature (CLI invocation, dev server, etc.) to confirm runtime behavior matches the spec. Type-checking and tests passing is necessary but not sufficient — verify the feature actually does what it should.

## Process

1. Identify the scope of changes to review (the work done in this session, or the diff against the base branch — whichever matches the user's request).
2. Run a full pass over all changed code, evaluating against every checklist item. Collect findings.
3. If findings exist, fix them. Don't batch — fix and move on.
4. Re-run the full review. Continue until a complete pass produces zero findings.
5. Report the final result: confirm each checklist item passes, and summarize what was fixed during the review (if anything).

## Notes

- Don't stop after one pass. The first round of fixes can introduce new issues; the loop is the point.
- Run linters and tests with the project's actual commands (check `package.json` scripts, `Makefile`, `pyproject.toml`, etc.). Don't assume `npm test` works if the project uses something else.
- If a check is genuinely not applicable (e.g., a docs-only change has no linter target), say so explicitly rather than skipping silently.
- If you cannot verify runtime behavior (no way to exercise the feature in this environment), say so explicitly — don't claim "it works" based on tests alone.
What's great here is the expansion of the prompt to more detailed instructions. The front matter contains a description of the skill, along with guidance as to what prompt should trigger this. It then has the basics list I provided but expanded with more detailed instructions. "compliance with the original spec for this work" becomes "Spec compliance — Do the changes implement what was originally asked? Re-read the original request/spec and verify every requirement is met. Flag missing pieces, scope creep, or anything that drifted from intent."

It also adds helpful notes, like don't run checks that are not applicable, such as run multiple passes as one pass might introduce new issues, or avoid linter checks for a pure docs change.

Use the skill

Now I have my skill, I can reload my coding agent and it will pick up this new skill. Instead of typing my review prompt in detail each time I need a review, I can just ask Review your work, and the coding agent will load this skill and follow it for a thorough review.

I can also iterate on this skill. If there is something I’ve missed, such as adding rules on running unit tests, or pointing it to a coding style standard, I can update the skill and these changes will be picked up every time I ask the agent to review its work.

Summary

Skills are a great way to build repeatable processes into how you interact with a coding agent. If you do a task more than once with your agent, consider building it into a skill, a task that is pretty easy to do by asking your coding agent to create the skill for you.

You can get the code for my skill here: github.com/jimbobbennett/ai-skills

Who are the four main characters in fiction? We explore how these character roles function as literary devices—and how you can use them to strengthen your stories.

One of the easiest ways to tell if you have a plot, and not just a story idea, is by looking at the characters you’ve included in your story. You need to pay special attention to the four main characters who give your story the structure it needs.

Who Are The 4 Main Characters?

1. The Protagonist
2. The Antagonist
3. The Confidant
4. The Love Interest

Is It A Plot Or A Story Idea? The Protagonist Will Tell You

Beginner fiction writers often struggle to distinguish between describing a series of events and telling a story that truly makes readers care. If we do not learn how to shape our ideas into a plot using storytelling techniques — including using characters as literary devices — readers are far more likely to abandon our books.

Have you ever read a book where things simply happen, but there is no clear character for the reader to connect with? Stories without a strong central problem quickly lose momentum, and without a protagonist readers can identify with or empathise with, it becomes difficult to keep them emotionally invested. A compelling protagonist gives readers someone to follow through the conflict, making the story clearer, more engaging, and far more memorable.

Something happens in your story that negatively affects your protagonist’s life, creating a problem they must resolve. For the story to matter, the problem needs to be significant enough to create meaningful consequences and force the protagonist to act.

Why The Others Matter As Literary Devices

One of the most effective ways to make readers care about the protagonist is by using the other key characters to reveal who they are. A story rarely exists in isolation—without these relationships, the protagonist has nothing to react to, struggle against, or grow from. Each of these characters serves a distinct narrative purpose.

The love interest introduces emotional stakes and vulnerability. The antagonist creates conflict, which is essential for any story to move forward. The confidant offers support, and insight into the protagonist’s inner world.

Together, these characters shape the protagonist and the plot from different angles, making the story more dynamic and far more engaging.

How Writers Use The 4 Main Characters As Literary Devices

1. The Protagonist

A good protagonist is one who wants something (story goal), and sets out to get it. We need a proactive character in this role. A passive character will kill your story. A great protagonist makes decisions and chooses to act. These decisions and actions influence your story. John Gardner says, ‘Failure to recognise that the central character must act, not simply be acted upon, is the single most common mistake in the fiction of beginners.’

2. The Antagonist

On this journey, they meet resistance. This is usually a result of the antagonist’s actions. This causes the conflict that creates a plot. Remember that conflict must have consequences, so your antagonist has to be as strong as, or stronger than, your hero. As Franz Kafka said: ‘From a real antagonist one gains boundless courage.’ This character should be believable. Their motivation should be reasonable from their perspective. This character is the hero of their story, and your protagonist is their villain. (Suggested reading: Very Important Characters)

3. The Confidant

Along the way, the protagonist needs some help. Provide a confidant or a sidekick to support them in this quest. You need this character so that your hero does not spend too much time alone thinking about things. The friend is a sounding board for the main character. As Chuck Palahniuk says: ‘One of the most-common mistakes that beginning writers make is leaving their characters alone. Writing, you may be alone. Reading, your audience may be alone. But your character should spend very, very little time alone. Because a solitary character starts thinking or worrying or wondering.’

4. The Love Interest

To make your protagonist three-dimensional and to complicate their life, you should add a love interest to the mix. This character reveals the protagonist’s strengths and more importantly, their weaknesses. (Suggested reading: The Romantic Sub-Plot) Please remember that the character we use for this device does not have to be a romantic love interest. It just has to be somebody who is able to make your hero act irrationally and unreliably. Love makes fools of all of us. As Ernest Hemingway wrote: ‘I am so in love with you that there isn’t anything else.’

Why Are These Four Main Characters Important?

As literary devices, the main characters force us to show and not tell. The nature of the relationship between the protagonist and the other three leads to tangible interactions.

We have to talk to these characters and interact with them. We cannot avoid our worst enemies if they are determined to find us. We cannot ignore our best friends, unless we are prepared to risk losing those friendships. We cannot abandon the people we love most if we are human. (Suggested reading: The 3 Most Effective Types of Inner Conflict)

There will be other characters in your book, but they will be easier for your protagonist to deal with in a perfunctory manner. Too much of this type of interaction makes the character unsympathetic and boring.

(TOP TIP: Fill in Character Questionnaires for your main characters.)

So, you use your four main characters as literary devices to create a plot when:

1. An action (inciting moment) somewhere (setting),
2. Taken by somebody (your antagonist),
3. Has a negative impact on somebody else (your protagonist).
4. This creates a problem
5. That your protagonist must solve (story goal) by acting,
6. Which leads to confrontations with the antagonist and other characters (conflict in scenes and sequels).
7. This goes on for approximately 60-80 scenes and sequels.
8. Your protagonist is supported (can be a sub-plot) by somebody (confidant),
9. And made aware of their weaknesses (sub-plot) by somebody else (love interest)
10. Until they achieve, or fail to achieve, the story goal. (ending)”

In the next four instalments, I will discuss each of these four main characters as literary devices, and how you build a story around them, in more detail.

1. The Protagonist As A Literary Device
2. The Antagonist As A Literary Device
3. The Confidant As A Literary Device
4. The Love Interest As A Literary Device

The Last Word

Understanding the four main characters in fiction gives you a powerful set of tools to shape stronger stories. Use these roles as literary devices to deepen conflict, reveal character, and drive your plot forward. They can transform your novels and stories into more compelling, cohesive narratives.

by Amanda Patterson
© Amanda Patterson

If you enjoyed this article, read:

1. 5 Tips For Writing Vivid Fiction From Edgar Allan Poe
2. The 7 Qualities You Need To Become A Fiction Writer
3. Use Your Antagonist To Define Your Story Goal
4. The 7 Critical Elements Of A Great Book
5. Cheat Sheets For Writing Body Language
6. 9 Literary Terms You Need To Know
7. 3 Steps To Help You Find Your Story’s Theme

Top Tip: Sign up for our free daily writing links.

The post How Writers Use The 4 Main Characters As Literary Devices appeared first on Writers Write.