Week 12: Skills and Reusable Instructions

Learning objectives

By the end of this week, you will be able to:

1. Explain what a reusable instruction document is, in plain language, and describe why it saves time and improves consistency compared to retyping your preferences every time.
2. Describe, conceptually, what a file like CLAUDE.md does for an AI coding tool, and connect that idea to the custom instructions and system prompt concepts you have met earlier in this course.
3. Locate and use a chat tool's custom instructions setting, building on the exploration skills you have developed earlier in this course, to save a standing preference.
4. Save and organize a personal prompt library entry as a reusable instruction, rather than a one-time message, building on the personal prompt library habit you started earlier in this course.
5. Write a short, well-organized personal accessibility-first instruction set in Markdown, describing your own screen reader and formatting preferences, using file-editing skills you have practiced earlier in this course.
6. Identify at least two different ways to put a saved instruction document to use in an AI tool: pasting it into a settings field, referencing it at the start of a conversation, or attaching it as a file.
7. Explain the honest limits of a saved instruction set, and describe why the verification habits you have built throughout this course still apply to AI output produced under saved instructions.

Lesson

The problem this week solves: saying the same thing over and over

If you have worked through this course from the beginning, you have probably noticed a small, repetitive annoyance building up. Every time you start a new conversation with an AI tool, you find yourself typing some version of the same background information. You might explain that you are blind and use a screen reader, so you want plain text instead of dense tables. You might explain what kind of work you do, or what tone you prefer, or that you want short paragraphs instead of long ones. Then, in your very next conversation, an hour later or the next day, you often have to explain all of it again, because the AI tool has no memory of what you told it last time, or because you are asking a fresh question and do not want to scroll back through an old conversation to find the wording you used before.

This repetition is not just mildly annoying. It costs real time, message after message, week after week. It is also easy to forget a detail here or there, so your preferences end up stated a little differently each time, which means the AI's responses are a little less consistent than they could be. And it wastes some of the very skill you have been building in this course: once you have found a clear, well-worded way to describe your own accessibility needs and standards, retyping it from memory every time is a poor use of a good sentence.

You have already met two partial solutions to this problem earlier in the course. An earlier lesson introduced the custom instructions feature found in chat tools such as ChatGPT, a place where you can write a standing statement of your preferences once and have the tool apply it automatically to new conversations. Another earlier lesson introduced the system prompt, the idea that many AI tools let you set standing instructions that shape the AI's behavior for an entire conversation, or even across many conversations, rather than being just one more message you type and send, and started you building a personal prompt library. This week's skill removes the remaining repetition by turning those two ideas into one concrete, personal habit: writing your own reusable instruction document, once, in your own words, and then using it deliberately every time it is useful, instead of relying on memory or retyping.

A concrete example: the same request, twice

Imagine two versions of the same short scenario. In the first version, you open a chat tool on a Monday morning and ask it to help you draft a weekly status update for your team. Before you can even describe the update, you type out, once again, that you are blind and use a screen reader, that you want the reply in plain text with short paragraphs rather than a table, and that you prefer a brief, direct tone rather than a flowery one. Only after typing all of that do you finally ask your real question. On Tuesday, working on something unrelated, you open a fresh conversation and find yourself typing nearly the same three sentences again, because the tool has already forgotten them, and because you are not confident it would apply them anyway even if it remembered.

In the second version of this scenario, you have already saved an accessibility-first instruction set, and you have either pasted it into a custom instructions setting or you keep it ready to paste in at the start of a new conversation. On Monday, you open the chat tool and go straight to your real question about the status update, because your preferences are already in place. On Tuesday, the same is true again, in a completely different conversation about a completely different topic. The time you save is not dramatic in any single conversation, often just a minute or two, but it adds up across dozens or hundreds of conversations over months of regular AI use, and the consistency you gain, getting plain text and a direct tone every time rather than only when you remember to ask, is worth at least as much as the time.

This is the entire practical case for this week's skill in one small story. Nothing about the underlying AI tool changes between the two versions. What changes is whether you, the person using it, have taken the small, one-time step of writing your preferences down once, in a form the tool can use automatically or that you can reuse deliberately, instead of recomposing them from memory every single time you sit down to work.

What a skill file or instruction document actually is

Set aside any technical-sounding language for a moment, because the underlying idea is simple. A skill file, or instruction document, is a saved, reusable piece of text that tells an AI tool your standing preferences, your project details, or your standards, so you do not have to restate them by hand every time. It is often written as a Markdown file, the same plain text format with simple headings that you have practiced reading and editing earlier in this course, because Markdown is easy for a person to write and read with a screen reader, and easy for an AI tool to read and follow.

An instruction document can be used in two different ways, and it is worth knowing both, because you will use both this week. Sometimes it is read automatically by a tool, without you having to do anything once it is set up, the way a chat tool's custom instructions setting applies your saved preferences to every new conversation without you retyping them. Other times it is referenced deliberately, meaning you paste it in, attach it, or point the AI tool to it at the start of a conversation, because the tool you are using does not have an automatic setting for this, or because you want to apply a slightly different version of your instructions for a specific task. Either way, the underlying document is the same kind of thing: a saved, reusable statement of what you want, written once and used many times, instead of composed fresh, from memory, every single time you sit down to work.

It also helps to notice what an instruction document is not. It is not a single command that makes something happen once, the way a search query or a translation request does. It is standing context and standing preference, meant to apply broadly, across many separate requests, until you decide to change it. That distinction, a one-time instruction compared to a standing instruction, is the entire idea behind this week's lesson, and once you notice it, you will start seeing places to apply it throughout the rest of this course.

CLAUDE.md: a real example you have been living inside

Rather than describe this idea only in the abstract, it helps to look at one common, real pattern that AI coding tools actually use today, because it is a clean, honest example of everything described above. Many AI coding assistants support a plain Markdown file, often named CLAUDE.md, placed inside a project's files, that the AI tool reads automatically at the start of a working session. That file typically describes things like the project's goals, the style or formatting rules to follow, standing facts the AI should remember about the project, and any workflow steps the person building the project wants followed consistently. The AI tool reads it once at the start, and from that point on, its behavior in that project reflects what the file says, without anyone having to repeat those instructions by hand in every single request.

Here is the honest, useful part of this example: this very course, the one you are working through right now, was built using exactly this pattern. The project that produced these lessons has its own CLAUDE.md file, describing who the learner is, what accessibility standard every file must meet, how each week should be structured, and what to do at the start and end of each working session. Every week of this course, including this very page, was produced by an AI tool that read that instruction file first, so the standards inside it, plain language, a working skip link, properly labeled test questions, and so on, stayed consistent across many separate working sessions, without a person having to retype those standards from scratch every single time.

You do not need to become a programmer to take the lesson from this example. The lesson is simply this: a plain text instruction file, read automatically at the start of a session, is a genuinely reliable way to keep standards consistent across a long, multi-part piece of work, whether that work is a 24-week training course or your own ongoing use of an AI tool for your job or personal projects. You are about to build a much smaller, personal version of the same idea later in this lesson.

Custom instructions, revisited

Custom instructions, which you explored earlier in this course, are the most common example of an automatically applied instruction document you are likely to meet in an everyday chat tool. Custom instructions live inside a chat tool's settings area, usually reached through an account or settings menu, and they let you describe your standing preferences once: your tone preference, background information about your work or goals, and formatting needs such as plain text instead of tables, or short paragraphs instead of long blocks of text. Once saved, most chat tools apply your custom instructions automatically to every new conversation you start, without you doing anything else.

Custom instructions are a good fit for broad, general preferences that should apply almost everywhere you use that particular tool. A statement like "I am blind and use a screen reader, so please avoid describing things by color or visual position, and use plain text or short paragraphs instead of tables unless I specifically ask for one" is exactly the kind of standing preference custom instructions are built for. You will revisit this exact setting later this week, this time armed with a fuller instruction set to try inside it.

It is worth noticing what custom instructions are not, so you use them well. They are not the right place for information specific to a single task, such as the details of one particular report you are writing today; that kind of detail belongs in the conversation itself, not in a standing setting that will still be active weeks later, quietly shaping conversations that have nothing to do with that one report. Custom instructions work best when you ask a simple test question of anything you consider adding to them: would this sentence still make sense, and still be useful, in almost any conversation I might have with this tool, next week or next month. If the answer is yes, it belongs in custom instructions. If the answer is no, it belongs in that day's conversation instead.

It is also worth checking back on your custom instructions occasionally, the same way you might reread and update a resume every so often rather than writing it once and forgetting about it. As your goals shift, or as you notice a formatting preference you did not think to mention the first time, revisit the setting and adjust it, the same small, one-time-per-change effort that made the whole system worthwhile in the first place.

Saved prompts as reusable instructions, revisited

An earlier lesson introduced a different, related habit: building a personal prompt library, a saved collection of prompts you have already tested and found useful, so you can reuse and adapt them instead of writing a new prompt from scratch every time. This week asks you to look at that habit from a slightly different angle. A well-tested, carefully worded prompt is not just a one-off message you happen to reuse. It is a small reusable instruction in its own right, the same underlying idea as a skill file, just scoped to one specific, recurring task rather than to your overall standing preferences.

For example, if you regularly ask an AI tool to summarize a long document into plain-language bullet points at an eighth-grade reading level, with no information conveyed by color, you do not need to compose that request freshly every time. Once you have worded it well, save it, exactly as you would save any other reusable instruction, and reuse it the next time you have a similar document to summarize, adjusting only the specific details that change. Treating your best prompts this way, as saved instructions rather than disposable messages, is a small shift in mindset that pays off every time you reach for one again.

A practical walkthrough: writing your accessibility-first instruction set

Now it is time to build your own instruction document, in the same spirit as CLAUDE.md and the same file skills you have practiced earlier in this course. Call it your accessibility-first instruction set: a short, well-organized document, written in Markdown, describing your own screen reader and formatting preferences so that any AI tool you show it to has what it needs to work well with you from the very first message.

Start with three short sections, each written as a Markdown heading followed by one or two plain sentences underneath. The first section describes your screen reader setup: which screen reader you use as your primary tool and on which operating system, and which ones you use as secondary tools on other devices, since a well-informed AI tool can tailor keyboard instructions and interface descriptions to the tool you are actually using. The second section describes your formatting preferences, echoing the accessible-output prompting skills you developed earlier in this course: for example, "always use plain text or short paragraphs instead of tables unless I ask for one," or "use clear headings instead of long unbroken paragraphs," or "never convey information by color alone." The third section states any standing context worth mentioning once, such as your general goals from the AI Skills Roadmap you built earlier in this course, so an AI tool understands not just how to format its answers, but roughly what you are working toward.

Keep the whole document short. A good accessibility-first instruction set is closer to one page than five; the goal is a document you can realistically read in full using Say All, or your screen reader's continuous reading command, in well under a minute, and that an AI tool can absorb quickly at the start of a conversation. Long, cluttered instruction documents tend to get skimmed, by people and AI tools alike, while short, clearly organized ones tend to actually get followed. If you find yourself writing paragraph after paragraph, that is usually a sign to trim back to the sentences that matter most, not a sign that you need to explain more.

Write it the way you have practiced earlier in this course: open Notepad or VS Code, type your headings using Markdown's number-sign syntax, write your sentences underneath in plain text, and save the file with a name you will recognize later, such as my-accessibility-first-ai-instructions, using the .md file extension. You will keep refining this exact document for the rest of this course, so do not worry about making it perfect on the first attempt; a solid first draft, saved and ready to reuse, is this week's real goal.

Here is a short, complete example to give you a feel for the finished shape, not to copy word for word, since your own document should reflect your own voice and your own preferences. A first section titled "My screen reader" might read: "My primary screen reader runs on my Windows computer. I also use VoiceOver on my iPhone and occasionally on a Mac." A second section titled "My formatting preferences" might read: "Please use plain text or short paragraphs instead of tables unless I specifically ask for one. Use clear headings to organize longer answers. Never describe anything by color alone." A third section titled "My goals and context" might read: "I am working through a 24-week course to build AI skills for employment and personal growth. I am especially interested in writing and communication-related work." Three short sections, each just a sentence or two, are enough to make a real, practical difference in how an AI tool responds to you.

Where and how to use your instruction document

Once you have a draft, you have three practical ways to put it to work, and it is worth knowing all three, because different tools and different situations call for different ones. First, paste all or part of it into a custom instructions setting, the way you explored earlier in this course, so a chat tool applies it automatically to every new conversation without further effort on your part. Second, simply reference it at the start of a conversation by pasting it in as your first message, useful for a tool that has no custom instructions setting, or for a specific conversation where you want to state your preferences fresh, on the spot. Third, literally attach it as a file at the start of a conversation, the way you practiced uploading files earlier in this course, which works well for longer instruction documents or for tools that read attached files particularly well.

None of these three methods is universally correct; the right choice depends on the tool you are using and the task at hand. A quick, casual question might not need any of them. A long, important project, or a tool you use every single day, is usually worth the small, one-time effort of setting up custom instructions so you never have to think about it again. When in doubt, start with whichever method is fastest to try, and adjust once you see how the AI tool responds.

Honest limits: a strong nudge, not a guarantee

It is worth being completely honest about what a saved instruction set can and cannot do, in the same spirit of honest verification this course has emphasized from the start. A saved instruction document is a strong nudge, not a guarantee. Most AI tools follow saved instructions well most of the time, but not perfectly, every time, without exception. An AI tool might occasionally slip back into a table when you asked for plain text, or add a longer paragraph than you wanted, especially in a long conversation where earlier instructions can matter less than the most recent messages.

This means the verification habits you have built throughout this course do not disappear once you have a saved instruction set in place; if anything, they matter just as much as ever. Keep reading AI output carefully with your screen reader, the same way you always have, rather than assuming that because you saved good instructions, every single response will automatically follow them perfectly. If you notice an AI tool drifting away from your saved preferences partway through a long conversation, it is entirely reasonable to simply restate the specific preference that matters most in that moment, the same way you would politely remind a new coworker of a preference they briefly forgot, rather than treating the slip as a failure of the whole idea.

None of this makes a saved instruction set less worth building. Even an imperfect nudge that works most of the time saves real, meaningful effort compared to typing the same preferences from memory in every single conversation, and it is far more consistent than relying on memory alone. The goal this week is not a perfect, unbreakable system; it is a real, personal habit that saves you time and improves consistency in the vast majority of your AI conversations, while you keep the same thoughtful, verifying eye on the results that you have practiced from the start of this course.

Key terms from this week

Use this list to review the vocabulary introduced in this lesson before you start the exercises and the test.

Skill file / instruction document

A saved, reusable piece of text, often written in Markdown, that tells an AI tool your standing preferences, project details, or standards, so you do not have to retype them in every conversation.

Accessibility-first instruction set

A personal instruction document describing your own screen reader, formatting preferences, and standing goals, written so any AI tool can work well with you from the start of a conversation.

Keyboard-only exercises

These exercises use only your keyboard. Screen reader commands are described in general terms below; substitute your own screen reader's equivalent command where needed.

Exercise 1: Draft your accessibility-first instruction set

1. Open Notepad or VS Code, using the file-opening and editing skills you have practiced earlier in this course.
2. Create a new file and save it immediately with the name my-accessibility-first-ai-instructions.md, so you do not lose your work partway through.
3. Type a top-level Markdown heading, using one number sign and a space, reading "My Accessibility-First AI Instructions."
4. Add three second-level headings, using two number signs and a space: "My screen reader," "My formatting preferences," and "My goals and context."
5. Under each heading, type one or two plain sentences, following the guidance from this week's lesson.
6. Read the whole file back using Say All, or your screen reader's continuous reading command, to check that it reads clearly from top to bottom. If you are not sure what triggers this command, check your screen reader's own shortcuts list or help documentation.
7. Save the file again to make sure your changes are kept.

Exercise 2: Locate a custom instructions setting and save a preference

1. Open an AI chat tool you have used earlier in this course, such as Claude or ChatGPT, in your web browser.
2. Use your screen reader's list of links or interactive elements (sometimes called an elements list), or its landmark or region navigation, to locate a navigation or account menu region, an exploration approach you have practiced earlier in this course. Check your own screen reader's shortcuts if you are not sure how to open this list.
3. From that menu, find a settings or personalization area, and open it, reading each option with Say All, or your screen reader's continuous reading command, as you go.
4. Locate the custom instructions area, if the tool has one, and open your accessibility-first instruction set file from Exercise 1 in a second window, using Alt plus Tab (or Cmd plus Tab on a Mac) to switch between the two.
5. Copy one or two sentences from your instruction set, such as your formatting preference sentence, and paste them into the custom instructions field.
6. Save the custom instructions setting before closing the menu.

Exercise 3: Test whether your saved preference changes the AI's response

1. With your custom instructions from Exercise 2 saved and active, start a brand new conversation in the same AI tool.
2. Ask a question likely to produce a table by default, such as a request to compare three items across several features.
3. Read the AI's response with Say All, or your screen reader's continuous reading command, and note whether it followed your saved formatting preference, such as using plain text or short paragraphs instead of a table.
4. If you have access to an earlier conversation from before your custom instructions were active, compare its formatting to this new response.
5. Write one or two sentences noting what you observed, including whether the AI followed your saved preference perfectly, partly, or not at all, applying the honest-limits idea from this week's lesson.

Portfolio project: My Accessibility-First AI Instructions

This week's portfolio piece is a complete, polished version of the instruction document you started in Exercise 1. You will keep reusing and refining this exact file for the rest of this course, and potentially at work, so it is worth finishing it carefully.

1. Open your my-accessibility-first-ai-instructions.md file from Exercise 1 in Notepad or VS Code.
2. Review and expand the "My screen reader" section so it clearly names your primary screen reader and the operating system you use it on, and any secondary screen readers you use on other devices.
3. Review and expand the "My formatting preferences" section with at least three specific preferences, drawing on the accessible-output prompting ideas from earlier in this course, such as plain text over tables, clear headings, and no information conveyed by color alone.
4. Review and expand the "My goals and context" section, drawing on the AI Skills Roadmap you built earlier in this course, with one or two sentences about your general employment or personal growth goals.
5. Read the entire document one more time using Say All, or your screen reader's continuous reading command, and fix any sentence that sounds unclear or incomplete when heard rather than seen.
6. Save the finished file in the same portfolio folder you have used throughout this course, keeping the name my-accessibility-first-ai-instructions.md.

Weekly test

Answer key

Each answer below includes a one-sentence explanation drawn from this week's lesson.