mirror of
https://github.com/pewdiepie-archdaemon/odysseus.git
synced 2026-09-14 20:22:22 +02:00
1.8 KiB
1.8 KiB
name, description, version, category, tags, status, confidence, source, owner, created
| name | description | version | category | tags | status | confidence | source | owner | created | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| developer-docs | Find, read, and apply authoritative developer documentation during implementation | 1.0.0 | dev |
|
published | 1.0 | builtin | 2026-08-18T00:00:00Z |
When to Use
Use when the user asks how a library, framework, API, protocol, CLI, or SDK works, or when implementation depends on version-specific behavior. Prefer this skill over guessing from memory.
Procedure
- Identify the exact product, package, version, and task. Ask one focused clarification only when the target is genuinely ambiguous.
- Prefer the vendor's or project's primary documentation, source repository, release notes, and API reference. Use a general search only to locate those sources.
- Read the relevant page or reference section, then apply the documented behavior to the user's codebase and active workspace.
- Separate documented facts from inference, and call out version or environment assumptions.
- For code changes, add a focused regression test for the documented contract and run it before reporting completion.
Pitfalls
- Do not present search snippets, stale cached knowledge, or a third-party tutorial as authoritative when primary documentation is available.
- Do not silently mix instructions from different major versions.
- Do not claim an API or option exists without confirming it in the relevant reference.
- Do not use web search for a local project task when the active workspace and local tools can answer it.
Verification
- The cited or retrieved documentation matches the target version.
- The implementation or answer distinguishes source-backed facts from inference.
- Any code change has a focused test or a concrete verification command.