القائمة
Use when about to call a library, crate, or framework API you haven't verified, when a dependency's behavior is surprising, when training-data memory might be stale, or when investigating how a dependency actually behaves.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when ingesting, refreshing, listing, searching, or deleting a local corpus with Blackbird code search and `gh blackbird search --fileset`.
Use when reaching for `gh blackbird` (Blackbird code search) for cross-repo lexical, symbol, or semantic search on GitHub — finding callers, ownership, or how systems work without cloning.
Use when creating a GitHub pull request, or when updating an existing PR's title or body so it matches what the code actually does.
Use when authoring or substantially editing a design doc, architecture doc, or subsystem explanation — the "here's what's there and why" companion to an ADR's terse decision record.
Use when creating a repo-tracked multi-agent planning PR for a large project, especially when phases, living docs, parallel agent prompts, and cross-PR coordination are needed.
Use when investigating an alert, monitor, incident, error spike, degraded service, or production anomaly, and the repository has no incident-investigation skill of its own.
| name | reading-source-code |
| description | Use when about to call a library, crate, or framework API you haven't verified, when a dependency's behavior is surprising, when training-data memory might be stale, or when investigating how a dependency actually behaves. |
Read the actual source before you write code against it. Training data goes stale, docs lag the implementation, and "I remember this API" is the most common source of plausible-looking but wrong code. The source is almost always reachable in seconds — read it.
This skill is about the discipline. The how (where the source lives, which search tool to use) is mechanical and varies by ecosystem.
Load this skill when you're about to:
Don't load it for:
std, Go stdlib, Ruby core, common Node built-ins).Read the dependency file first — Cargo.toml + Cargo.lock, go.mod + go.sum, Gemfile.lock, or package.json + lockfile. The version determines which source matters. Reading docs or source for the wrong version is worse than not reading at all — it produces confident, wrong code.
In Rust this matters more than anywhere else: a function may have been added, renamed, or had its trait bounds changed between adjacent minor versions of a crate, and cargo will happily resolve to whichever matches the Cargo.lock.
Official docs are a strong signal but lag the implementation, sometimes by major versions. When the source and the docs disagree, the source wins for the version you're on. When the source and a blog post or Stack Overflow answer disagree, it's not a contest.
Source hierarchy, strongest first:
~/.cargo/registry/src/... for Rust crates, $(go env GOMODCACHE) for Go modules, the gem's install path (bundle info <gem> --path) for Ruby, node_modules/ for JS/TS, vendored deps, or the matching tag on GitHub.cargo doc --open, go doc <pkg>.<sym>, ri <Class>, tsserver/editor hover.Stack Overflow, blog posts, and your own training data are starting points, not citations.
Don't try to internalize the whole crate or package. Find the type, function, or trait you're about to use and read its definition and immediate neighbors. For unfamiliar APIs, also read one or two usage sites in the dependency's own tests — Rust's tests/ and src/**/*.rs #[cfg(test)] blocks, Go's *_test.go, Ruby's spec/, JS's __tests__/ — they show the contract better than the prose docs do.
For cross-repo reading at GitHub, gh blackbird (see the blackbird skill) jumps straight to symbols and usages without cloning. For local source, rg inside the registry cache, GOMODCACHE, gem path, or node_modules is usually faster than a web fetch.
When you've grounded a non-obvious choice in source, mention it briefly and link to it once — e.g. "Using tokio::task::JoinSet (added in tokio 1.21; ~/.cargo/registry/src/.../tokio-1.38.0/src/task/join_set.rs)." Don't narrate a ceremony of detection steps. The user cares about the citation, not the ritual.
If you couldn't find the source — e.g. the dependency is closed-source or only available via a binary — say so explicitly: "I couldn't verify this against the source; treating the docs as authoritative."
If the source-grounded approach contradicts a pattern already in the repo, surface it instead of silently picking one:
The current code calls
reqwest::Client::new(), but the crate now recommendsreqwest::Client::builder()...build()for any client that needs non-default timeouts (seesrc/client.rs:412inreqwest-0.12.4). Want me to migrate this call, match the existing pattern, or leave it for a separate PR?
Let the user choose. Don't quietly modernize and don't quietly cargo-cult.
If you can't reach the source in this session (no network, dep not vendored, closed-source SDK) and you're not confident from recent reading, say so and either ask the user, write the smallest thing that compiles and can be checked, or stop. A confident wrong implementation costs more than a paused one.