Anthropic's prompt engineering course has no licence file and a Google Sheet as its recommended form

Nine chapters, one order, and no licence file

The structure is deliberate and the README insists on it: the course is broken into 9 chapters with accompanying exercises, plus an appendix of more advanced methods, and it is intended for you to work through in chapter order. The sequence runs from beginner, chapters 1 to 3 covering Basic Prompt Structure, Being Clear and Direct, and Assigning Roles, through intermediate, chapters 4 to 7 covering Separating Data from Instructions, Formatting Output and Speaking for Claude, Precognition, and Using Examples, to advanced, chapter 8 on Avoiding Hallucinations and chapter 9 on Building Complex Prompts for industry use cases. The appendix adds Chaining Prompts, Tool Use, and Search and Retrieval.

Chapter 9 is where the exercises get specific, with dedicated ones for financial services and for coding alongside worked examples for a chatbot and for legal services. The stated goals after finishing are the basic structure of a good prompt, the common failure modes and the 80/20 techniques for them, Claude's strengths and weaknesses, and building prompts from scratch.

Chapter order being mandatory is the constraint to plan around. This is a course, not a reference, so there is no entry point for someone who already knows roles and prompt templates and only wants the hallucination chapter. The repository is not archived, its last push was on 2026-08-28, and it has no GitHub releases, so content arrives only as commits on the default branch. There is no LICENSE file among the top-level entries either, which is a separate problem and the subject of another section.

The exercises run on Haiku, and the answer key was written for three Claude 3 models

The README states the model choice plainly: the tutorial uses Claude 3 Haiku, described as the smallest, fastest and cheapest model, and it names two others, Claude 3 Sonnet and Claude 3 Opus, as more intelligent than Haiku, with Opus the most intelligent of the three. Practising on the cheapest model is a defensible teaching decision, since prompt iteration should not cost much, and it means the techniques transfer rather than the exact outputs.

The transfer is the part to be careful about. Every worked answer in the course, and every expectation in the answer key spreadsheet, was produced by a model from the Claude 3 family, so a reader running the same prompt on a different model is comparing against a response that was never produced that way. The three techniques the course teaches that are most sensitive to model capability are the ones in the middle of the book: precognition, or thinking step by step, and using examples. Both work by shaping how much computation the model spends, and the README's own statement is that Opus is the most intelligent model of the three, which is an admission that the same prompt does not buy the same result on all of them.

The practical instruction is to treat the answer key as a reference for shape rather than for wording. If your work is going into production on a stronger model, validate the prompts there. Nothing in the README tells you to re-run the exercises on Sonnet or Opus, and the appendix on tool use and retrieval is where a capability gap would show up first.

The README recommends the Google Sheet, which puts the course outside version control

The repository is not the recommended way to take this course. The README says the tutorial also exists on Google Sheets using Anthropic's Claude for Sheets extension, and recommends that version as more user friendly. So the maintained artefact a reader is pointed at is a spreadsheet, and the repository notebooks are the alternative.

That has consequences worth stating before anyone plans a team session around it. A spreadsheet is not in the repository, so its history is not the repository's history, and a change made in the sheet leaves no trace in the commits. It requires a Google account and a third-party extension in the browser, which is a different access and data-handling question from cloning a repository. And the answer key is a spreadsheet too, so the reference answers and the exercises live in two documents that can drift apart independently of the notebooks.

The difference between the two forms is the practical one. The notebooks are files you can fork, diff and pin, and they are the version to use if you want to adapt an exercise to your own domain or keep a copy that does not change under you. The sheet is the version to use if you want the course to feel like a course rather than a repository, which is what the README is optimising for. For an individual learner the sheet is the better experience. For anything you intend to maintain, take the notebooks and copy the exercise text out of the sheet before it moves.

AmazonBedrock/ and Anthropic 1P/ are the two doors, and neither is explained

The top-level entries are short: a README, a .gitignore, and two directories, AmazonBedrock/ and a directory whose name is Anthropic 1P/ with a space in it. The primary language GitHub reports for the repository is Jupyter Notebook, so the material is notebooks, and the README's own instruction for starting is to go to 01_Basic Prompt Structure, which is a folder name in the same style, numbered and spaced.

The two directory names read as two ways of reaching a model, one through Amazon Bedrock and one through Anthropic's own first-party access. Nothing in the README says so, says which one a new reader should open, or describes what changes between them, and a directory name containing a space is not something a script or a path expression handles without quoting. So the first mechanical step of taking the course is finding out which half of the tree is yours, by opening files rather than by reading instructions.

That matters because the cost profile is different on each side and because credentials differ. A reader with Bedrock access and a reader with a first-party key are looking at different notebooks, and a team mixing the two will produce prompts against different backends. The README does not document a configuration step, an environment variable or a dependency file, and none of those appears in the top-level entries either, which is the gap the next section is about.

The README contains no setup command, and the top level has no environment file

There is no installation instruction anywhere in the README, and nothing that looks like one. No package manager command, no Python version, no API key variable, no requirements file. What the README offers instead is a reading order and two links, to the documentation site for the Claude models and to the Sheets version of the course.

The tree does not fill the gap. The top-level entries are the README, a .gitignore and the two model-access directories, with no pyproject.toml, no requirements.txt, no environment file and no lock file. GitHub also records no licence for the repository. For a course aimed at people new to prompting, the missing piece is the boring one: how to get a notebook to run at all, which means a Python environment, a notebook environment, and a way to call a model.

The consequence is that every reader assembles their own setup, and the two that matter diverge sharply. A reader who follows the README's recommendation loses the repository entirely and works in a browser, where the extension handles the model call. A reader who clones the notebooks has to install a notebook stack, obtain credentials for whichever of the two directories they picked, and hope the examples still run against a current SDK, since nothing in the repository records which version they were written for. Plan for an afternoon of setup on the second path, and treat the first as the reason the README recommends the sheet.

The Example Playground is the interactive part, and it needs a live model

Each lesson has an Example Playground area at the bottom, and the README's description of it is the whole pedagogy: you are free to experiment with the examples in the lesson and see for yourself how changing prompts can change Claude's responses. The interactive element of this course is not a widget in the notebook. It is a live model answering you while you edit a prompt, and the answer key spreadsheet exists to check what you got against.

That design has a cost, and it is the reason the course cannot be completed offline. Every chapter depends on a model responding, so a reader without a working access path cannot do the exercises, only read them, and the failure mode is silent because the lesson text still reads fine. The stated goal of recognising common failure modes is the part that most needs the loop, since a failure mode is something you have to watch the model do wrong before you can see the fix work.

It also means the course measures nothing. There is no scoring, no test, no check that you improved a prompt, only a reference spreadsheet to compare against. For self-study that is enough. For a team, the value is in the comparisons people bring back, and the README does not describe a way to collect them, so that part is yours to build.

The appendix stops at chaining, tool use and retrieval, and nothing after

The last thing the course teaches is an appendix titled Beyond Standard Prompting, with three entries: Chaining Prompts, Tool Use, and Search and Retrieval. Three items, no version, no indication of depth. Tool use and retrieval are the two topics a working application actually needs, and they are also the two most dependent on a current model and a current API, which is where a course written against the Claude 3 family is most likely to have aged.

Read the course as a whole, the shape is a fundamentals book with a short advanced tail. Chapters 1 to 3 are about the form of a prompt, chapters 4 to 7 about structure, output and examples, chapter 8 about a specific failure mode, and chapter 9 assembling the pieces for four named industries. The industry cases are the most transferable part, because a chatbot prompt, a legal services prompt and a financial services prompt differ in vocabulary rather than in technique.

What is not here is as useful to know. The README does not cover evaluating a prompt beyond comparing it to an answer key, does not cover latency, cost or context limits, does not cover version control for prompts, and does not point to a maintained reference beyond the models documentation page. If your team needs prompts that survive contact with production traffic, this course gives you the writing and none of the surrounding practice. Take the chapters, skip the assumption that the appendix is current.

Editorial conclusion

Work through this course if you are new to prompting Claude and want the exercises and the troubleshooting loop rather than a reference to consult. Do not adopt it as internal training material without checking the licence position first, because no licence file is listed among the repository's top-level entries and GitHub records no licence. Verify first by opening the version you will actually use, since the README recommends the Google Sheets copy over the notebooks, and by confirming which of the two access directories in the tree your model credentials will work with.

Frequently asked questions

Official sources

1. Official README
2. Project repository