A 60-minute core course with optional extensions. Read, try, check, and keep your work. This offline companion includes the written exercises and answer guidance; live responses and saved workbooks require the website.
Open the interactive course · Guidance checked September 9, 2026.
Allow five minutes for orientation, then 55 minutes for the six lessons. In the website, use Course agenda to see your position or choose another lesson. Glossary is always available. Help, Files and Notes open on request.
Artificial intelligence is a broad name for systems that perform tasks such as recognizing patterns or generating language. Today we’ll use generative AI: software that produces a response to your instructions using patterns learned during training.
ChatGPT and Claude are AI assistants from different companies. Codex is OpenAI’s agent for technical work. We’ll demonstrate ChatGPT; the prompting and checking habits also work in Claude.
Generated answers need checking against a source. ChatGPT is our main tool; Claude is an alternative. The website needs no account; AI exercises use your own account or a partner. No purchase is required.
Systems that perform tasks such as recognizing patterns, making predictions or generating language. AI is the broad category; this course uses generative AI.
AI that produces text, images or other content from instructions and context. A fluent response can still contain errors.
The trained system producing a response. An LLM is a large language model, trained to work with language. The app is the interface you use; the model is one system behind it.
OpenAI’s AI assistant. Use a chat to ask questions, explore ideas and revise drafts. Its desktop app also includes other experiences, such as Codex.
Anthropic’s AI assistant. Similar prompting habits apply, but accounts, menus, model choices and skill installation differ from ChatGPT.
OpenAI’s agent for work with code and technical tools. In the current desktop app it is a separate product view. It can also follow a document workflow when the right files and instructions are supplied.
Labels you may see within ChatGPT. Chat supports a conversation; Work handles longer tasks using available tools. Availability and placement vary. Work is not required for the first prompting exercise.
The instruction or question you send to the model. Useful prompts state the goal, relevant material, desired output and boundaries.
The place where you type or paste your prompt. Select Send to submit it. A follow-up in the same conversation can refer to the previous reply.
The instructions and material available for the current response, such as messages and supplied files. Naming a folder does not give the model access to its contents.
A generated claim that is false or unsupported, even when it sounds convincing. Check claims against the original source; asking the model to be accurate is not proof.
A reusable set of task instructions, often stored in SKILL.md. It tells an agent when and how to use a method. A skill is not a newly trained model.
A package that adds capabilities to an AI app. It can include skills and connections to tools. Installing a package and authorizing a connected account are distinct steps.
A connector provides access to another tool or source. MCP means Model Context Protocol, a standard some connectors use. Instructions in a skill do not grant account or file access.
An AI system that can use tools and work through steps toward a result. Its actions depend on the capabilities and permissions available to it.
A place to group related work or choose its files and instructions. Its meaning varies by app. Check which files the model can actually read.
Instructions guide a task; saved memory can preserve selected context across chats. Training changes a model’s learned parameters. Giving it a preference does not itself retrain the model.
Work configured to run later or repeatedly. Recognize the label if you see it; scheduling is outside this workshop’s practice.
A proposed code change for others to review, often on GitHub. This is a software workflow; you will not need it for this course.
Outcome: Start a chat, send a prompt and a follow-up, and find your practice files.
This is lesson 1 of 6. You will open ChatGPT, locate the few controls you need, and try a short conversation. Keep this course beside your AI app so you can read, try, and return.
Your prompt is the message you send. The model’s reply appears in the same conversation. A follow-up in that chat can refer to the reply. New chat starts a different conversation; provide the relevant material again rather than assuming it came along.
ChatGPT and Claude are apps from different companies. Codex is OpenAI’s agent for technical work. Within ChatGPT you may also see Chat and Work. The model picker is a separate control; leave its default for this exercise.
Learning goal: Open the desktop app, or choose the browser practice route.
Open the official download page, choose your operating system, and follow the installer. Launch ChatGPT and sign in with your own account. Already installed? Open it and continue. No API key is needed.
Learning goal: Locate the product selector, New chat, and the message box.
In the desktop app, open the product selector near the top left and choose ChatGPT. Select New chat. Find the message box, often labeled “Message ChatGPT.” If you see Chat and Work, choose Chat for this first conversation. You do not need to find a Work button to continue.
Learning goal: Find the brief and sample notes you will use next.
Download the kit and unzip it. Open the AI Workshop Practice folder, then read workshop-brief.md in a text editor. It describes a fictional volunteer learning hub. You will use its three notes in lesson 2; no real organizational research is needed.
Learning goal: Send a prompt and distinguish your message from the model’s response.
Copy the prompt into the message box in your AI app and select Send (the upward arrow). Watch your message and the model’s reply appear in the conversation. The reply is a draft you can question and change.
I am learning to use AI for everyday work. Today I will turn three fictional notes into a short brief and check it. Explain what a brief is in two plain-language sentences. Do not create the brief yet.
Learning goal: Use a follow-up to request a specific revision.
In the same chat, send the follow-up below. Compare the new reply with the first one. A follow-up can refine an answer without starting over. If it misses your instruction, point to what needs changing.
Rewrite that explanation for someone who has never written a brief. Use one sentence and avoid jargon.
Which control lets you ask a follow-up about a reply in the current conversation?
Answer: Correct. The same chat keeps the reply available as conversation context. You can use a follow-up to request a change.
Example: A finished setup has two messages you sent in one chat, two replies you can compare, and the practice folder available. Desktop and browser practice both support this first task.
If stuck: If installation or sign-in blocks you, use chatgpt.com in your browser, pair with someone, or read the supplied example in Help. During the live workshop, switch routes after three minutes of setup trouble. Record only what you actually tried; you can revisit setup later.
Reflect: Which tool did you use? What changed after your follow-up? Note any setup step you still need to finish.
OpenAI · Desktop interface guide · OpenAI · Free account limits
Outcome: Revise a vague prompt using a goal, relevant context, output format and boundaries.
A useful prompt is a small brief. You do not need a special phrase. Tell the model what you want, what it can use, and how you will judge the result.
“You are an expert” cannot supply missing facts. A specific goal, source material and useful output format do more work.
Run a first attempt, find what is missing, and revise that part. Read the new output against the source rather than accepting a more confident tone as an improvement.
Learning goal: Produce a first draft to compare with a revised request.
Paste the three fictional notes from sample-notes.md into your AI chat, then run this prompt. Keep the output so you can compare it.
Summarize these notes.
Learning goal: Specify sources, output and boundaries in a prompt.
In the same chat, replace the vague request with this prompt. Compare specificity, source references and claims. The exercise concerns a fictional volunteer learning hub; it is not Oppia research.
Using only the three fictional notes I provided, write a brief for the volunteer coordinator. Include: (1) two observations with note IDs, (2) one possible explanation labeled as a hypothesis, and (3) one question to investigate next. Use no more than 150 words. Do not invent quotes, counts, causes or people. If the notes cannot support a claim, say what is missing.
Learning goal: Correct one weakness and verify the revision.
Choose one unsupported or unclear sentence in the output. Ask for a targeted revision, then check that the change actually happened.
Check every factual claim in your brief against the supplied notes. Identify one weak claim, explain why the evidence is insufficient, and revise it. Keep observations separate from interpretations.
Which addition makes “summarize these notes” easier to evaluate?
Answer: Yes. You can check the source IDs, the claims, and the labels.
Example: Before: “People are confused by the platform.” After: “In N1, one volunteer found the lesson list but asked where to start.” The second statement stays within the evidence. It does not claim how common the problem is.
If stuck: If the model makes up a detail, quote the sentence back and ask which note supports it. Remove unsupported claims yourself if needed. A second model response is another draft, not verification.
Reflect: Paste your revised prompt and explain one change that improved the result.
Outcome: Limit the working context to the exercise folder and check a claim against its actual source.
Context is the material the model can use for this task. Your whole drive is rarely the right starting point. A small, named folder makes the task easier to explain and verify.
Select AI Workshop Practice as the working folder when your desktop mode supports local files. Otherwise attach just workshop-brief.md and sample-notes.md, or paste their contents. Ask what was actually read.
A working-preferences file can describe your tone, pace and output requirements. Providing it helps this task; it does not retrain the underlying model. Saved memory and project instructions have separate settings and scopes.
Learning goal: Supply only the files needed for this task.
In a fresh desktop task, select or open the AI Workshop Practice folder. If folder selection is unavailable, attach the two exercise files. Do not assume the model can see a folder just because you named it.
Learning goal: Verify file access using an exact passage.
Read the model’s answer and compare its file list with your actual folder. A correct-looking filename without content is not enough.
Use only AI Workshop Practice for this task. Tell me which files you can actually read, then quote the first sentence from sample-notes.md. If you cannot access the folder, say so and ask me to attach or paste the files. Do not claim to have read unavailable files.
Learning goal: Apply a working preference and check one source claim.
Open my-working-preferences.md and add one preference that matters to you, such as “lead with the next action.” Provide it to the model. Ask for the brief again and inspect one source claim yourself.
Read workshop-brief.md, sample-notes.md and my-working-preferences.md. Create a draft brief using only those files. Follow my preferences where they fit the task. Show the note ID next to each observation and label hypotheses. Show me the draft before saving or changing any files.
The model says “I read your folder,” but cannot quote the supplied note. What should you do?
Answer: Yes. Provide the needed material explicitly, then check a passage against the file yourself.
Example: N3 says one volunteer finished using a direct link sent by a teammate. It supports that observed route. It does not establish that navigation caused a failure or that a redesign would solve it.
If stuck: If the interface cannot read local folders, attach or paste the two Markdown files. If it reports an unreadable file, open it in a text editor and paste the text. Do not spend the workshop configuring a new connector.
Reflect: Which note supports one sentence in your brief? What does that note not tell you?
Outcome: Create or install an instruction-only skill and test whether it handles missing evidence.
A skill packages a repeatable method. Today you will give the model a short set of instructions for turning notes into a checked brief—and see whether it follows them.
Start from a task you have actually tried. A skill folder contains a SKILL.md file with a name, a description that explains when to use it, and the workflow. It may include supporting files; this practice skill needs no scripts.
Check that the skill is discoverable, invoke it explicitly, and inspect its output. Then test an incomplete input. A skill should ask for missing notes rather than manufacture evidence.
Learning goal: Identify the purpose and instructions inside SKILL.md.
Download evidence-brief.zip and unzip it. Read evidence-brief/SKILL.md in a text editor. It names its purpose, allowed sources, output and checks. Keep the folder together when moving it.
Learning goal: Create or install a scoped skill, or test its instructions.
Use the skill-creation controls available in your agent: Codex supports $skill-creator; ChatGPT Work supports @skill-creator where available. Supply SKILL.md or its text with the prompt below. Ask the agent to identify the installation route in your current interface. If unavailable, use the instruction-pasting fallback in Help.
Create an instruction-only skill named evidence-brief using the supplied SKILL.md as its starting point. It should turn provided notes into a short, source-linked brief and ask for missing evidence. Keep it scoped to this practice workspace, with no scripts or external connections. Tell me the exact file location and how to find and invoke it in this interface. Do not overwrite an existing skill with the same name.
Learning goal: Check the skill’s output against the supplied notes.
Invoke evidence-brief explicitly using your tool’s skill picker. Supply the three notes and ask for a brief. Confirm the output cites N1–N3 accurately and labels interpretations.
Learning goal: Test whether the skill asks for missing source material.
Start a new task, invoke the skill, and deliberately omit the notes. It should request them. If it invents a brief, edit the skill to make the boundary explicit, then repeat the test.
Use the evidence-brief skill to summarize the research findings. I have not supplied the notes yet.
Which result shows the missing-input test passed?
Answer: Yes. It recognizes that the task needs source material and does not invent it.
Example: A useful missing-input response is: “Please provide the notes you want summarized. I cannot create an evidence brief from findings that have not been supplied.” Exact wording can differ; the behavior matters.
If stuck: If your account cannot install standalone skills, paste SKILL.md into a new chat and test its instructions. Save the file for later. Record “instructions tested; installation pending.” In Codex, a local project skill lives at .agents/skills/evidence-brief/SKILL.md. Restart the app if a new skill is not detected. Claude has its own ZIP upload path in the optional lesson.
Reflect: Record your tool, where the skill lives, what happened in each test, and any correction you made.
Outcome: Distinguish a reusable skill from a connection to tools or data, and choose the smallest useful access.
A skill describes how to do a task. Files provide the material. A connector gives the model access to another system. MCP (Model Context Protocol) is one standard for those connections; a skill alone does not grant access.
The evidence-brief skill describes a process and quality checks. It does not automatically grant access to documents, accounts or apps.
Model Context Protocol lets an AI application communicate with servers exposing capabilities such as tools and resources. The client’s permissions and each server’s implementation determine what is accessible.
Need a repeatable method? Try a skill. Need a few files once? Attach them or select a folder. Need repeated access to a separate service? Consider an approved connector. Building a server is a later development task.
Learning goal: Choose a skill, files or connector for three distinct needs.
For “always cite note IDs,” choose a skill. For “summarize these three files,” provide the files. For “search an authorized team knowledge base repeatedly,” investigate a connector. Explain why each fits.
Learning goal: Specify the minimum access for a sample connection.
Imagine connecting to a practice notes library. Start with read/search access to that library. Identify a write or delete action you would keep out. Nothing needs to be connected during this lesson.
You want the model to repeat your brief-writing method. You already supplied the notes. What do you need first?
Answer: Yes. The method belongs in a skill; the required notes are already available.
Example: “Search the practice notes folder, return matching passages and filenames, and do not write or delete files.” That is a bounded connector specification. “Have access to everything” is not.
If stuck: If the terms are confusing, use this analogy: a skill is the recipe; a connector is access to an ingredient shelf or tool. The recipe does not unlock the shelf. The analogy is limited: real permissions still belong to the application and server.
Reflect: Name a task where a skill is enough, and a different task where a connector could help.
OpenAI · Build skills · Model Context Protocol · Introduction
Outcome: Evaluate your brief against source evidence and adapt the workflow to a small task of your own.
The finish line is a checked result and a method you can repeat. You do not need a perfect system. Keep the useful parts and make one next attempt.
Check whether each factual claim has a source, whether interpretations are labeled, and whether the next question is actionable. A polished paragraph can still be wrong.
Choose a low-stakes task with material you can verify: a meeting recap, a volunteer guide, or a project brief. Keep the task small enough to inspect the whole result yourself.
Learning goal: Remove unsupported claims from your brief.
Check your actual output against the supplied notes. Correct unsupported claims. Keep two observations, one explicitly labeled hypothesis, and one question. Do not turn fictional notes into real organizational evidence.
Learning goal: Explain the evidence for one claim.
If you have a partner, take two minutes each as author and reviewer. The reviewer asks, “Which source supports that?” Then swap. Working alone, answer the same question in your notes. This is practice reviewing an artifact, not simulated research.
Learning goal: Keep your work and define a new task with a verification step.
Open Notes and paste your final checked brief above your next-task reflection. Save those notes before you export your workbook, and keep the practice kit. Write one task you will try this week, which files you will provide, and how you will check the result.
Which next step demonstrates transfer?
Answer: Yes. New context gives you a chance to test whether the method transfers.
Example: Checked practice brief: N1 describes one volunteer asking where to start after finding a lesson list. N2 describes one volunteer pausing at a sign-in request. Hypothesis: clearer first-step guidance may help some new volunteers; these notes do not establish a cause. Next question: where do new volunteers hesitate during their first visit?
If stuck: If you did not finish the skill installation, keep the tested instruction file and mark installation pending. If you did not finish the brief, complete the two observations first. Your workbook is a record of practice, not a certificate of mastery.
Reflect: My next task is ___. I will provide ___. Before I use the result, I will check ___.
Outcome: Translate the workflow into another interface while checking its actual installation and access behavior.
The core method travels well. Buttons, permissions and skill installation paths differ. This optional lesson helps you make the switch deliberately.
Use the official Claude desktop installer or claude.ai. Prompting and source checks work in a normal chat. Custom skills use a ZIP upload flow; feature availability and organization settings may differ.
In the current ChatGPT desktop app, choose Codex for work involving a local software project and developer tools. A skill can still describe document work. The important distinction is the workspace and tool access you intend to use.
Learning goal: Compare the same source-based task across two tools.
Open a new chat in the second tool. Paste the same three notes and the improved brief prompt. Compare source fidelity and output boundaries; do not compare personality alone.
Learning goal: Install and test a Claude skill if your account supports it.
In Claude, enable code execution and file creation if required by your settings. Open Customize → Skills → + Create skill → Upload a skill. Upload evidence-brief.zip with its single root folder and SKILL.md, then enable it. Check the official guide if labels differ. Repeat the normal and missing-input tests.
Learning goal: Place and test a skill in a scoped Codex project.
Open only AI Workshop Practice as your working project. Place evidence-brief/SKILL.md inside .agents/skills in that project. Select the skill with $evidence-brief and repeat both tests. Ask before changing files outside that practice folder.
What transfers most reliably between AI products?
Answer: Yes. Transfer the reasoning and checks; verify the installation details separately.
Example: Tool A and Tool B can produce different wording while both passing the evidence checks. Neither passes if it invents participants, quotes or causes.
If stuck: If a feature is unavailable, keep working with plain text. Do not purchase a plan for this exercise. Installation can remain a clearly recorded follow-up.
Reflect: What stayed the same across tools, and what did you have to verify again?
Anthropic · Use skills in Claude · OpenAI · Build skills · OpenAI · Desktop quickstart
Outcome: Write and evaluate a specification for a small read-only MCP, with explicit acceptance tests.
This is an optional development exercise after the workshop. Use an AI coding tool to build a connector for the fictional practice notes. No API key, cloud account or live organizational system is part of the exercise.
Build a local tool that searches the exercise notes and returns matching passages with filenames. Do not begin with Drive, email or an organization-wide integration.
A generated server is a draft until you run it and test it. Define allowed files, missing-file behavior and rejected paths before asking the model to write code.
Learning goal: Identify the connector’s allowed capability and boundaries.
Download mcp-builder-brief.md. It defines search_notes, a read-only root, returned source passages and checks for unsafe paths. Keep the work in a separate practice project.
Learning goal: Turn the specification into a reviewable implementation.
Supply the brief and fictional sample files. Ask it to consult the current official MCP SDK docs for your environment, explain dependencies before installing them, and implement the smallest server that passes the specified tests.
Build the local, read-only practice-notes MCP described in mcp-builder-brief.md. Use the current official MCP SDK documentation. Before installing dependencies, explain what each is needed for. Restrict access to the supplied practice-data folder, reject paths outside it including symlink escapes, return source filenames and exact matching passages, and include the acceptance tests from the brief. Do not connect to an account, deploy a server, spend money, or write outside this project. Run the tests and distinguish tested behavior from anything unverified.
Learning goal: Run tests for accuracy and access boundaries.
Read the test results and manually check one returned passage against its file. Try a query with no matches. Try a path outside the allowed folder. Do not connect the server to a live workspace unless the boundaries pass and you understand the permissions.
Learning goal: Verify local client integration separately from server tests.
Follow your AI client’s current documentation for a local MCP server. The app must support the chosen transport; a local stdio server is not a hosted HTTPS endpoint. If your client cannot connect, preserve the tested project and record that integration is still pending.
The generated server runs, but can read a file outside practice-data. Has the exercise passed?
Answer: Correct. The requested capability is limited to the practice folder.
Example: A good no-match result is an empty list with “No matching passages found.” A fabricated summary of a nonexistent file is a failed test.
If stuck: Stop the optional build at a tested local project if your app lacks the right MCP transport. Keep the normal folder-and-skill workflow for useful work today.
Reflect: Which acceptance tests passed? Which behavior or client integration remains unverified?
Model Context Protocol · Introduction · MCP · Build a server