Montaj
Enhesa

Workshop reference / optional follow-on

Understand the parts.
Build a method you can reuse.

Six concepts, practical examples and steps for Claude, Codex and n8n. Pick the guide you need, then return to your workshop.

Examples are fictional or generic. Use approved real evidence in your own workspace. Installation and live scheduling are follow-on activities, outside the timed exercise.

01

Chat: give the work a clear starting point

Chat is the conversation where you ask for work, supply context and review the response. The application determines whether the AI can also read files, use tools or take actions.

When it helps

Use it to explore an idea, interview a colleague, draft an asset or work through a decision. You can clarify the job as you go.

Marketing example

Ask for a draft launch email using the supplied product brief and tone-of-voice examples. Keep the product evidence separate from suggestions for copy.

How to use it
  1. State the job and the audience. Ask for one specific output, such as a 150-word email and a claims table.
  2. Attach the relevant brief, approved examples and context. Ask which files the AI can actually access. Another conversation's context isn't automatically available.
  3. Set limits: approved claims, tone, length, required evidence and anything that needs a human decision.
  4. Read the draft against the originals. Explain what needs changing and why, then ask for a revision.
  5. Save the reviewed output and useful method as Markdown files. Reopen the saved files to check them.

Claude

Start a chat in your approved Claude workspace. For a Project, explicitly add the reviewed context to Project knowledge; generating it in a conversation isn't the same as adding it. In an ordinary fresh chat, attach the files again.

Codex

Open a task in your approved project or working folder. Name the evidence files and ask Codex to read them before drafting. Ask it to save the result to a named file, then open that file yourself. Give new tasks the relevant file locations.

Using only the context and evidence I supply, draft one launch email of up to 150 words for [audience]. First list the files you can access and ask about any essential gaps. Follow [tone examples]. Add a claims table with the source filename and section for each factual claim. Separate suggestions from supported facts. Don't send or publish anything. Return a draft for my review.

Check the result

Can you trace each factual claim to a supplied source? Does the draft address the intended audience? A polished answer without the evidence is still a draft.

Back to concepts ↑
02

Deterministic tasks: let rules do the work

A deterministic task follows explicit rules. With the same input and rules, the intended result stays the same. Copying a field, calculating an agreed rate or looking up an owner doesn't need a language model.

When it helps

Use automation when you can write down the exact condition and action. AI can help write the automation, but it doesn't need to make the decision at runtime. External data and service failures still need handling.

Marketing example

A fictional campaign brief has a product code, audience, deadline and brief ID. Route it to the owner listed against that product code. If fields or the owner are missing, return a missing-information result.

How to use it

Build a brief checker in n8n

Start with test records and a draft output. Replace the input and destination with approved connections only after the checks pass.

  1. Create a workflow with a Manual Trigger. Add Edit Fields (Set) and enter a fictional brief: briefId = TEST-001, productCode = HALDEN, audience = compliance managers, deadline = 2026-10-01. Add a test owner mapping: HALDEN → Campaign owner A.
  2. Add an If node. Require a non-empty brief ID, product code and audience, plus a valid deadline in your agreed format. Define the date check explicitly; a non-empty string alone isn't a valid date.
  3. On the false branch, use Edit Fields to return status = needs_information and the missing or invalid fields. End that branch without creating a task.
  4. On the true branch, look up productCode in the owner mapping. If the code has no owner, return status = needs_owner. Never guess an owner.
  5. For a known owner, return a draft routing record containing briefId, owner, audience and deadline. Test it before adding an approved Monday or other destination node.
  6. When adding a live destination later, check briefId against existing records before creating anything. Repeated delivery of the same brief mustn't create duplicate tasks. Store credentials in n8n's credential controls.

AI could assess whether the brief is clear or suggest campaign angles after validation. Keep the fixed field checks and owner lookup as rules.

Help me design an n8n brief-routing workflow using fictional records. Use fixed rules for required fields, date validation and product-code-to-owner lookup. Include branches for missing fields, invalid dates, unknown owners and duplicate brief IDs. Begin with Manual Trigger and a draft output, with no live writes. Show the nodes and exact conditions. Identify any step that truly needs AI judgement; don't add an AI node for simple field movement.

Check the result

Test a complete brief, one with a missing audience, an invalid deadline, an unknown product code and a repeated brief ID. Record the expected and actual result for each. Missing information must never reach the create-task branch.

Back to concepts ↑
03

Skills: keep the method that worked

A skill is a reusable set of instructions for a particular job. It can include examples, reference files and scripts. It tells the AI how to approach the work, but each result still needs checking.

When it helps

Use a skill when you repeatedly do a similar job and can describe a good result. Keep current campaign facts in the supplied evidence, so the skill can work on another campaign.

Marketing example

A briefing skill interviews a campaign manager, checks for missing information and produces a consistent brief. A launch skill uses that approved brief to draft an email and claims table.

How to use it

Download the optional brain-building skill to use a ready-made method for interviews and source-backed knowledge. Setup instructions and the blank starter structure. Downloading is not installation; this is follow-on work.

Route 1: complete the task first (preferred)

  1. Do the whole task with AI and your real review process. Keep the original inputs and the final version.
  2. Correct mistakes and awkward steps. Note what changed, why it changed and which decisions needed a person.
  3. Ask AI to extract the working method: inputs, sequence, rules, output, checks and stopping points. Remove one-off campaign facts.
  4. Turn that method into a draft skill. Test it on a different input in a fresh task with the relevant context supplied.

Route 2: start from an existing SOP

  1. Supply the SOP, a good input/output pair and the reviewer's criteria.
  2. Ask AI to identify missing decisions or contradictory steps before drafting the skill.
  3. Walk through the draft on one example. Correct it, then test another example. An SOP is a starting point, not evidence that the skill works.
Turn the reviewed process and corrections from this task into an instruction-only skill called campaign-brief-check. If I supplied an SOP instead, first identify gaps and ask the necessary questions. Include when to use it, required evidence, steps, output format, missing-information handling, human review and a second-input test. Separate reusable rules from campaign facts. Create SKILL.md with name and description metadata; list any supporting files. Return a draft for review. Don't install, enable or share it yet.

Claude

  1. Review the skill folder and its instructions. Package the folder as a ZIP with the skill file and any referenced examples inside it.
  2. Open Customize → Skills, use Add to upload the package and enable it. Your organisation must allow skills and the required code execution capability.
  3. Start a fresh task, name the skill and attach new evidence. Check that it was used and compare its output against your criteria. If skills aren't enabled, attach the reviewed method and ask Claude to follow it explicitly.

Codex

  1. In Codex, ask $skill-creator to package your reviewed method as an instruction-only skill.
  2. For a project skill, use .agents/skills/campaign-brief-check/SKILL.md within your approved project. Keep name and description in its metadata. Review the saved file.
  3. Start a fresh task and select or explicitly name the skill, supplying the new evidence. If it doesn't appear, restart Codex and check the folder. Verify the output, rather than relying on automatic selection.

Keep a reviewed copy of the skill and its examples in approved team storage. A portable instruction file doesn't make tool connections or permissions portable.

Check the result

Does a second brief work without importing facts from the first? Does a deliberately incomplete brief trigger useful questions? Keep the previous skill version until the replacement passes those checks.

Back to concepts ↑
04

Scheduled tasks: decide when the method runs

A scheduled task runs a saved job at an agreed time. A skill defines how to do the job; a schedule defines when to start it. A scheduled task can use a skill, but timing alone doesn't make its output reliable.

When it helps

Use schedules for recurring work with known sources and a clear reviewer. They remove the need to remember the prompt, while giving the team a predictable review point.

Marketing example

Fictional examples: a weekday change summary at 17:00, a Monday priority list at 09:00, and a Friday summary at 16:00. Choose the team's timezone explicitly.

How to use it

End of day

What changed since the last successful run? Show changed briefs, blockers and source links. Say when nothing changed.

Weekly to-do

List due and overdue work by recorded owner. Flag missing owners and dependencies. Don't invent commitments.

End of week

Compare planned work with completed work. Separate observed results from possible explanations and carry open questions forward.

Prepare once, before activation

  1. Choose one job and a reviewed method. Define accessible sources, reporting period, timezone, output destination and reviewer.
  2. Run the job manually with test evidence. Check missing sources, duplicate records and a period with no changes. Keep incomplete data visible.
  3. Agree what can happen automatically. Start with a private draft. Name who handles failures and who can pause the task.
  4. After setup, inspect the first actual scheduled run: its time, evidence access, output and destination. Don't treat a saved schedule as a successful run.
Help me set up an end-of-day change summary using the reviewed method [skill or file]. First confirm the accessible sources, destination, reviewer and timezone. Proposed cadence: weekdays at 17:00 in Europe/London. Report changes since the last successful run; on the first run, state the baseline period. Link each change to evidence, flag unavailable sources, and say if there are no changes. Save a private draft for [reviewer]; don't send it. Run a manual test first. Show the final configuration for my confirmation before activating it. Explain how I inspect a run and pause it.

Claude Cowork

  1. Open Scheduled → New task → Create with Claude, or use the manual setup option. Supply the tested prompt and select the cadence.
  2. Check the job and timing before confirming Schedule. Use Scheduled to inspect runs, run on demand, edit or pause.
  3. For cloud runs, use account files and enabled connectors. Local-file requirements need a compatible local setup: check the execution mode shown in your account before activation.

Current guidance describes remote runs with the desktop app closed, but also a local-file exception. Don't assume cloud tasks can reach a folder on your laptop. Cowork access is managed by your organisation.

Codex

  1. Open the relevant Codex task and ask it to schedule the tested job. Name the skill or method and required project or files.
  2. Review the proposed cadence, execution location and instructions. Confirm the schedule, then inspect it in Scheduled or Automations, depending on your app version.
  3. Check the first run and its output. Use the task's management controls to pause it when the job or its sources change.

A job using a local project needs the computer on, the app running and that folder available. Cloud tasks need accessible uploaded or connected evidence. Availability depends on your workspace.

n8n

  1. Open the workflow you tested manually. Add Schedule Trigger and set the weekday or weekly rule, hour and minute.
  2. Set the workflow timezone explicitly, for example Europe/London. Keep fixed extraction and calculations in normal nodes; add AI only where interpretation is needed.
  3. Connect the approved draft destination. Save and publish the workflow, then inspect its first scheduled execution. Unpublish or deactivate it to stop future runs.

Use n8n Cloud or a maintained server that stays available. A workflow running on a switched-off laptop can't execute. Configure a failure notification to the named workflow owner.

If your account lacks scheduling, keep the tested prompt and method for manual use. Activate later in an approved environment. These guides don't create a schedule from this website.

Check the result

Can the task read the intended sources at runtime? Does it use the correct timezone and period? Can the reviewer find its output and pause it? Check one failed or missing-input run as well as a successful run.

Back to concepts ↑
05

Loops: improve with evidence

A loop repeats work, checks what happened and decides whether to continue. It needs a goal, a check and a stopping condition. Repeating a prompt without those controls can repeat the same mistake.

When it helps

Use a loop to refine a draft, monitor a changing source or improve a saved process from reviewed feedback. These are different uses of repetition.

Marketing example

A launch email fails a claims check. The AI removes unsupported wording, tests another draft and proposes an update to the briefing skill so the next campaign asks for evidence earlier.

How to use it
ProduceCreate a draft
CheckCompare with evidence
CorrectFix a specific failure
RetestTry another input
ApproveHuman decides
UpdateSave method + log

Repeat only while useful. Stop after 2 correction attempts, or earlier for missing evidence. Escalate to the reviewer.

Download loop diagram (PNG)

Choose the loop you mean

  1. Improve one output: compare it with explicit criteria, correct failures and stop when it passes or reaches the attempt limit.
  2. Repeat a check: inspect an accessible source at a set cadence. Define what counts as a change and when monitoring ends. Use a schedule if it needs to continue between sessions.
  3. Retain an improvement: propose a change to the saved skill or context, get human approval, test it on a different input and log the accepted change. Make that version available to future runs.

The model hasn't automatically retrained itself. You've improved the instructions, examples or knowledge it receives. A higher score from the same model isn't enough to prove the change works.

Review this draft against the supplied evidence and these criteria: every factual claim has a source; no unsupported capabilities; the output meets the requested format. List specific failures, then revise. Allow at most 2 correction attempts. Stop and ask me if evidence is missing, criteria conflict or the same failure persists. Show unresolved issues honestly. After I review the result, propose a minimal update to method.md, with a reason and source. Don't apply it without my approval. Test the proposed method on a different input and recheck the original before proposing adoption. Keep the previous version and add a dated change-log entry for accepted updates.

Check the result

Does the correction fix a verified failure? Does the second input still work, and did the original case regress? Record the evidence, the reviewer and the accepted version. If checks fail, keep the earlier method.

Back to concepts ↑
06

AI harness: the environment that runs the work

An AI harness is the software around the model. It supplies instructions and context, makes tools available, manages execution and permissions, and lets you inspect the result. The model is one part of that system.

When it helps

Use this idea when deciding where a workflow should run. Ask what the AI can access, what it can change, how it checks success and who sees a failure.

Marketing example

The Workshop OS gives you a brief and prompts. Claude or Codex reads your approved evidence and does the work. An optional n8n workflow can gather records or trigger a job; a person reviews the result.

How to use it
Your goal + approved evidence

AI application / harness

Instructions + skills
Context + files
Model
Interpret · plan · draft
Tools + permissions
Execution + checks
Reviewed output → approved method / knowledge update

The board guides you. Claude or Codex runs the task. n8n can supply inputs or trigger work.

Download harness diagram (PNG)

Map your own setup

  1. Write down the job and output. Choose the application that can work with your approved evidence.
  2. List the context and skill it needs. Keep a portable reviewed copy so another application can use the same underlying method.
  3. List the tools and allowed actions. A connector provides access; it doesn't define a workflow or guarantee that the data is correct.
  4. Name the fixed checks, AI decisions, reviewer and failure route. Add a schedule only if the task should run without a manual start.
  5. Test a small example and a missing-input case. Inspect tool results and the saved output. Confirm which files will actually be supplied to the next run.
Map the environment needed for this workflow: [job]. List the goal, supplied context, reusable skill, fixed-rule steps, AI judgement, tools, permitted actions, execution location, output and human checks. Mark each component available, missing or unverified based on what you can actually access. Propose a small manual test and one failure test. Don't connect tools, change permissions or create schedules. Show what could be reused if we moved to a different AI application.

Check the result

Can someone explain which part does each job? Are unavailable tools marked honestly? Does the saved evidence and method remain usable outside the current chat? You don't need to build a custom harness for this workshop.

Back to concepts ↑

Platform guidance checked on 10 September 2026. Menus and availability can vary by account; use the linked official instructions if your screen differs.

Return to your module