01—LLM / PRACTICE SYSTEM

Start with the model · then make one checked attempt

Understand LLMs before you ask them to work.

Learn what a language model can and cannot establish, write one bounded request, inspect the answer, and repeat the method on a new task. Codex, tools, Agents, and Skills come after this foundation.

You leave with a bounded task card · a checked result record · one transfer attempt Targets, not measured outcomes.

02

Start here · one useful result today

What do you want the model to help you do?

Finish the LLM Foundation Core first. Then choose one real purpose. The point is not a magic prompt; it is a small result you can inspect, revise, and carry to the next task.

Your first useful result

Choose one thing you want help with now.

Choose a purpose, add only the details that matter, then copy a prompt you can use in any chat model. No account, files, or setup required.

Optional prompt cards · five minutes

Start with one small conversation.

Copy one original, text-only card. The language card needs no editing; the research card has two brackets. Inspect the response yourself, and keep the claim small: one attempt is not fluency, research, or a finished answer.

01 / LANGUAGE PRACTICEtext only · no tool authority

Complete one short typed Spanish study-group time check.

This text-only card uses fictional study details, waits for your typed attempt, and limits help to one meaning-blocking error.

  1. Copy the card exactly as written. It already sets a fictional typed Spanish study-group time check.
  2. Paste it into any text chat. Do not add a real name, school, calendar, account, or payment detail.
  3. Type the first answer yourself. A rough attempt is the point; do not ask for the answer first.
Show the prompt
Run one four-minute typed Spanish study-group time check with exactly four learner turns. You are a fictional classmate and write first. Use only short present-tense questions. I will type one answer after each question.

Fictional study card: Ana; a study group; Tuesday or Thursday; 6:00 or 6:30; library or online; bring one question. I may use the card and look up at most three single words. Do not request or accept a real name, school, calendar, account, address, contact, or payment detail.

Before turn one, show this fixed rubric: four learner turns; purpose and study group communicated; day and time clarified; place or online option communicated; Spanish understandable enough to continue. Do not teach, translate, or show a model answer before I reply. Preserve my first attempt and record lookups. Correct only the first meaning-blocking error: name the error type, then give a partial cue, then one worked fragment only if I still cannot continue. Ask me to correct it. Keep both attempts and do not call one successful exchange fluency, spoken conversation, or listening/pronunciation evidence.

Candidate text practice only: one typed session cannot show spoken conversation, pronunciation, listening, fluency, accuracy, retention, or independent performance.

02 / RESEARCH PREPtext only · no browsing assumed

Prepare a source check, not a verdict.

Turn one narrow question and the material you supplied into a small ledger of claims, gaps, and the next question.

  1. Copy the card, then replace only its two brackets.
  2. Supply only material you may share. Leave personal, private, or high-stakes material out.
  3. Treat its table as preparation. Open and match sources yourself before relying on a claim.
Show the prompt
I have five minutes to prepare a research check, not a final answer.

Question: [one narrow question].
Material I supplied: [URLs, titles, excerpts, or "none"].

First, restate the question and name what evidence would be needed. Then make a three-row table with: possible claim, supplied source or "missing", and what would need checking. Do not invent citations, state that you opened a source you cannot access, or give a recommendation. Separate fact, report, and inference. If the material is missing, contradictory, personal, or high stakes, stop and tell me the smallest safe next step.

End with: sources actually supplied, unknowns, and one question I should answer before continuing.

It cannot prove a source exists, is current, or supports a claim. A generated table is not evidence on its own.

03 / SKILL PRACTICEfictional plan · no tool authority

Practise one small planning skill before asking for help.

Make a short fictional park-visit plan yourself. The model must wait, give one small hint, and then test the same skill under one changed limit.

  1. Copy the card into any text chat. It contains a fictional situation and needs no account, file, tool, or personal detail.
  2. Write the first plan yourself within four minutes. Do not ask for a model plan or a polished replacement first.
  3. Accept one short hint, correct your own plan, then try the changed time limit without help.
Show the prompt
Help me practise making a small plan. Do not make the plan first.

Practice task: plan a fictional 45-minute visit to a city park for one adult. Include a water bottle, a weather check, and one return-time reminder. This is not a real booking, travel decision, or weather forecast.

Before I write, show this fixed check: 3–5 steps; all three constraints appear; no unsupported local facts; and a person could follow the plan. Give me four minutes to write it. Do not show a model plan, expand it, or grade it before I respond.

After my first attempt, name one consequential omission only. Ask one question or give a hint of no more than 12 words, then wait for my correction. Preserve both attempts. Then change only the visit length from 45 minutes to 20 minutes and ask for one new plan without help, using the same check.

End with exactly one status: practised, demonstrated_on_this_task, transferred_to_time_limit_variation, or not_run. One session does not establish planning ability, judgement, safety, or independent performance.

Candidate practice only: a short fictional plan cannot prove planning ability, judgement, transfer, retention, safety, or independent performance.

Optional application routes · open after the foundation

These routes are useful when you already know what you want to practise. They do not replace the LLM Foundation Core.

Open every problem route
03

A five-minute LLM prompt practice

See why a clear prompt needs a human check.

Use any chat model. You will give it one small rewriting task, then check whether it preserved the facts instead of making helpful-sounding details up.

Your first prompt practice

Ask the model to improve a message without inventing facts.

5 min

This is a small demonstration of why prompts matter. The model can make a message sound better, but it may also add details you never supplied. You will give one clear instruction, then check whether it followed it.

01 · READ THE ORIGINAL
The workshop changed. It starts Friday at 10. Bring the draft. Tell me if you cannot come.
02 · COPY THIS PROMPT INTO ANY CHAT MODEL
Please rewrite the message below so it is clear and friendly.

Keep every fact exactly the same. Do not add a date, place, reason, contact detail, or any other information that is not in the original.

Original message:
"The workshop changed. It starts Friday at 10. Bring the draft. Tell me if you cannot come."

Return only the rewritten message.
03 · READ THE ANSWER AND ASK THREE QUESTIONS
  1. Does it still say Friday at 10?
  2. Does it still ask people to bring the draft and reply if they cannot come?
  3. Did it avoid adding a date, place, reason, or contact detail?

If all three answers are yes, the model followed this small instruction. If not, tell it exactly which fact it changed or invented, then try again.

ONE ACCEPTABLE RESULT
“The workshop starts Friday at 10. Please bring your draft. If you cannot attend, please reply.”

The wording can differ. What matters is that the facts and the requested action stay the same.

WHY THIS MATTERS

An LLM predicts useful-sounding text; it does not automatically know which missing details must stay unknown. A clear prompt and a quick check help you catch that difference.

04

The basic map

Put each LLM concept in its own lane.

Before you choose a product or copy a prompt, separate generation, framing, action, coordination, and checking. The same map works across chat models and agent tools.

LLM

Five layers, five different questions.

A fluent answer belongs to the generation layer. It does not, by itself, prove that a source was opened, a file changed, or a task was completed.

Read the complete LLM fundamentals guide
  1. 01
    GenerateLLM

    Predicts a useful continuation from the context it receives. Fluency is not verification.

  2. 02
    FrameContext + prompt

    States the goal, relevant material, limits, and the shape of the answer you need.

  3. 03
    ExtendProduct + tools + Skills

    May add files, browsing, commands, or reusable methods. Access and side effects are runtime facts.

  4. 04
    CoordinateAgent + workflow

    Organises multiple observations and actions with checkpoints, retries, and stop conditions.

  5. 05
    CheckEvidence + human judgment

    Compares the result with a source, diff, test, log, or acceptance rule before making a claim.

Do not infer a lower layer from a higher one: a model proposal is not a tool action, a tool action is not a verified result, and one checked result is not mastery.

06

Six terms, one checked result.

These terms describe different parts of one request. Keep them separate before you decide what the model has actually established.

Open the complete English visual
  1. 01Token

    A unit of text the model processes. Token counts vary by tokenizer; a token is not a fact or a permission.

  2. 02Context

    The material available in this turn, such as your prompt, supplied text, or returned tool data. Missing material stays unknown.

  3. 03Context window

    The amount of material a model can fit into one turn. The exact limit depends on the model and product.

  4. 04Prompt

    The goal, context, constraints, and requested answer shape. A prompt frames work; it does not grant access.

  5. 05Response

    Text proposed by the model for you to inspect. Fluency can make a mistake sound certain.

  6. 06Tool / Agent

    A product may add reading, action, or coordination. Runtime permission and evidence still decide what happened.

Response ≠ action ≠ verified result. Compare the result with a source, diff, test, log, or acceptance rule before claiming completion.

08

Follow the reliable LLM work loop.

Choose a node to see the next question. The static list below keeps the same route available when the interaction is unavailable.

SELECTED STEP

Understand

Separate a model's proposed text from what the available evidence can establish.

Next questionWhat result can I check?

Open this part of the route
Read the six steps as a text sequence

Use this list without the interactive map. Each step names an action and the evidence boundary that follows it.

  1. UnderstandSeparate a model's proposed text from what the available evidence can establish.Open this part of the route
  2. FrameState the goal, relevant context, allowed help, limits, check, and stop condition.Open this part of the route
  3. ActAllow the smallest reversible action and pause before an external effect.Open this part of the route
  4. InspectCompare the output or diff with a source, test, log, or acceptance rule.Open this part of the route
  5. RepairName one mismatch, keep the failed receipt, and change one condition before retrying.Open this part of the route
  6. TransferRepeat the method on an unseen task; do not turn one successful attempt into mastery.Open this part of the route
Six-step reliable LLM work loop: understand, frame, act, inspect, repair, and transfer
Open the full project-authored board for a printable view. The list and explanation above carry the same meaning in text.

A map is a route, not proof of learning. Keep the attempt, the check, the failure, and the remaining unknowns.

09

Let the evidence set the decision.

Follow one question from source to observation. The map ends at a deliberate stop when the next proof is missing.

SELECTED STEP

Question

Name the decision before you search. A broad topic is not yet a checkable question.

Next checkWhat decision would this evidence change?

Open this part of the route
Read the evidence path as text

Use this sequence without the interactive map. Each step keeps the claim within the record.

  1. QuestionName the decision before you search. A broad topic is not yet a checkable question.Open this part of the route
  2. SourceName the owner, location, date, version, and the source's boundary.Open this part of the route
  3. ObserveRead the page, diff, test, log, or response. Do not infer an event you did not observe.Open this part of the route
  4. DecideKeep the claim supported when the check matches; otherwise mark it candidate or unknown.Open this part of the route
  5. StopWhen the next proof is missing, stop and record the smallest safe next check.Open this part of the route
Evidence to decision and stop teaching board
Open the project-authored board for a printable view. The interactive map and text sequence carry the same meaning.

A decision map is a reasoning aid, not proof that a source is correct, a tool ran, or a learner mastered the method.

11

See the whole Playbook before you choose a track.

One map answers the first practical question: what should I do now, and what comes after the first checked result?

Read the four stages as text

Use this ordered list without the interactive map. Each stage names the work and the evidence boundary that follows it.

  1. 01Foundation Core

    Understand the model, make one request, recognize visible failures, repair, and try a new task.

  2. 02First bounded task

    Name the result, context, allowed help, limits, check, and stop condition.

  3. 03Evidence loop

    Compare what changed with a source, test, log, or acceptance rule; stop when proof is missing.

  4. 04Optional tracks

    Choose Codex, tools, Skills, Agents, research, engineering, or team practice only when the next layer is useful.

The map shows order, not mastery. Keep the artifact, evidence, limit, and next question.

Playbook learning journey from the Foundation Core to a first bounded task, an evidence loop, and optional tracks
Open the project-authored journey board for a printable view. The ordered list is the text explanation.
INDEX

Project index

Know where each claim lives.

This is a human-readable map of the repository: what each layer stores, where to begin, and which source controls its status.

00

What this repository contains

Start with the lesson, then use the exercises and reusable methods when you are ready to practise.

Open the detailed map

The shortcuts above are the compact view. Open this panel for the canonical reading map, field research, and maintenance rules.

01

Repository map

Read the layer that matches the work. The public page is a guide; the files below are the source of truth.

02

Read in your language

Choose the language you read most naturally. Each route stays in that language as you move through the book.

  1. ENEnglish
  2. ZH简体中文
  3. ESEspañol
  4. DEDeutsch
  5. JA日本語
  6. KO한국어
  7. 繁中繁體中文
  8. FRFrançais

Use the language menu at the top of the page whenever you want to switch.

04

Real problems, with the boundary attached.

The research index turns public Codex issues and forum reports into symptoms, versions, safe checks, and teaching links. It does not claim an official root cause or local reproduction.

Read the sources alongside the teaching notes, and treat them as starting points for your own investigation.

05

See the method in context.

Four original boards show the method, the evidence boundary, and the practice loop.

Use these diagrams to understand the method, then test it on a small task of your own.

05

The working frame

Every serious task needs a boundary.

This frame is the common language between a person, a model, a tool, and an Agent. Use it before adding permissions or Skills.

Read the task protocol

If a missing input changes the scope, risk, or acceptance test, pause and ask. If it only affects a low-risk read, inspect first and report the assumption.

  1. 01
    Define

    What result is in scope, and what is deliberately out?

  2. 02
    Act

    What may the model or tool do, and what stays paused?

  3. 03
    Verify

    Which source, diff, test, or acceptance check can show what happened?

  4. 04
    Hand off

    What should the next person receive, including the unknowns?

06

Learning path

Seven levels. Four kinds of evidence.

A level is not a reading count. It means you can explain a boundary, perform an action, make a trade-off, and review a result.

Current level / L0

Understand the model before you act.

Explain what an LLM, context, prompt, product, tool, Agent, and Skill can establish before choosing a platform.

Required chapters

    Required lab

      Supporting Skills

        Evaluation fixtures

          Evidence gate

          Four evidence types

            Move on when

            Stop when

            07

            The reading routes

            22 chapters. Four ways in.

            Read in order to build the model. Jump by route when a real task is blocking you. Every route returns to practice and evidence.

            Showing all 22 chapters.

            08

            The lab

            Make the principle observable.

            Labs are low-risk, reproducible tasks. Each one names setup, evidence, a failure variant, a secret boundary, and a reflection.

            LAB 001 · L1

            First safe task

            In a sandbox project, ask Codex to inspect before editing. Turn “done” into a checkable diff.

            starting lab↗
            LAB 013 · L3featured lab

            Auditable vertical slice

            Run one local Markdown change from protocol and baseline to checkpoint, diff, focused check, failure, and transfer.

            maintainer reference accepted · learner not run↗
            LAB 002 · L2

            Task protocol

            Break a vague request into goal, inputs, constraints, acceptance, and failure handling.

            Open exercise↗
            LAB 003 · L3

            Evidence review

            Find a result that looks complete but has no evidence for its claim.

            Open exercise↗
            LAB 004 · L4

            Skill selection

            Explain the choice and refuse to use directory size as a proxy for fit.

            Open exercise↗
            LAB 005 · L4

            Design a Skill

            Turn a stable method into a capability with boundaries, evidence, and failure cases.

            Open exercise↗
            LAB 006 · L5

            Agent stop conditions

            Record observable events, reconcile a lost response, and hand off an uncertain run safely.

            Open exercise↗
            LAB 007 · L3

            Action boundaries

            Compare the evidence needed for reading, editing, running, committing, pushing, and publishing.

            Open exercise↗
            LAB 008 · L3

            Research question

            Turn a broad topic into a question, source plan, and minimum evidence table.

            Open exercise↗
            LAB 009 · L3

            Engineering lifecycle

            Compare direct implementation with a full lifecycle and record the rework evidence.

            Open exercise↗
            LAB 010 · L3

            Shared product context

            Version a shared product understanding and separate facts from hypotheses.

            Open exercise↗
            LAB 011 · L0

            GPT and Codex boundaries

            Use static task cards to separate generation, execution, verification, and external effects.

            Open exercise↗
            LAB 012 · L6

            Team capability migration

            Create a contract for version, owner, permissions, independent reproduction, and rollback.

            Open exercise↗
            LAB 014 · L3

            Resume reconciliation

            Reconcile the task pointer, target, branch, permissions, and side-effect state before continuing.

            Open exercise↗
            LAB 015 · L5

            Evidence delivery

            Split a completion sentence into claims, scopes, outputs, and the smallest next check.

            Open exercise↗
            LAB 016 · L3

            Side-effect boundary

            Separate diagnosis from installation, publication, restart, and other persistent actions.

            Open exercise↗
            LAB 017 · L4

            Skill discovery audit

            Check existence, discovery, loading, behavior, license, and adoption as separate claims.

            Open exercise↗
            LAB 018 · L2

            Language transfer

            Preserve an unaided baseline, correct one meaning-blocking error, then test a changed case without reusing lesson sentences.

            Open exercise↗
            Open the lab rules and all 18 entries
            09

            Capability layer

            Twenty-six Skills. Distinct jobs.

            A Skill is a method with a trigger, an input check, boundaries, stop conditions, an output contract, and a way to verify it.

            Browse the complete Skill registry

            These methods are optional. Start with the situation above; open the full registry when you know what kind of work you need to support.

            01Codex CoachChoose a learning path and practice boundary.↗ 02Task ProtocolTurn a vague request into an executable contract.↗ 03Evidence ReviewSplit completion claims into checkable evidence.↗ 04Skill SelectorChoose a minimum viable capability set.↗ 05Workflow OrchestratorManage stages, checkpoints, and hand-off.↗ 06Research RouterConverge a question into auditable knowledge.↗ 07Product ContextKeep stable principles separate from changing facts.↗ 08Learning CoachPractise with recall, correction, delayed review, and transfer.↗ 09Source InvestigatorTurn broad searches into bounded source-backed investigations.↗ 10Field Signal CuratorTurn public reports into bounded demand evidence.↗ 11Platform Adapter ReviewReject platform lessons without a sourced, runnable delta.↗ 12Platform Fact WatchMap a changing product claim before a named step misleads readers.↗ 13Communication Failure TriageDiagnose one failed interaction and retest the smallest repair.↗ 14Dialogue BriefTurn one untried low-risk request into a copy-ready first message.↗ 15First-Turn CheckInspect an unsent low-risk request for visible boundaries.↗ 16Prompt Card EditorTurn one authorized prompt idea into a source-aware teaching card.↗ 17Adversarial Project ReviewRank material weaknesses before a publication or release decision.↗ 18Request EscalationChoose the smallest safe lane before drafting, researching, or acting.↗ 19LLM Comparison ProtocolPlan a fair two-candidate comparison without inventing a leaderboard.↗ 20Practice TargetTurn a broad learning wish into one observable first attempt.↗ 21Interruption CheckpointPreserve what is known before a retry, a model switch, or a new task.↗ 22Shift HandoffSeparate reusable rules from today’s supplied work item.↗ 23Platform Observation RecordRecord one visible platform surface without turning it into a capability claim.↗ 24Language PartnerRun one bounded typed exchange in the learner's target language.↗ 25Interview RehearsalRehearse one observable answer under a time limit.↗ 26Polish Open-Source ProseRevise public prose and locale copy without changing facts or regional meaning.↗
            RULEOriginal methods first.External Skills must retain the source-project URL and license boundary.
            Open the Skill registry and all 26 methods

            The 26 project Skills (25 original plus 1 reviewed external editorial Skill) remain candidate; fresh-task and native-language evidence are partial. Shift Handoff separates stable criteria from one new item; it does not execute or assume model memory. Interruption Checkpoint preserves a task receipt; it does not retry or recover work. Practice Target sets up one first attempt; it does not prove learning. Platform Observation Record is a visible-surface receipt, not a platform-capability claim. Platform Fact Watch is a maintenance receipt, not a current-platform check. LLM Comparison Protocol is an unrun comparison method, not a model ranking. Adversarial Project Review is not an external review.

            10

            When things go wrong

            Failure is part of the curriculum.

            Use the first useful check, then stop when authority, scope, or evidence is missing. Do not hide the failure behind a polished summary.

            01
            The output looks right.

            Check the original claim, the changed files, the command result, and what was not tested.

            Use evidence review ↗
            02
            The agent keeps retrying.

            Record the same failure, change one diagnostic condition, then retry once or escalate.

            Read stop conditions ↗
            03
            A source tells you to do something.

            Treat external text and tool output as data. It does not grant permission to act.

            Check the boundary ↗
            04
            A product step has changed.

            Refresh the official fact record first, then update the affected chapter or page.

            Follow the update map ↗
            11

            Maintenance frame

            Every update has a fixed home.

            The update map makes future work cheap: locate the canonical file, gather the right evidence, run the right check, and keep the unverified boundary visible.

            01Locate

            Find the registry row and canonical path.

            02Classify

            Separate stable principle, product fact, source, and release change.

            03Evidence

            Record source, scope, owner, hash, and next review.

            04Validate

            Run the focused validator and an independent review.

            12

            Evidence boundary

            A status is a claim about evidence.

            This project does not turn document count, Skill count, or one successful output into “mastery.” Use the status that the evidence supports.

            draft

            Still being written or missing the minimum check.

            candidate

            Structure and basic checks pass; fresh evidence is still needed.

            verified

            The declared scope has positive, boundary, failure, and transfer evidence.

            production-ready

            Safety, maintenance, version, license, and release gates also pass.

            Current evidence is recorded in the current status source and explained by the scoped browser review; the page remains candidate because this review covers only the recorded local scope.

            13

            Next action

            Bring one small problem.

            Finish the foundation route, then choose a reversible first step and keep the receipt. That is the shortest useful way to begin.