Prysai LLM Playbook: a curriculum that refuses to claim it works yet

The problem is not tool choice, it is the missing inspection step

Most material aimed at people who are new to language models starts at the platform layer: which agent framework, which CLI, which skill format. The Playbook starts one layer earlier and states the reason in its own framing. A reader may have heard about Codex, Claude Code, Agents or Skills and wondered which to learn first; the project argues that the question to answer first is how a model uses context to produce an answer, why a fluent answer can still be wrong, and what can be inspected before the result is trusted. The audience is therefore a beginner who has not yet picked a platform, plus an engineer who wants a repeatable loop rather than a prompt collection. The loop is written as a single line in the README: define the task, choose a bounded action, inspect the result, keep evidence, state the limit. That line is the whole product thesis. Everything else in the repository is either an exercise built on it or an adapter that maps it onto a named tool. If you already have a working review process for model output, the foundation route will read as remedial. If you do not, the sequence is the part worth copying.

Five units, three artifacts, and a rule that copied prompts do not count

The default path is the LLM foundation core, described as the only default starting path. It runs five units: explain what an LLM is and is not; write a small request with goal, context, limits and output shape; identify omission, invention, forced ambiguity and overconfidence; check and minimally repair an answer while stating one limit; and repeat the method on an unseen task without a complete prompt template. The fifth unit is the one that distinguishes this from a prompt library, because a template cannot be carried into it. The README is explicit that each unit must leave a learner-authored artifact, and that a copied prompt, a polished model answer, or a green structural check is not proof of learning. Three artifacts are named as the route's working targets: a bounded task card covering goal, supplied context, allowed help, limits, check and stop condition; a checked result record covering what the model proposed, what was inspected, the evidence kept and what remains unknown; and a transfer attempt with a continue, revise or stop decision. The project states these are targets rather than measured outcomes. That distinction is repeated often enough in the README that it reads as a deliberate design constraint rather than hedging.

The evidence ledger is the most unusual part of the repository

The README carries a table headed evidence ledger with three rows, and the rows are graded rather than summarised. The observed row points to a document dated 2026-08-15 covering seven local checks across five sequential runs, with raw milliseconds and a chart. The permitted conclusion is narrow: those named engineering checks were stable in one local Windows worktree, and the result is not a speed, Skill, learner, safety or model result. The second row is labelled captured, unscored, analysis-ineligible. It describes a Shift Handoff output packet containing 18 de-identified fictional outputs, alongside an input-integrity review that found the historical prompt hashes do not bind the prepared Windows prompt bytes. The README's own reading of that finding is that a model-output collection occurred but cannot be compared, scored or aggregated, and cannot support any inference about time, percentage, benefit, efficiency, productivity, learning, safety, accuracy, IQ or model quality. The third row is simply unknown: learner completion, transfer, real-work productivity and IQ, with no conclusion available. A separate research record defines task-scoped completion, rework, time and fixed-rubric measures for any future result, requiring the commit, conditions, raw de-identified records and scorer disagreements to be kept. Publishing a failed integrity check against your own pilot is rare. It also means the repository cannot currently answer the question most buyers ask first, which is whether anyone learned anything.

Codex is the flagship track, and the adapters are explicitly not equivalence claims

Beyond the core, the repository is organised as a transferable core, a Codex flagship track, and adapters for ChatGPT, Claude Code, Gemini, DeepSeek and Grok. The README places Codex, tools, Skills, Agents, professional tracks and named-platform adapters in a later layer, described as useful reference material whose current structure is not learner evidence and does not establish cross-platform equivalence. That sentence is the boundary to hold on to. The adapters tell you how the method is expressed in a given product; they do not tell you that a task card written for one platform transfers unchanged to another. The optional Codex chapter sits at book/chapters/01-gpt-and-codex-EN.md, and the README offers it as an optional boundary chapter rather than a starting point. The instruction is direct: do not enter Codex, Skills or professional tracks until the core route is done. Whether that ordering is enforced by tooling or only by prose is not something the supplied material makes clear.

Getting started, and what the Python side actually is

The entry point is deliberately low-friction. The README states you do not need Codex, Git, a terminal or a private file to begin, and points to the guided reading site at docs.prysai.com/llm-playbook for the five-unit foundation route. The repository route file is book/routes/llm-foundation-core-v1-EN.md. Eight locale entry points are registered, with README-EN.md, README-ZH.md, README-ES.md, README-JA.md, README-KO.md, README-DE.md, README-ZHTW.md and README-FR.md listed, and the README notes that translation review and learner evidence remain in progress. The governance and contract files that define the current scope are docs/product/core-course-contract.md, docs/governance/core-release-scope.md and docs/governance/core-content-inventory.yaml. Python is the primary language, and the project describes static checks that exist and were run locally, but the README does not document an install command, a package name, or a CLI invocation. If you are evaluating this as a Python tool rather than as a curriculum, the supplied material does not give you enough to start, and you would need to read the repository tree directly. The five-minute practice is optional and requires no setup.

Where this is the wrong choice

The project is labelled candidate, and the same word appears against the core route. Its own status text says the structure and static checks exist while learner runs, transfer runs, repeated evaluations and independent review are still pending. If you need a curriculum with completion data, retention evidence or a validated assessment rubric, this repository does not have one and says so. The second limitation is scope. The foundation route is five units aimed at a beginner, and the advanced platform material is deliberately deferred, so a team looking for agent orchestration patterns will find the Codex track is a chapter rather than a manual. The third is the pilot record: an output packet exists but is marked analysis-ineligible because the prompt hashes do not bind the prompt bytes, which means the one dataset a reader might want to reanalyse cannot be. The fourth is licensing ambiguity. The repository reports NOASSERTION as its licence identifier, while the README states curriculum text and teaching assets are CC BY 4.0 and scripts and tooling are Apache-2.0 unless a file states otherwise. Those two signals do not agree, and the README points to LICENSE, LICENSE-CODE and docs/sources/licensing.md for the boundary. Anyone embedding the text in a commercial course should read those three files before copying anything, and should treat the split as a per-file question rather than a repository-wide one. Nothing here is legal advice.

What a general prompt-engineering course does differently

The obvious comparison is a general prompt-engineering course, and the difference is structural rather than a matter of quality. A typical course teaches prompt patterns and stops when the output looks right, which is exactly the stopping point this project warns against with the line do not stop at a plausible output. The Playbook instead makes the artifact the unit of progress: a task card before the request, a result record after it, and a transfer attempt on a task the learner has not seen. The cost of that approach is that it cannot be consumed passively. You cannot finish the route by reading it, because each unit requires something you wrote and a stated limit you are willing to record. The benefit is that the method is platform-agnostic by construction, which is what makes the adapters meaningful rather than decorative. A prompt-pattern course gives you more patterns faster. This gives you fewer patterns and a check you are supposed to run every time. Which one you want depends on whether your failure mode is not knowing what to type or trusting what came back.

Maintenance cost and the upgrade question

The release history is thin. The only release listed is v0.1.0-alpha from 2026-08-16, and the last push to the default branch is 2026-09-09, so the project is under active editing but has not shipped a stable version. The upgrade risk sits in the platform adapters. Codex, Claude Code, Gemini, DeepSeek and Grok change their surfaces on their own schedules, and the README already frames the adapters as reference material rather than evidence, which means a stale adapter is a documentation bug rather than a broken promise. The core route is the part with the longest shelf life, because it depends on how models behave rather than on any vendor's command syntax. Eight locales multiply the maintenance surface: the README states translation review is in progress, so a reader working in Japanese, Korean, German or French should expect the English source to be ahead of the translation. The governance files, docs/governance/core-release-scope.md and docs/governance/core-content-inventory.yaml, are where the current boundary is recorded, and they are the first thing to diff when deciding whether to pull a newer revision into a fork.

Editorial conclusion

Use the LLM foundation route if you want a bounded, inspectable method for working with language models and you accept that the project labels itself candidate with learner completion, transfer and retention not_run. Do not adopt it as a validated training programme, a benchmark source, or a claim that Codex, Claude Code and Gemini are interchangeable; the README states its named-platform adapters do not establish cross-platform equivalence. Before committing, open docs/quality/verification-stability-2026-08-15.md and check what the seven local checks actually cover, then read docs/sources/licensing.md to confirm which files fall under CC BY 4.0 and which under Apache-2.0, because the repository reports NOASSERTION as its licence identifier.

Official sources

1. Issues
2. Project website
3. Prysai/Prysai-LLM-Playbook on GitHub
4. README
5. Releases