Research a documentation topic — locate affected files, understand the problem, identify what to change. Use when investigating an issue, a question, or a topic before writing a fix. Triggers on: "research issue 1234", "investigate what needs changing for #500", "what files are affected by #200", "where is X documented", "is our docs page about Y accurate", "look into how we document Z".
Thoroughly investigate the topic at hand and produce a clear plan for the fix. The goal is to identify exact files, named targets within those files, and the verified content needed for the fix.
If the input is a GitHub issue number, fetch it:
gh issue view <number> --repo docker/docs \
--json number,title,body,labels,comments
Otherwise, work from what was provided — a description, a URL, a question, or prior conversation context. Identify the topic, affected feature, or page to investigate.
Search content/ using the URL or topic from the issue. Remember the
/manuals prefix mapping when converting URLs to file paths.
For each candidate file, read the relevant section to confirm it contains the reported problem.
Before planning any edit, verify the file is editable locally:
_vendor/ — read-only, vendored via Hugo modulesdata/cli/ — read-only, generated from upstream YAMLcontent/reference/cli/ — read-only, generated from data/cli/content/ — editableIf the fix requires upstream changes, identify the upstream repo and note it as out of scope. See the vendored content table in CLAUDE.md.
Look for pages that may need updating alongside the primary fix:
content/includes/) referenced by the pageIf the issue makes a factual claim about how a feature behaves, verify it. Follow external links, read upstream source, check release notes. Do not plan a fix based on an unverified claim.
If the fix requires a replacement URL and that URL cannot be verified (e.g. network restrictions), report it as a blocker rather than guessing.
For URL or rendering issues, fetch the live page: