A professionally maintained SDK with clear purpose and solid docs, but setup friction and contributing barriers cost it points.
last scored 2026-06-15
Readiness lenses
The same repo, two ways: how ready it is for an AI coding agent, and for a human newcomer. Switch lenses to see each one's score and checks.
How ready the repo is for an AI coding agent to read, build, and operate it.
26 of 35 checks passed across 6 categories.
Machine Orientation
5 checks passed3 problems found
- lowllms.txt present
An llms.txt is the emerging machine-orientation standard — a curated map for LLMs.
Fix: Add an llms.txt pointing at the key docs and entry points.
- lowTopics set
GitHub topics situate the repo's domain and stack for an agent at a glance.
Fix: Add a few GitHub topics describing the domain and stack.
- lowArchitecture doc
An ARCHITECTURE doc hands an agent the module map instead of making it infer one.
Fix: Add an ARCHITECTURE.md describing the major components and how they fit.
- README present — An agent reconstructs what the repo is and how to work in it from the README first.
- Agent instructions file — AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
- Agent instructions stay lean — A bloated instructions file burns context and measurably hurts more than it helps.
- Repository description set — The one-line description is the fastest orientation signal an agent reads.
- Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Reproducible Setup
5 checks passed1 problem found
- lowEnv template present
A .env.example tells an agent which configuration keys it must supply to run.
Fix: Ship a .env.example listing every required key with placeholder values.
- Lockfile committed — Without a lockfile two clones can resolve different dependency trees — the build isn't reproducible.
- Runtime / toolchain pinned — An unpinned runtime makes an agent guess the version a clean environment needs.
- Version pins are exact — A floating pin (a bare major, or a range) still drifts between installs.
- Container or dev-container — A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
- Dev container — A .devcontainer gives an agent a one-command, fully-declared environment.
Code Navigability
2 checks passed0 problems found
- Conventional source layout — A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.
- TypeScript strict mode on — Strict typing gives an agent typed signatures to anchor an edit on, not guesses.
Verification Surface
5 checks passed2 problems found
- lowTask runner present
A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
Fix: Add a Makefile / Taskfile / justfile collecting the common commands.
- lowTypecheck command
A typecheck script lets an agent catch type errors before they ship.
Fix: Add a `typecheck` script (e.g. `tsc --noEmit`).
- Tests present — Runnable tests are the ground truth an agent checks its own edits against.
- Test command defined — A `test` script is the documented, discoverable way to run the suite.
- Lint command defined — A linter an agent can run catches a class of mistakes before they ship.
- CI configured — Readable CI is the feedback loop an agent reads to know what 'green' means here.
- Build command — A documented build command is the discoverable way for an agent to produce artifacts.
Agent Safety
6 checks passed2 problems found
- medium.gitignore covers env files
An ignore rule for .env is what keeps the next careless commit from leaking secrets.
Fix: Add `.env` (and `.env.*`) to .gitignore.
- lowAutomated dependency updates
Dependabot / Renovate keeps dependencies patched without a human in the loop.
Fix: Enable Dependabot or Renovate.
- No committed .env — A tracked real .env hands secrets to anything — including an agent — that reads the repo.
- No exposed secrets — Secret-shaped literals in tracked files are a live credential leak.
- CODEOWNERS present — CODEOWNERS marks the 'don't touch without review' zones an agent should respect.
- .gitignore present — A .gitignore is the first guard against an agent committing secrets or build junk.
- Security policy — A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
- License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.
Context Economy
3 checks passed1 problem found
- lowGenerated / vendored files marked
A .gitattributes linguist marker tells tools (and agents) what to skip.
Fix: Mark generated/vendored paths in .gitattributes (linguist-generated / linguist-vendored).
- Dependencies not vendored in — A committed node_modules / vendor tree drowns the real signal an agent needs.
- Build output not committed — Generated dist/ · build/ output is noise an agent has to read past.
- No oversized source file — A single file in the hundreds of KB blows past an agent's effective context window.
How ready the repo is for a human newcomer to understand, set up, and contribute.
78 / 10017 of 25 checks passed across 6 categories.
First Impression
85Clear purpose, good quick-start example, and external docs link—but a newcomer has to leave the repo to find the full story.
The README clearly states what the project is (Claude SDK for TypeScript), links to comprehensive external documentation, and provides a working code example. However, there's no architecture overview, no explanation of the four sub-packages (aws-sdk, bedrock-sdk, foundry-sdk, vertex-sdk) visible in the repo, and the getting-started example hardcodes a specific model name without mentioning available models. The repo feels like a published package rather than a navigable source project.
Getting Running
62Installation for npm users is trivial, but building from source is brittle and poorly documented.
The README only covers `npm install` for package consumers, not developers. CONTRIBUTING.md tells developers to run `yarn && yarn build`, but the `package.json` shows a `prepare` hook that runs shell scripts checking git state—this is a hidden gotcha for first-time builders. The mock server requirement for tests (`./scripts/mock` against OpenAPI, using an external tool called 'steady') is mentioned in CONTRIBUTING but not in any README, and no guidance on installing or running that external tool is provided. Node.js 18+ is documented, but no lock file versions or dependency pinning strategy is visible.
Finding Your Way
72Well-organized package structure and clear naming conventions, but the monorepo design and code generation muddies discoverability.
The main source lives in `src/` with clear subdirectories (core, internal, lib, helpers), and there are 25+ well-named examples in `examples/`. However, the CONTRIBUTING.md reveals that most of the SDK is generated code that can conflict with manual patches, and the generator never touches `src/lib/` and `examples/`—but a newcomer browsing the codebase has no way to distinguish generated from hand-written code. The four sub-packages in `packages/` (aws-sdk, bedrock-sdk, etc.) are visible but their relationship to the main SDK and when/why to use each is not explained anywhere in the snapshot.
Path to Contribute
68Basic contribution docs exist but lack detail on code style, PR review process, and beginner-friendly first issues.
CONTRIBUTING.md covers environment setup, example patterns, testing, linting, and publishing—solid coverage. However, there is no CONTRIBUTING template or issue/PR templates visible in the snapshot, no label for beginner-friendly issues ('good-first-issue', etc.), no code style guide beyond 'use prettier/eslint', and no explanation of the release-please automation or how to structure commits to trigger releases. The test setup requires a mock server against an external OpenAPI spec, but no guidance on what changes require tests or how to write new tests is provided.
Signs of Life
82Active maintenance with recent commits, automated releases, and robust CI/CD—clear ongoing investment.
Last pushed 2026-06-15 (recent), 1999 stars, 113 open issues, and multiple GitHub workflows (CI, releases, publish-npm) indicate active development and release automation. The repo has a monorepo structure, CHANGELOG.md, MIGRATION.md, and SECURITY.md—signs of mature stewardship. However, the snapshot does not show issue/PR turnover rates, contributor count, or response times, so the 'responsive' part of the category can't be fully verified.
Open Door
86MIT license is clear, security policy is documented, but no code of conduct is visible.
The LICENSE file is present and the README references it, MIT is explicitly stated in package.json, and SECURITY.md exists for vulnerability reporting. However, there is no CODE_OF_CONDUCT.md visible in the file tree or snapshot, which is important for signaling community tone and safe participation. The CONTRIBUTING.md mentions opening an issue but doesn't explicitly say it's the first place to ask for help, and there's no discussion forum, Discord server, or other community channel mentioned.
First Impression
2 checks passed1 problem found
- lowTopics set
Topics situate the project's domain at a glance and help a newcomer find it.
Fix: Add a few GitHub topics describing the domain and stack.
- README present — The README is the first screen — with none, a newcomer has nothing to land on.
- Repository description set — The one-line description sets expectations before a newcomer even opens the README.
Getting Running
5 checks passed1 problem found
- lowEnv template present
A .env.example shows a newcomer exactly which settings they must fill in to run it.
Fix: Ship a .env.example listing every required key with placeholder values.
- Lockfile committed — Without a lockfile a newcomer's install resolves differently and hits errors the docs don't mention.
- Prerequisite versions pinned — Unpinned prerequisites are the classic 'works on my machine' first-run failure.
- One-command environment — A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
- One-click dev container — A .devcontainer lets a newcomer start in a cloud IDE with zero local setup.
- Versions pinned exactly — A floating version still drifts — a newcomer can hit a break the maintainer never saw.
Finding Your Way
2 checks passed1 problem found
- mediumArchitecture / overview doc
An overview hands a newcomer the map instead of making them reconstruct it.
Fix: Add an ARCHITECTURE.md (or a 'Project layout' README section) naming the key directories.
- Conventional source layout — A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
- No oversized source file — A single thousand-line file is a wall a newcomer bounces off.
Path to Contribute
3 checks passed3 problems found
- lowIssue templates
Issue templates show a newcomer how to file something useful — and that contributions are welcome.
Fix: Add issue templates under .github/ISSUE_TEMPLATE.
- lowPull-request template
A PR template tells a first-time contributor what a good change includes.
Fix: Add a PULL_REQUEST_TEMPLATE.md.
- lowTask runner
A Makefile / Taskfile gives a contributor a single index of the project's commands.
Fix: Add a Makefile / Taskfile collecting the common dev commands.
- CONTRIBUTING guide — A CONTRIBUTING guide is the difference between a guessed and a guided first PR.
- Test command defined — A documented test command lets a contributor check their change before opening a PR.
- Lint command — A linter lets a first-time contributor catch style issues before review.
Signs of Life
2 checks passed1 problem found
- lowAutomated dependency updates
Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
Fix: Enable Dependabot or Renovate.
- Tests present — A test suite signals a project that's cared for, not abandoned.
- CI configured — Green CI on every change tells a newcomer the project is actively kept working.
Open Door
3 checks passed1 problem found
- lowCode of conduct
A code of conduct states the social ground rules that make it safe to step in.
Fix: Add a CODE_OF_CONDUCT.md (the Contributor Covenant is the de-facto standard).
- License present — With no license the project isn't legally reusable — the door is shut however friendly the README.
- License is a standard one — A non-standard or custom license is a legal question mark a newcomer won't resolve.
- Security policy — A SECURITY.md tells a newcomer how to report a problem responsibly.
Where the grip slips
- highGetting Running+12 pts if fixed
Mock server setup for testing is undocumented and requires external tool
CONTRIBUTING.md tells developers to run `./scripts/mock` and then `yarn test`, citing a requirement for a mock server against OpenAPI spec using an external tool called 'steady'. However, there is no install guide for 'steady', no CI config showing how the CI actually runs tests, and no fallback or guidance for running tests without the mock server. A newcomer will run `yarn test` and hit an error with no path forward.
Fix: Document the mock server setup in CONTRIBUTING.md: add a 'Mock Server Setup' section with links to install 'steady', instructions to run `./scripts/mock`, and explain what happens if tests fail due to mock server issues. Alternatively, show how CI runs tests in the `ci.yml` workflow and make that the source of truth.
- highFinding Your Way+11 pts if fixed
No explanation of four sub-packages and when to use each
The file tree shows four separate SDKs in `packages/` (aws-sdk, bedrock-sdk, foundry-sdk, vertex-sdk), each with their own package.json and CI config. The README and CONTRIBUTING.md do not mention these exist, their purpose, or when a user should reach for one vs. the main package. A newcomer exploring the repo will be confused by the structure and may not realize these are separate entry points for different deployment targets.
Fix: Add a 'Monorepo Structure' section to the README or CONTRIBUTING.md explaining the four sub-packages, their purpose (e.g., foundry-sdk for Anthropic Foundry, aws-sdk for AWS Bedrock), and when a contributor should modify which one. Link each to its own README if those exist and are helpful.
- mediumFinding Your Way+8 pts if fixed
Generated vs. hand-written code is not labeled or distinguishable
CONTRIBUTING.md states that 'most of the SDK is generated code' and that modifications 'may result in merge conflicts' and the generator 'will never modify the contents of `src/lib/` and `examples/` directories.' However, a newcomer reading the source tree has no way to tell which files are generated and which are safe to edit. There is no comment header, no .generated-marker, and no listing of which directories are generated.
Fix: Add a comment block at the top of all generated files (e.g., `src/api.ts`, `src/api-promise.ts`, generated client files) stating 'This file is generated and should not be manually edited' with a link to CONTRIBUTING.md. Alternatively, create a `GENERATED_FILES.md` listing all generated paths and an explanation of the generation process.
- mediumPath To Contribute+7 pts if fixed
No PR or issue templates to guide contributors
The snapshot does not show GitHub issue or pull request templates (normally `.github/ISSUE_TEMPLATE/` and `.github/PULL_REQUEST_TEMPLATE.md`). Without these, contributors may submit incomplete PRs or issues, and maintainers have no structured way to prompt for required info (e.g., SDK version, reproduction steps, which example doesn't work).
Fix: Create `.github/ISSUE_TEMPLATE/bug_report.yml` and `.github/ISSUE_TEMPLATE/feature_request.yml` with fields for SDK version, environment, minimal repro, and expected vs. actual behavior. Create `.github/pull_request_template.md` with a checklist for tests, docs updates, and changelog entries.
- mediumGetting Running+6 pts if fixed
Build from source has hidden gotchas in the prepare hook
The `package.json` includes a `prepare` script that runs shell scripts checking git state and conditionally building/swapping symlinks. This is not documented in CONTRIBUTING.md and will cause confusion when a developer clones the repo, runs `yarn`, and sees unexpected behavior. The `check-is-in-git-install.sh` is cryptic—a developer with no context may think the build failed.
Fix: Add a note to CONTRIBUTING.md under 'Setting up the environment' explaining that `yarn` will run a prepare hook that checks git state; clarify what the hook does and why (e.g., 'to ensure dist/ stays in sync'). If the prepare hook is only for CI/CD, move it out of package.json and into a separate CI step.
- lowPath To Contribute+5 pts if fixed
No beginner-friendly issues or contribution roadmap
The repo has 113 open issues but the snapshot does not show any labels like 'good-first-issue', 'help-wanted', or 'beginner-friendly'. New contributors have no signal of which issues are safe or suitable for first contributions. There is also no contribution roadmap or list of high-value contributions Anthropic would like.
Fix: Use GitHub issue labels to mark 5–10 beginner-friendly issues as 'good-first-issue' or 'help-wanted'. Add a 'Contributing' section to the README or a `CONTRIBUTING.md` header noting that newcomers should look for these labels. Optionally, maintain a simple roadmap in the repo documenting high-priority gaps or features.
- lowPath To Contribute+5 pts if fixed
Examples are not easily executable without knowing the shebang pattern
The CONTRIBUTING.md shows that examples like `examples/<your-example>.ts` require a shebang (`#!/usr/bin/env -S npm run tsn -T`) and `chmod +x` to run as executable scripts. This is clever but not intuitive—a newcomer may not know to make the file executable or may try to run `node examples/demo.ts` and get an error. Only the shebang pattern is shown; there's no explanation of why this is necessary or when to use it.
Fix: Add an 'Examples' section to CONTRIBUTING.md or README.md explaining: (1) examples have a shebang and require `chmod +x` to run as executables, (2) the pattern `#!/usr/bin/env -S npm run tsn -T` uses ts-node to run TypeScript directly, (3) how to run an example (`./examples/demo.ts` vs. `yarn tsn examples/demo.ts` vs. `node dist/examples/demo.js`). Provide a copy-paste template for new examples.
- lowOpen Door+4 pts if fixed
No code of conduct or community guidelines
The file tree contains SECURITY.md and CONTRIBUTING.md but no CODE_OF_CONDUCT.md. This signals to contributors that the project may not have clear norms for respectful participation, which is especially important for a widely-used SDK.
Fix: Add a CODE_OF_CONDUCT.md (e.g., based on Contributor Covenant) at the repo root and link it from CONTRIBUTING.md and README.md.
Show your score
[](https://latch.fyi/anthropics/anthropic-sdk-typescript)Share this analysis
https://latch.fyi/anthropics/anthropic-sdk-typescriptFixed some issues? Re-analyze to measure your progress →
Copy the whole report
Grab the entire verdict in one go — a Markdown block for a README or an issue, plain text, or a prompt you can paste straight into an LLM.