Working
with AI.

Set aside about ten minutes for this practice. The aim is to produce something useful and improve it once. Learning twelve new product names is optional.

Give it a small, complete job

Open the AI app your organization permits. Paste the following request into a new chat or work task. Everything needed is inside the prompt.

This is a fictional practice task. Label the output PRACTICE.

Turn these meeting notes into:
1. Decisions made.
2. Actions, with an owner and a date only when the notes provide them.
3. Open questions.
4. A short follow-up draft for my review.

Use only these notes. Do not turn a suggestion into an agreement.
Mark missing information as unknown. Do not send anything or change files.

Notes:
We discussed a customer workshop. The team chose an online format.
Sam will check facilitator availability by 18 September 2026.
Jo suggested a budget of $2,000, but nobody approved it.
We still need to decide who will invite customers and when the workshop runs.

Compare the result with this example

An acceptable answer could look like this. The wording can differ; the facts should not.

PRACTICE

Decision: Run the workshop online.

Action: Sam will check facilitator availability by 18 September 2026.

Open questions: Is the proposed $2,000 budget approved? Who will invite customers? What is the workshop date?

Follow-up draft: We agreed to run the workshop online. Sam will check facilitator availability by 18 September. We still need to confirm the budget, invitation owner, and workshop date.

If the AI says the budget is approved, the answer is wrong even if the layout is lovely. A polished table can still contain nonsense. It has simply put on a tie.

Make one meaningful correction

Suppose the draft is accurate, but the open questions are buried at the bottom. Try:

Put the unresolved decisions first so I can see what needs attention.
Then show the agreed decision and Sam's action.
Keep the budget clearly marked as a proposal, not an approval.
Do not change the facts or send anything.

Check that the revised answer changed the order without changing the meaning. You have now practised briefing, checking, and steering. Those three habits support much larger work.

Leave yourself a useful return point

Give me a five-line handoff I can save and use next time:
the task, what we finished, unresolved questions, the useful writing preference,
and the next step. Keep it labelled PRACTICE. Do not save it into real client records.

Save that note somewhere you can find it. In a new chat, attach or paste it and ask, “What is the next step?” A sound answer should recover the open decisions. It should not claim the workshop happened.

You can stop here. Try this with one small piece of approved work next. Leave confidential or sensitive material out until your organization has approved the tool and data use. If you want to understand why the exercise worked, continue below.

Think of a chat as a conversation at a colleague's desk. You ask a question, discuss options, or improve a paragraph together. In a work task, you give that colleague a result to produce and the resources they need to produce it.

“What belongs in a workshop proposal?” starts a discussion. “Use these notes and our approved template to create a workshop proposal, flag missing terms, and return a draft” delegates a job.

The difference is the amount of work you hand over. Ordinary chat can also use tools, read files, or produce documents. Work modes are designed to carry a larger task through several steps while you steer and review. OpenAI's Chat and Work comparison explains this distinction for ChatGPT.

What the AI actually does

A typical work task moves through a loop: read the request, plan the next step, use an available tool, inspect what happened, then continue or ask for help. The model supplies language and reasoning. Tools let it search, calculate, read files, or make changes. An agent is an AI system arranged to carry out work through such steps.

The colleague analogy has a limit. AI does not carry human accountability or reliably know when it is wrong. It can misunderstand a source, miss a condition, or sound certain about a guess. Your brief and checks still matter.

Choose the mode that fits the job

Start with the simplest mode that can finish the job. A two-line reply does not need its own operations department.

Three products with similar ambitions

Claude Cowork is Anthropic's way to delegate work across files and connected tools. Microsoft Copilot Cowork operates in Microsoft's environment, including supported Microsoft 365 services. ChatGPT Work is OpenAI's work experience for producing reviewable results using available files and tools. They are separate products. A skill or button in one is not automatically present in another. See the platform notes for the right starting route.

Try it: take a question you often ask AI and rewrite it as a deliverable. Replace “Help with our report” with “Produce the report from these sources, with these checks.”

See what you could make

These are small illustrative outputs, using invented inputs. They show the shape of useful work. They are not product recommendations or reports of actual results.

A comparison that helps you choose. Suppose you need four seats and data export. Your sample research notes say Option A supports both for $40 per month; Option B has six seats for $30 per month but no export. A useful result makes the deciding fact visible:

The value is an explicit comparison against your needs. For real research, supply or retrieve current sources and inspect the claims that determine the choice. Give it a useful brief.

One source, ready for different readers. A fictional approved notice says: “The community repair event is Saturday, 10 a.m. to noon. Volunteer registration closes Thursday.” Ask for a newsletter item and a short social post:

Newsletter: Help out at Saturday's repair event, from 10 a.m. to noon. Register as a volunteer by Thursday.

Social draft: Have two hours on Saturday? Volunteer at the repair event, 10 a.m. to noon. Register by Thursday.

The AI changes the format while keeping the facts. You check the tone and add the approved registration link. It should not invent a venue, guarantee repairs, or publish the drafts. Check and improve the work.

A project update that surfaces the next decision. Instead of rereading two weeks of notes, you get an update that says:

You can see what needs your attention. The complete walkthrough supplies both weeks' notes, the prompts, the checks, and the path to repeating the work.

Choose a job you understand well enough to judge. Familiar work gives you a better error detector than an impressive-looking answer does.

A useful brief tells the AI what a capable colleague would need to know. You do not need to guess a secret prompt formula.

Explain the outcome, the reader, the sources, the constraints, and how you will judge the result. Include the details that change the work. An entire company archive is usually a poor substitute for the current template and the right notes.

For the workshop, “Make a proposal” leaves the AI to guess what is being offered, to whom, and on what terms. This is more useful:

Create a review draft of a one-page workshop proposal for a prospective customer.

Use the attached meeting notes and the approved proposal template.
The reader needs to decide whether to discuss scope with us.
Use plain language and make the proposed outcome easy to find.

Treat the online format as agreed. The budget, date, and invitation owner
are still unresolved. Mark them clearly; do not invent terms.

Done means: the draft follows the template, its factual claims match the notes,
unresolved terms are visible, and the next decision is clear.
Return the draft for review. Do not send or publish it.

Ask me only for missing information that would materially change the result.

If you cannot yet describe the result, say:

Help me define this job before building it. Ask one question at a time about
the outcome, audience, source material, and what a good result must contain.
Then show me a short brief we can use.

Tell it what matters most

Sometimes requirements compete. A proposal cannot explain every detail and remain a short introduction. State the tradeoff: “Prioritize a clear buying decision. Put technical detail in an appendix.”

Give a good example when you have one, and explain what to copy from it. “Use the structure of this proposal” should not become “reuse its old client's price and promises.”

Voice works too. Talk through the job, then ask the AI to write back the brief. Check names, numbers, and dates after dictation. You can be conversational without leaving the assignment vague.

Ready to move on: the AI can restate the desired result and its important limits in a few sentences. If it cannot, fix the brief before asking for more output.

These words describe different parts of your working setup. Treat a project as the room for an area of work, a folder as a place to keep files, and a chat or task as one job being discussed in that room. A room can contain several jobs. A folder does not know which document is correct merely because its name sounds official.

Context is the information the AI has available for the current work: your request, selected conversation history, instructions, files it has read, and results returned by tools. “The file is somewhere in the project” and “the AI used that file” are different statements.

Start with a small working set

For recurring workshop work, a useful arrangement might be:

Workshop work/
  Brief and current state.md
  Sources/
    Approved template.docx
    Meeting notes.txt
  Drafts/
    Workshop proposal v1.docx

This is an example, not a required folder system. If your company already has a sensible place for these files, use it. A .md file is plain text with simple formatting. You can keep the same information in an approved document if that fits your tools better.

Keep one agreed current version. Rename old drafts clearly. “Final”, “Final revised”, and “Final actually final” is a naming system with a short life expectancy.

Use a new task for a distinct outcome, such as preparing the proposal versus checking the final presentation. Continue the same task for revisions to the same result. Keep related work in the same project when its sources and permissions belong together.

A project is not always a folder

In ChatGPT, a cloud project can hold chats, uploaded files, instructions, and connected sources. Local desktop projects can attach folders on your computer. A cloud project does not by itself give access to your local drive. See OpenAI's projects guide.

Claude Cowork Projects can gather folders, instructions, links, and project memory. Claude's chat projects and Cowork projects have distinct behaviour; check the current Cowork Projects guide before moving work between them.

For Microsoft Copilot Cowork, use the files and task views available in your account. Its input and output areas help you find source files and generated work. Do not expect Claude's local folder setup to be the Microsoft setup. Microsoft's getting-started guide shows its file flow.

Context has limits

Picture a desk with limited working space. The filing cabinet may contain years of material, but only some of it is open on the desk. Long conversations can be summarized; tools may retrieve only part of a source. A new task may need to read saved notes before it can continue accurately.

For important work, ask: “Which exact sources did you use, and what could you not access?” If two sources conflict, ask the AI to show the disagreement. Tell it which source has authority rather than allowing it to quietly combine incompatible versions.

Separate client work when information must remain separate. Use your organization's access controls as well as clear project boundaries. A folder title or a prompt saying “only use this client” is not a security lock. Connected accounts can have their own access scope, as explained in the ChatGPT Work overview.

Try it: give the AI the current template and one old example. Ask it which source governs structure and which governs facts. Correct any confusion before it drafts.

A session routine is a small handover habit. It helps avoid spending the first ten minutes reconstructing the last ten minutes of yesterday.

“Start my session” and “Wrap up” are useful names for that habit. They are not universal commands that install a memory system. They work when your instructions explain them and the AI can reach the saved record. Otherwise, use the full prompts below.

Start with the current state

Start my session. Read the attached current-work note and the sources it names
that you can access. Tell me the last completed step, unresolved decisions,
and the next useful action. Distinguish saved facts from your assumptions.
Tell me if a source is missing. Do not change files or send anything yet.

Once oriented, give the next job. You need not ask for a new plan after every small step. If the result is heading off course, steer it while it works: “Keep the agreed outline. Focus this revision on the budget section.”

Finish with a useful handoff

Wrap up this task. Summarize the completed work, decisions, unresolved questions,
exact output location, and next action. Include only reusable corrections
that matter to future work.

If updating our current-work note is already authorized, update it and show me
what changed. Otherwise return a short note I can save. Do not claim it is
saved unless you can confirm the actual saved record. Do not send anything.

The note can be short:

PRACTICE: Workshop proposal v1 is drafted. Online format is agreed. Budget and date remain unresolved. Put open decisions before background in workshop summaries. Next: confirm the missing terms, then revise the proposal. Nothing has been sent.

Save the useful state, not a transcript of every turn. It should tell the next session where the work stands and which version to use.

Think of a bookmark with a note in the margin. The bookmark tells you where to resume; the note reminds you what mattered. Neither helps if the next reader never opens the book. The AI must actually read the saved handoff.

Check the return path once

Open a new task in the same approved project and ask it to recover the next step from the saved record. If it cannot, fix the file location or reading instruction. Do not keep rebuilding the whole workspace.

When moving work between AI products, hand over the same compact note and relevant files. Do not expect another product to know your old conversation. Keep one task responsible for edits to a given file so two assistants do not rewrite each other's work.

Ready to move on: you can leave, return, and continue from a correct saved state without retelling the whole story.

“Make it better” gives the AI very little to work with. Helpful feedback names the miss, explains its effect, and shows the desired change.

Compare “This sounds wrong” with: “This is too formal for a familiar customer. Keep the decision and next step, remove the sales language, and use the tone of this approved example.”

You do not need to diagnose the whole system. Point to the part that failed. The AI can help turn that observation into a specific correction.

Three things people mean by learning

The thumbs-up or thumbs-down button is product feedback. It is not a reliable way to install your company's writing rule. If a correction matters next time, put it in an appropriate place and verify that later work uses it.

OpenAI distinguishes memories from required project instructions in its personalization guide. Claude documents project memory in its Projects guide. Neither is a reason to treat an unverified recollection as the current approved record.

Turn one correction into reusable guidance

You treated a suggested budget as approved. Repair this draft.
Then propose one short rule for our proposal guidance that prevents the mistake.
Apply it only to proposal work. Show where the rule should live and how we can
test it with a new example. Do not install or change shared instructions yet.

A useful proposed rule would be:

Separate agreed terms from suggestions. Label a price, date, or responsibility as approved only when the supplied source explicitly supports that status. Otherwise flag it for confirmation.

Once the right person approves saving the rule, save it in the existing guidance. Next time, give the workflow notes containing both an approved item and a suggestion. Check that it distinguishes them. This verifies useful behaviour more convincingly than an answer saying, “I have learned my lesson.”

Keep learning small and specific

Use this loop: notice a miss → correct the work → save the useful rule → try it again.

A one-off preference may belong in this task only. A repeated report format belongs with that report. A company-wide instruction belongs with its owner. Avoid piling every correction into global instructions; rules can contradict each other or make simple jobs awkward.

Keep a change when the next use shows it helped. More instructions and more skills are not measures of improvement.

Try it: select one recurring annoyance. Write the correction, name where it belongs, and choose the next normal task that will show whether it worked.

These are related, but they solve different problems. Imagine a colleague preparing a workshop proposal.

The names and packaging vary. If you see MCP, it means Model Context Protocol, a standard way for AI software to connect to tools and resources. Think of a common plug shape. Matching the plug does not decide what the connected account is allowed to do. OpenAI explains the pieces in Skills and Plugins; Microsoft documents its Cowork customization.

Add access when a real task needs it

If you only need to summarize one approved document, attach it. If you repeatedly need the latest version from a shared drive, an approved connection may remove repeated downloading and uploading.

Connecting an app can involve several separate steps: make the plugin available, connect the right account, grant permitted actions, and confirm the required source is reachable. Installation alone is not proof of access.

Ask the AI to perform a small check: “Find this named document and report its title and updated date. Do not change it.” Then inspect the source it found. A confident summary of the wrong file is still the wrong file.

Reading and writing are different permissions

Reading a calendar is different from inviting ten people to a meeting. Finding a proposal is different from replacing it. Check the actual connection, account, and action settings. A connected account can have broader permissions than the particular task needs. OpenAI's Work access overview describes these layers.

For your first connected workflow, choose a narrow purpose and a clear output. Ask for a draft and handle sending yourself. Use available app and admin controls to support that boundary; a written instruction alone is not a technical guarantee.

Try it: name one repeated step a connection would remove. If you cannot name the step, leave the connection for later.

A prompt is a request you make now. A skill is a reusable way to handle a class of requests. The skill might include steps, a template, examples, and checks. It earns its place when those details repeatedly matter.

You would not write a staff handbook for one sandwich order. You might write a clear procedure for the lunch service you run every day. Apply the same restraint to AI.

What belongs in a useful skill?

For a workshop proposal, the useful parts are concrete:

• When to use it: turning approved discovery notes into a proposal draft.
• Inputs: current notes, the approved template, and confirmed commercial terms.
• Steps: extract facts, flag gaps, draft, then check against the sources.
• Output: a proposal with unresolved terms clearly marked.
• Limits: do not invent approval or send the result.

Keep current client facts in the source files. Keep the reusable method in the skill. Otherwise, a rule intended to improve every proposal can quietly carry one client's details into the next.

Create the instructions before installing them

Turn the workflow we just used into a draft skill for future workshop proposals.
Include when it applies, required inputs, the drafting steps, quality checks,
and the approval boundary. Use our corrected draft as a structural example,
but remove its client-specific facts.

Keep it short. Reuse existing guidance rather than duplicating it.
Return the instructions for review; do not install or share them yet.

After approval, use your product's supported skill setup. Test it in a new task with new material: the output should follow the method without carrying over old facts.

OpenAI supports explicit skill selection and automatic matching; its skill guide explains the surface-specific syntax. Microsoft's customization guide explains creating, importing, and testing custom skills. For Claude, use the official skills help.

Reuse across products carefully

The written method often transfers well. The package, file paths, commands, permissions, and tool names may need adaptation. Have the receiving app check compatibility instead of promising that a ZIP works everywhere.

Ready to move on: a new task uses the skill on different material and meets the same checks without carrying over old facts.

Chaining means giving several methods a useful order. A proposal workflow may gather evidence, draft, review, challenge assumptions, and revise. You can request those stages in ordinary language before installing any named skills.

Think of a kitchen. Preparation, cooking, and checking the plate have different jobs. Adding five more cooks does not fix a missing ingredient. Each stage should contribute something the others do not.

Follow one proposal through the chain

In the workshop example, a source check catches the unsupported budget. A reader review notices that the next decision is unclear. A stress test asks whether the proposed date depends on an unavailable facilitator. Those are distinct checks with practical consequences.

Review the work against a standard

Review this exact proposal against the attached brief, notes, and template.
Check factual support, missing requirements, clarity for the customer,
and the decision they need to make next.

For each material defect, show its location, why it matters, and the smallest fix.
Repair the draft, then check the changed sections again.
Do not change agreed terms or add unsupported claims.

Stress test the assumptions

Stress test this proposal. What is the strongest credible reason the customer
could reject it or the delivery could fail? Use the actual scope and sources.

Separate an observed problem from a hypothetical risk. Tell me what evidence
would change your assessment. Recommend only changes that materially improve
the decision or delivery. Do not invent objections to fill a list.

Asking the same AI to play “finance director” and “customer” provides useful viewpoints. It does not create two independent experts. Both can repeat the same false premise. For consequential facts, use the underlying evidence and a qualified person where the decision requires one.

What OneShot means here

OneShot is Sidekick's name for a workflow that carries substantial work from a brief through building, checking, improvement, and a clear handoff. It is a custom method, not a universal feature included in every AI account. If it is installed, ask for it. If it is not, this prompt describes the method:

Take this task from brief to a checked draft. Use only the stages it needs:
clarify important gaps, plan, build, check the sources and requirements,
repair material weaknesses, and return the exact result with remaining decisions.
Use available relevant skills. If a named skill is missing, say so and follow
the method directly. Stop before any external action I have not approved.

Stop reviewing when the required checks pass and no material defect remains. “Make it 10% better” repeated indefinitely is a fine way to spend the afternoon moving commas.

Try it: run one source check and one stress test on a small draft. Notice whether they find different kinds of problems. Keep the checks that change the result.

A goal describes the result you want. An evaluation, often shortened to eval, checks whether the result meets a standard. Think of ordering a bookshelf: the goal is a shelf that fits the space and holds your books; the evaluation includes measuring the space and checking whether the shelf wobbles.

“Work on my proposal” names activity. “Create a proposal draft that follows this template, separates confirmed terms from gaps, and gives the customer a clear next decision” describes a finish line.

Write a finish line the AI can check

Goal: create a review draft of the workshop proposal using the supplied sources.
Include the outcome, proposed scope, known responsibilities, unresolved terms,
and the customer's next decision.

Use the approved template. Do not invent prices, dates, or commitments.
Finish when every required section is present, factual claims are supported,
the document opens correctly, and any remaining decisions are clearly listed.
Return the draft and stop before sending or publishing.

In supported ChatGPT desktop and Codex surfaces, /goal can keep a defined objective active across longer work. For ChatGPT Work on the web, put the outcome and completion checks in the task prompt. A goal does not grant broader access or guarantee that work succeeds. See OpenAI's long-running work guide.

If the goal is unclear, define it with the AI first. “Automate my business” leaves too much unresolved. Start with “Prepare a weekly update from these two approved sources, without posting it.”

Use checks that could catch a real failure

For the workshop practice, a small evaluation set looks like this:

These are practice checks, not a scientific benchmark. They make “good” less subjective and expose mistakes a pleasant writing style can hide.

Match the check to the work: recalculate a spreadsheet total, trace a summary to its notes, inspect a design at its intended size, or challenge the evidence behind a recommendation.

A score is not proof

An AI giving its own work 96/100 has told you its opinion. Ask what was checked and what evidence supports the result. A missing legal term or wrong customer cannot be averaged away by excellent spelling.

Check the artifact and the workflow separately. A correct draft shows that this task worked. Repeated useful runs, with the effort and cost recorded, help you judge whether the workflow is worth keeping. Neither guarantees future success.

Ready to move on: you can name a few ways the work could fail, run those checks, and distinguish a finished result from an unresolved task.

Once the AI produces a useful result repeatedly, you can remove some of the effort around starting and moving the work. Automate one stable part at a time.

A recipe tells you how to make dinner. A timer tells you when to start. A schedule cannot rescue a bad recipe; it can only arrange for the same problem to arrive punctually.

Move up one step at a time

Sending communications, changing official records, or making purchases involves different consequences from preparing drafts. Keep the human decision where the work requires it. More autonomy is useful when it reduces total effort without creating unacceptable errors.

Design a small recurring workflow

Choose one recurring output you already know how to check. Write down the trigger, current inputs, destination, quality checks, and what should happen when a source is missing or a run fails. Name the person who handles exceptions and can pause it.

Test the workflow manually with a normal case, no new material, and an unavailable source. Then use the product's supported controls to prepare and review the exact schedule. Confirm its time zone, sources, destination, and permissions.

The complete walkthrough shows how to build that routine around a weekly project update. It includes two sets of practice notes, expected outputs, a reusable method, and the proposed schedule. You can try the work before connecting anything.

Running in the background is not the same as scheduling

A running task is doing work now. A schedule starts work later or repeatedly. A goal keeps a finish line in view. These functions can work together, but none implies the others.

The execution location also matters. ChatGPT cloud work can continue independently of your computer; local scheduled work needs the required computer, app, and files available. OpenAI's scheduled-task guide explains the distinction. For Claude, check the current Cowork getting-started guidance for the execution mode you use. Microsoft documents scheduling and task management in its Cowork overview.

Judge total effort

Compare total gathering, review, correction, and completion time with your old approach. Include usage charges. A fast first draft followed by an hour of repair may be a loss.

If a scheduled task produces noise, narrow its sources or reporting condition. If it repeatedly misses the same requirement, repair the method before increasing the frequency. If an action has an uncertain result, inspect the destination before retrying so you do not create duplicates. Pause the workflow when the sources or responsibilities change enough that the old rules no longer fit.

A sensible next step: select one recurring draft you already know how to check. Improve that workflow until the next run needs less explanation. Then decide whether scheduling would actually help.

A team update sounds simple until you have to reconstruct the week from scattered notes, remember last week's open questions, and work out what actually needs a decision. This walkthrough brings the earlier concepts together around that job.

Illustrative example: Project A and all notes below are fictional. The sample answers show what to check; they are not records of a client result or a live automation. You can practise both weeks in ordinary chat. Nothing needs to be connected or installed.

First use: give it the work and a finish line

Paste this complete request:

PRACTICE: prepare Project A's weekly update for its team lead.
Use only the notes below. Produce a draft of no more than 150 words with
progress, blockers, decisions needed, and next actions. Cite each factual
bullet with its note ID, such as [A1]. Do not send anything or change files.

Done means the reader can see what changed and what needs attention.
Keep proposals separate from approvals. Do not invent owners or dates.

Week 1 notes:
[A1] The team approved a pilot with 10 participants. The start date is undecided.
[A2] The demo owner completed the draft invitation and needs the team lead's
approval before invitations can go out.
[A3] The demo owner proposed starting next Tuesday. No one approved that date.
[A4] The demo coordinator will check room availability by Monday.

An acceptable draft could say:

PRACTICE: Project A, week 1

Progress: The pilot is approved for 10 participants. The draft invitation is complete. [A1, A2]

Blockers: Invitations await the team lead's approval. [A2]

Decisions needed: Approve the invitation and choose a start date. Next Tuesday is a proposal. [A1, A2, A3]

Next action: The demo coordinator will check room availability by Monday. [A4]

Those little source labels make review easier: you can trace a sentence back to a note. They are useful only if the cited note actually supports the sentence. A citation is a receipt to inspect, not a decorative stamp.

Correct the method once

You want to see the decisions before the good-news paragraph. Tell the AI:

Put decisions needed first, then blockers, progress, and next actions.
Keep the source IDs beside the facts. Preserve the distinction between a
proposed date and an approved date. Revise the update using that order.
Then give me a short reusable method for future project updates.

The revised update should lead with the invitation approval and start-date decision. Its facts should stay the same. A compact reusable method is enough:

Weekly update method

Read the current notes and the last saved state. Write no more than 150 words in this order: decisions needed, blockers, progress, next actions. Cite the current source for each factual bullet. Separate proposals from approvals. Compare with the prior state so resolved issues do not remain open. Report missing sources. Return a draft for review.

For now, save or copy that method. It can later become a skill through your app's supported setup. You can test whether the instructions help before installing anything.

Save the state separately from the method

Ask for a short handoff using the session routine. Compare it with this example and save a correct version for the second use:

PRACTICE: Project A, end of week 1. Pilot approved for 10 participants. Invitation drafted; approval pending. Start date undecided; next Tuesday was only proposed. Demo coordinator to check room availability by Monday. Use the Weekly update method, with decisions first. Next: read week 2 notes and update these statuses. Nothing sent.

The method explains how to do the job. The handoff says where this particular job stands. Keeping them separate lets you reuse the method for Project B without accidentally inviting Project A's participants. That would be an adventurous interpretation of teamwork.

Second use: recover, compare, and apply the feedback

Open a new chat. Paste the method and the saved handoff, followed by this request:

Continue this fictional practice using the Weekly update method and week 1
handoff above. Read the week 2 notes below. Produce the next update, showing
what changed. Then list any check that failed or information still missing.
The new notes update the old state where they explicitly resolve an item.
Do not carry a resolved blocker forward. Do not send anything or change files.

Week 2 notes:
[B1] The team lead approved the invitation on Monday.
[B2] The demo coordinator confirmed a room is available next Thursday.
[B3] The team lead chose next Thursday as the pilot start date, replacing the
unapproved Tuesday proposal. The approved group remains 10 participants.
[B4] Invitation delivery is still pending. The notes give no owner or send date.

A passing result could look like this:

PRACTICE: Project A, week 2

Decisions needed: Assign who will send invitations and when. Neither is specified. [B4]

Blockers: Invitation delivery is pending; the earlier invitation-approval blocker is resolved. [B1, B4]

Progress: The invitation is approved. A room is available, and the team lead chose next Thursday for the 10-person pilot. Thursday replaces the earlier Tuesday proposal. [B1, B2, B3]

Next action: Assign invitation delivery, then confirm completion. The source does not establish that invitations have been sent. [B4]

Inspect two different things. Did the facts update correctly? And did the new task use the decisions-first preference? A correct answer to both supports this particular reuse test. It does not establish that every future task will remember the rule.

Before closing, replace the practice handoff with the week 2 state: invitation approved, Thursday chosen, room available, invitation delivery pending with owner and date unknown. Keep the old handoff as history if useful, but identify the week 2 note as current.

Give each check a job

You now have a useful chain: read → compare → draft → check → revise → save the handoff. One AI task can carry out those stages. Named skills become useful when their instructions need to be reused or maintained separately.

A stress test can raise a question such as “What if invitations are delayed?” It should not invent evidence that they already are. You still decide the owner and deadline; the AI makes the unresolved work easier to see.

Try two variations before trusting the routine. For each, open a separate new chat and paste only the reusable method, the original week 1 handoff printed above, and that variation's notes. Say, “Use only these supplied practice inputs.” This keeps the answer from a previous attempt out of the test.

In the first variation, supply B2-B4 but omit B1. The result should leave invitation approval unconfirmed. In the second, supply no week 2 notes. It should report missing input instead of announcing that nothing changed. These small evals test the errors most likely to mislead the reader.

Connect the inputs when copying becomes the chore

After the manual routine works, you may want the AI to read the current notes from an approved folder or connected app. Keep the same method and checks. Change how the inputs arrive.

Use the connections chapter to check access to one named source first. In real work, ask it to show the file name and date it found. Open that source once to confirm it is the right one. Replace the practice IDs with useful file or source links in the update.

A connector supplies access; a skill supplies the method. A plugin may package these together. None chooses the correct source or checks the answer merely by being installed. If attachment is still easy, keep attaching the file.

Let a schedule start the tested routine

When the connected version is useful across normal runs, prepare a schedule using the automation chapter and your product's official controls. A proposed setup for this example is:

This table is a plan. Entering it in a chat does not activate a schedule. Review the actual saved configuration and first run through the app, including its failure behaviour. Apply any usage limit appropriate to the account.

You have now moved from preparing one update to specifying a repeatable workflow. The possible gain is less gathering, rebriefing, and formatting. Measure that against the time spent checking and repairing the result over normal uses. If the routine adds more work than it removes, simplify it before giving it a Friday appointment.

Transfer the pattern to a different job

For content work, the inputs might be an approved article and editorial guidance; the output might be a newsletter and social drafts. Replace the project-status checks with claim fidelity, audience fit, and format checks. Save a correction such as “use the original article's figures; do not add a stronger performance claim.”

For a spreadsheet update, keep the formulas and source data explicit. If three fictional orders total $40, $60, and $100, the expected total is $200. Check that known case before scaling up, and test how the workflow treats a blank value. A blank cell should not silently become a zero unless that is your agreed rule.

The repeatable structure transfers. The definition of a good result must fit the work.

Use the route for your actual product and account. If a label is missing, check the current official guide or ask your administrator. You can still practise briefing and review in chat while access is resolved.

Claude Cowork

Open Cowork in the Claude desktop app and choose a working location for the task. Start with a small approved folder or a suitable Project. Anthropic's four-minute setup tutorial shows the current flow, including guided customization. You can postpone optional connections until a task needs them.

Keep the distinction between the files and the project that uses them. A Project helps carry context between sessions; confirm that the next session finds the right source and current record. Use Claude's current Cowork help for supported devices, execution modes, approvals, and account requirements.

Microsoft Copilot Cowork

Use your approved Microsoft account, open Copilot, and select Cowork where available. Attach the relevant files or choose supported cloud sources. Work or school access depends on your organization's setup, licensing, and billing configuration. Start with Microsoft's setup instructions.

For reusable instructions, the documented Customize area has Plugins and Skills. Use the customization guide, and test changed skills in a new conversation. Your actual account determines what is available. A local folder recipe written for Claude should not be treated as proof of Microsoft permissions or persistent context.

ChatGPT Work

Switch from Chat to Work when you want a larger deliverable. Provide the source material and the result you need. On supported desktop setups, choose local work for resources on your computer or cloud work for accessible hosted sources. The Work introduction, with video, shows the starting experience.

Use Projects for related work and the Plugins area for supported extensions. On the web, a project uses uploads and connected sources rather than automatically reading your computer. If you use Codex for everyday work, you can continue there; OpenAI describes overlapping core capabilities with different presentation in its Chat, Work, and Codex comparison.

If the app disagrees with this guide

Do not keep clicking around to match an old screenshot. Tell the AI the exact product, device, and visible labels, and ask it to use current official instructions. Have it distinguish a missing feature from a permission issue. Your organization decides which tools and information you may use; a tutorial cannot grant access.

For a confusing failure, use:

Stop and help me diagnose this. What did you attempt, what actually happened,
and what evidence do you have? Separate missing information, missing permission,
tool failure, and an unclear instruction. Suggest the smallest safe next step.
Do not retry an external action or change access settings.

Files, emails, and websites can contain instructions that were not written by you. Treat those as source content, not permission to change the job. If a document tells the AI to ignore your request or send information somewhere else, stop that action and ask for a plain explanation. This is one reason access limits and review belong in the workflow.

You do not have to become the technical support team. A useful escalation contains the intended task, the failed step, the exact error, and what remains unfinished. Leave passwords and private information out of anything you share for help.

Find the problem below. Use the short prompt now, or follow its link for the explanation and complete example. For an error or unexpected change, use troubleshooting.

Choose your next step

These are stages of practice, not course prerequisites. Use the next stage when your work needs it. You can get plenty of value without becoming the household plugin collector.

You can stay at any stage that helps. Progress means useful work takes less effort and fewer corrections.

Choose the resource for the question in front of you. You do not need to finish a course before trying the first task. Official learning sites may ask you to sign in; the written examples in this guide stand on their own.

A short learning path

Use one app's instructions at a time. Learning three sets of buttons in one sitting is optional extra homework.

Watch a relevant introductory video with one question in mind: “What do I need to do to give it my next job?” Pause and try that step. The written examples here remain usable on their own. Linked video pages were checked; the videos have not been reviewed end to end for this guide.

Organize recurring work

• ChatGPT Projects: understand shared sources and the difference between local and cloud projects.
• Claude Cowork Projects: understand how folders, instructions, and project memory fit together.
• ChatGPT personalization: distinguish saved memories from instructions that should govern the work.

Reuse methods and add tools

• OpenAI Skills and Plugins, with a video: learn what each contains and when to use it.
• Claude skills explained: learn how reusable expertise fits into Claude.
• Customize Microsoft Copilot Cowork: create or import skills and review plugins.
• ChatGPT Work access and execution: understand which files, accounts, and tools a task can use.

Continue longer work or repeat a task

• OpenAI long-running work: define a finish line and use Goal mode on supported surfaces.
• OpenAI scheduled tasks: understand repeat runs, local requirements, and testing before scheduling.
• Microsoft Copilot Cowork overview: find current guidance on scheduled prompts and supported tasks.

Learn at your own pace

• Claude Academy: look for Claude 101, Introduction to Claude Cowork, and task-specific tutorials. Choose one topic that helps with work you already have.
• Sidekick Starter Kit: an optional guided workspace for beginning with Claude Cowork. If you already have a working client setup, use that setup rather than creating a duplicate.

For your next session, bring one task you understand well enough to check. State the result, provide the sources, and use the first correction to make the next attempt better.