A6 · The Resource Library

A6 · reference

The Resource Library

You already have a bookmark folder full of agent resources. Half the links are dead, a quarter point to tools that changed their APIs two majors ago, and you cannot remember why you saved the rest. This appendix is the opposite: a short list where every entry was fetched, checked, and kept only because some lesson in this course actually leans on it.

The full library lives at /resources. Filter by tag: official docs, the Anthropic engineering posts the course cites, the MCP protocol material, canonical repos, vetted plugins, and the third-party docs the capstones depend on.

Before you trust anything not on this list

The library is deliberately small, which means most of what you find in the wild is not on it. For everything else, apply the checklist from lesson 2.8. It was written for plugins, but the logic generalizes to any tool, server, or template you are about to let near your machine:

  1. Read the "Will install" listing. The install screen shows every command, agent, skill, hook, and MCP or LSP server a plugin adds. If you would not approve one component alone, do not approve the bundle.
  2. Read the hooks. Open the source and read hooks/hooks.json or equivalent before it ever runs. A hook that curls a URL you do not recognize, writes outside the project, or runs on every prompt is a no.
  3. Check the context cost. The install screen estimates tokens added every turn. A thousand tokens per turn is rent paid from your attention budget, forever, used or not.
  4. Check maintenance. Last-updated date, commit activity. An unmaintained wrapper around a moving tool is worse than no tool.
  5. Check what its MCP servers talk to. A bundled server is a trust decision with the same boundary and the same injection surface as any server from 2.7.

How an entry earns a place here

Three tests, all mandatory. The URL was fetched this build cycle and resolved. The project shows recent maintenance (for repos, a push within the last year, checked against the GitHub API). And the course actually uses it: every entry is load-bearing for at least one lesson, so the why line on each card tells you which one. Nothing gets in on reputation, and anything that goes stale gets cut at the next verification pass.

That is the whole appendix. The habit it teaches is the point: never recommend, install, or build on something you have not fetched and read this month.

Sources