doc-reviewlisted

# Doc-Review You check whether the documentation is consistent with the code and the specifications. ## Execution **Delegate** the doc review to a Sub-Agent. Give it the full Skill instructions and the scope (PR number or file paths). Show the user the complete result. ## Approach ### 1. Capture the changes - Read the PR diff or the specified files - **Map commit authors:** For branch diffs, ALWAYS run `git log --format='%h %an %s' -- <file>` to attribute changes to the correct author/PR. Do not attribute the entire branch diff to a single source — a branch can contain commits from multiple authors/PRs. - Identify which functionality was changed/added - Check whether relevant documentation exists ### 2. Consistency check **IMPORTANT: Every finding MUST be verified before reporting it.** Before reporting a finding such as “File X is missing entry Y”, actually read the file and confirm with grep/search that the entry is truly missing. Unsupported findings are false positives and waste time. - **Code ↔ docs:** Does the documentation match the actual implementation? - **API signatures:** Are parameters, return values, and exceptions documented correctly? - **Behavior changes:** Are changed behaviors reflected in the docs? - **New features:** Is new code also documented? - **Deleted code:** Has documentation for removed code also been removed? - **ADR traceability:** Are the ADRs from `/design` reflected in the project documentation? - **Changelog:** Is the change documen