pixiv-cli-review

Review pixiv-cli

Fix the review boundary

Inspect git status --short, git diff --stat, and the actual diff. For a PR/commit range, identify base and head SHAs and review that exact range; an empty working diff does not mean the PR has no changes. Read the originating requirement and relevant AGENTS.md routes. Do not guess the review range or treat another agent's summary as evidence.

Require each changed path to serve the requested result or an affected durable contract. Flag incidental planning notes, local evidence, temporary probes, and unrelated cleanup for removal from the PR; use PR scope checks.

Review the change, not an imagined framework

• Behavior: trace changed inputs to outputs and compare with acceptance criteria. Check CLI text/JSON/NDJSON, record identity, logical pagination, optional fields, typed errors, and command-specific defaults. Verify local search filters are not falsely passed upstream.
• Architecture/Go: apply the develop rules. Check real ownership, interface necessity, context/goroutine lifetime, error classification, and that public SDK changes are intentional and listed for the changelog. Prefer deleting speculative machinery; length alone is not a finding.
• Structure and naming: apply naming and placement. Flag vague names, dependency bags, forwarding function fields, test-only exported seams, retained internal compatibility paths, code placed where its container's name no longer describes it, and new files without a header comment.
• Security/state: check secret redaction, SQL/query boundaries, credential revision transactions, atomic writes and commit outcomes, permissions, URL/redirect policy, and trusted-local versus remote input assumptions. Preserve explicitly supported private resource routes rather than applying a blanket network ban.
• MCP: verify schema validation, SDK routing, separate Pixiv/FANBOX runtimes, protocol-clean stdio, authenticated HTTP, capability-specific registration and structured errors. Use the MCP workflow for changes at that boundary.
• Native/release: use native or CI only when touched. Review source/artifact identity, platform evidence, permissions, and immutable handoffs, not exact YAML formatting or arbitrary job counts.
• Tests/docs: apply the seven-contract checklist and caps. Require the owning checklist row and missing scenario before requesting permanent test code; use ignored probes for other investigations. Check CI-selected tests/support remain verbatim during rewrites, and apply the removal criteria. Preserve actual Red/Green and relevant regression evidence; live verification is manual and requires explicit authorization.
• Readability: apply the commenting rules. Check whether an extraction reduces total mental effort rather than just line count; reject noisy per-line comments, unsupported guarantees, and mandatory stage numbering. Either source-comment language is acceptable. Preserve machine-consumed directives and affected locale/product contracts.