The Care and Feeding of Chatbots

Posted: May 18, 2026 | Author: computerGuyCJ | Filed under: Uncategorized | Tags: AI, Artificial Intelligence, chatbots, chatgpt, technology | Leave a comment

Part 1: Common Misses, or Teaching AI What Not to Waste Your Time With

TL;DR

I used AI to help write and refine this article, which seems fair given the subject. The point isn’t that AI should replace your thinking. The point is that AI works better when you give it durable context, clear constraints, and a list of things you already know you don’t want.

This is Part 1 of The Care and Feeding of Chatbots, a series about using reusable instruction files for everyday AI use. The broader idea of using “vault files” isn’t mine — I picked it up from Allie K Miller. The specific “Common Misses” name and concept came from Claude during one of my own experiments. What I’m sharing here is how I’m applying those ideas in practice.

This first piece introduces COMMON_MISSES.md: a file for capturing the suggestions, assumptions, formats, and defaults that usually miss the mark.

Part 2 will cover the rest of the instruction-file framework: what other files are useful, what belongs in them, and why most of the important stuff isn’t what people expect.

---

Most AI advice still sounds like it was written for someone using ChatGPT for the first time. Write better prompts. Be specific. Give it more context. That’s not wrong, but it’s incomplete — and it misses the actual problem most regular AI users have, which isn’t how to ask one good question. It’s how to make AI work consistently across many conversations, many tasks, and many moods, including the moods where you can’t be bothered to write a perfect prompt because it’s Tuesday night and you’re already tired of everything.

Software developers have already started solving a version of this. Modern agentic coding tools rely on small instruction files that tell the tool how to behave inside a project. Claude Code reads CLAUDE.md. Codex reads AGENTS.md. Copilot reads copilot-instructions.md. These files aren’t glamorous, but they’re often the difference between a coding assistant that works within your project and one that confidently wanders into the woods, invents a second architecture, and explains that this is “more scalable.”

The developer community figured out pretty quickly that you can’t just tell an AI tool “You’re an expert software engineer” and trust that the model knows what that means in your codebase, with your build process, your testing standards, your naming conventions, your security requirements, your legacy baggage, and your one file that everybody’s afraid to touch. So we started writing things down.

Instruction files usually contain a bunch of “do this” and “don’t do that” guidance, often organized under headings like Code Quality, Unit Testing, Architecture, Security, Pull Request Standards, or Things We Tried in 2021 and Will Not Be Repeating For Legal and Spiritual Reasons. The point isn’t that Markdown files are magical. The point is that reusable context matters. If you want an AI assistant to produce consistent work, you can’t expect every conversation to start from zero.

That same idea applies outside of code.

Most people, including software developers, still treat general chatbot conversations like disposable one-offs. We open the app and ask something like “Where’s a good place to eat tonight?” That sounds simple, except the chatbot has no idea what “good” means. Good for who? Good how? Cheap? Quiet? Open late? Won’t require a reservation?

This is where a lot of AI use quietly falls apart. The answer might be technically reasonable and still useless. The chatbot gives you a list. The list contains options. The options aren’t insane. But none of them fit you, your constraints, your energy level, your existing tools, your actual schedule, or the thing you were really trying to avoid.

You can solve that once by writing a better prompt. You can say, “I’m tired, it’s a weeknight, I don’t want to drive far, I don’t want anything spicy, I don’t want a place that requires reservations, and I need something that won’t make me regret being alive tomorrow morning.” That’ll probably get you a better answer. Once. Then the next time you ask, you get to type the whole thing again. And again. And again.

Even when AI tools have memory, custom instructions, projects, profiles, or workspace settings, they still benefit from explicit, durable guidance. Memory can help. Custom instructions can help. Project context can help. But they aren’t a substitute for having a clear written model of what the AI should consistently consider, avoid, prioritize, or ask about.

That’s where I think instruction files become useful — not necessarily as literal files in every tool, but as a portable framework for reusable context. One of the files I use in my own version of this approach is called COMMON_MISSES.md.

What Is Common Misses?

COMMON_MISSES.md is a file I tell chatbots to read before they work with me. It contains examples of past responses, habits, assumptions, formats, and suggestions that usually don’t work well for me. Not because those things are universally bad, but because they’re bad for how I work, how I think, or what I’m usually trying to accomplish.

A few examples from my own file:

• Don’t ask multiple clarifying questions at once. Pick one.
• Don’t bullet-point every response. Some things are better as sentences.
• Weigh suggestions against my likely energy level, time of day, and whether tomorrow is a workday. I’m not going hiking at 9pm on a Tuesday.
• Don’t recommend tools that require a new account, new service, or new subscription without asking whether I want to add to my existing stack.

This isn’t about making the chatbot “nice.” It’s about making it useful. A chatbot that knows what not to do can often be more helpful than one trying to guess the perfect thing to do.

That may sound negative at first. A file full of “don’t do this” and “avoid that” can seem like a strange way to improve creativity. But in practice, it often works better than trying to define the ideal answer upfront. The number of things you might want is enormous. The number of things you already know you’ll reject is usually much smaller.

That’s what makes “common misses” valuable. They’re reusable filters. They remove the obvious bad fits before the conversation spends energy on them.

Personal Example: Dinner, or Why You Keep Ordering Takeout

Say it’s Tuesday night and you need to figure out what to cook. You open your usual recipe sites. You scroll. You bookmark three things. You make none of them. Then you order takeout for the fourth time this week and pretend this was always the plan.

Or maybe you ask a chatbot for dinner ideas. It gives you recipes that all assume you have fresh herbs, a clean kitchen, emotional stability, and 90 minutes of available time. You pick the least bad option. Halfway through, you realize you’re missing two ingredients, one of the steps says “meanwhile, make the reduction,” and somehow you’re now eating pasta with whatever was in the fridge.

This is exactly where COMMON_MISSES.md helps. Instead of asking the chatbot to magically know what you want, you tell it what to filter out before it starts suggesting things.

For example:

• No recipes with more than ten ingredients.
• No recipes over 45 minutes.
• No recipes requiring a separate trip to a specialty store.
• No recipes using techniques I’ve never tried before.
• No recipes whose first instruction is “the night before, marinate…”

That last one should be illegal on weeknights.

The chatbot doesn’t need to know exactly what you’re hungry for. Half the time, you don’t know exactly what you’re hungry for. What it needs to know is what you’ll reject immediately.

The list of disqualifiers is short. The list of “perfect recipes for me tonight” is essentially infinite, changes by mood, depends on what’s in the fridge, and is why you keep ending up with DoorDash. Filtering out the obvious misses first isn’t glamorous. But it works.

Professional Example: Dependency Selection, or Future You Hates Present You

The same idea applies at work.

Say you’re adding a feature and need a library. Maybe you need to parse JSON in some unusual format. Maybe you need authentication, image processing, PDF generation, logging, charting, scheduling, or one of those deceptively simple tasks that starts with “surely there’s a package for this” and ends three days later in a GitHub issue from 2018.

You ask the AI what library to use. It suggests the popular one. You install it. You ship the feature. You move on.

Six months later, you find out the library has a known unpatched CVE. Or it’s maintained by one person who just changed jobs. Or the original package is dead and everyone quietly moved to a fork. Or it pulled in fifty transitive dependencies and now your bundle size has developed ambitions. Congratulations. You saved twenty minutes and purchased a future incident.

This is another place where a “common misses” file earns its keep. Instead of asking the AI to find the “best” library from scratch, tell it what kinds of libraries shouldn’t even make the first cut.

For example:

• No libraries with unpatched critical CVEs.
• No libraries with only one active maintainer.
• No libraries that haven’t had a meaningful commit in the last six months.
• No libraries that pull in a large dependency tree without a strong reason.
• No libraries with licenses incompatible with the project.
• No libraries that have been effectively replaced by a community-blessed alternative.

The chatbot doesn’t need to magically know the perfect library before the conversation starts. It needs to keep the bad candidates off your desk.

That’s the boring work you don’t want to repeat every time you add a dependency. Most of these checks are security and maintenance concerns you don’t really want to think about every time, but you do want handled. Once those options are filtered out, then you can have the more useful conversation: Which library fits this project? Which one matches the team’s style? Which one is easiest to maintain? Which one will future-you hate the least?

That’s where AI can actually help. But only after the rejection list has done its job.

Why “Don’t Do This” Is More Useful Than It Sounds

A lot of COMMON_MISSES.md is negative language. Don’t do this. I don’t want that. No tools like this. Avoid suggestions that assume that.

At first, that can feel backward. Shouldn’t we tell the chatbot what we do want? Sometimes, yes. But the problem is that the number of potentially good answers is enormous, while the number of known deal-breakers is usually manageable.

Most of us are open to a wide range of options except for a handful of things we already know won’t work. We have foods we hate. Tools we don’t want to use. Formats that annoy us. Suggestions that sound good in theory but collapse immediately when exposed to a normal Tuesday. Workflows that look elegant in a demo and then die when they meet an actual legacy system, an actual budget, or an actual human being with 23 minutes before their next meeting.

So name the deal-breakers. Write them down. Give the chatbot the list of things you’re likely to reject anyway. That doesn’t make the conversation rigid. It makes it more efficient. You’re not telling the chatbot to stop being creative. You’re telling it not to waste its creativity on things you already know are wrong for you.

That’s the simple reason this works. There’s a second reason, and it’s the more important one.

A rejection list isn’t only a filter. It tells the chatbot which dimensions actually matter to you. Once it knows what you reject, it knows what to ask about. The conversation gets sharper because the chatbot has a much better idea of which clarifying questions are worth asking and which would waste your time.

Without a rejection list, a chatbot asking what kind of dinner you want defaults to obvious dimensions: cuisine, dietary restrictions, prep time. Those are sometimes the right questions, but usually they aren’t — by the time you’ve answered them, you’re still nowhere closer to dinner. With a rejection list, the chatbot already knows you’ve ruled out long prep times, complicated techniques, and specialty-store ingredients. The remaining dimensions are different. The question becomes “what’s your energy level tonight, and do you want one of your usual rotations or something new within those constraints?” That’s a question that actually helps you decide.

Pair the rejection list with another standing instruction — something like “ask a clarifying question when current conditions might change the answer” — and the chatbot’s questions get noticeably better. Instead of suggesting “why don’t you go for a hike?” at 9pm on a weeknight, it might ask “do you have to work tomorrow, and how much energy do you actually have right now?” And depending on the answer, it might correctly suggest you stream The Lord of the Rings and fall asleep somewhere around Rivendell.

The Bigger Point

COMMON_MISSES.md isn’t magic. It doesn’t turn a chatbot into a trusted advisor, senior architect, personal chef, therapist, business consultant, or dependency auditor. What it does is simpler and more useful: it gives the chatbot a list of ways not to waste your time.

That matters because many bad AI responses aren’t wildly wrong. They’re slightly wrong in ways that make them useless. Too generic. Too eager. Too formal. Too verbose. Too dependent on tools you don’t use. Too optimistic about your available time, energy, patience, budget, or willingness to create another account.

A good “Common Misses” file helps remove those answers before they land. And once the obvious misses are gone, the actual conversation gets better.

This is where I think a lot of practical AI use is headed. Not toward everyone becoming a prompt engineer, and not toward every problem being solved by a giant enterprise platform. The useful middle ground is reusable context: durable instructions, known constraints, recurring preferences, and clear rejection rules.

In other words, the same basic lesson developers are learning from agentic coding tools applies much more broadly. If AI is going to be part of everyday work, we need better ways to tell it how we work.

COMMON_MISSES.md is one file in a larger framework I’ve been building: a set of instruction files that do for everyday chatbot conversations what AGENTS.md, CLAUDE.md, and copilot-instructions.md do for coding agents.

Because if we’re going to keep inviting these tools into more of our work and our personal lives, we should probably stop making them guess who we are every time.

Next time, I’ll get into the rest of that framework: what other instruction files are useful, what belongs in them, and why most of the important stuff isn’t what people expect.

The Care and Feeding of Chatbots, Part 2: Building the Rest of Your Instruction Files

---

echo "alias ollama='winpty ollama'" >> ~/.bashrc
source ~/.bashrc