Pixiv CLI Develop

Develop pixiv-cli

Establish the change

Read root AGENTS.md, the relevant architecture section, the exact owner code, and its tests. State the observable result and what is outside scope. For a bug, reproduce it and trace input through the owner before proposing a fix. For ambiguous or cross-boundary work, settle compatibility, data ownership, and acceptance criteria first; a small explicit fix needs no design ceremony.

Inspect git status --short, branch, and base SHA. Reuse a suitable isolated worktree or create one at an unused agreed location with git worktree add -b BRANCH PATH BASE; substitute verified values, preserve other worktrees, and never reset someone else's changes. Set the working directory on every tool invocation.

Use available LSP definitions, references, callers, and impact analysis before changing symbols. If unavailable, report it, inspect imports/callers with targeted rg, and verify the affected packages with the compiler/tests. Read foundational documents and exact edited code yourself; delegated summaries are evidence, not design authority.

Go design and language rules

• Use the go.mod toolchain and gofmt. Preserve Go initialisms, descriptive package names, and consistent receiver names. Document affected exported contracts, including cancellation, ownership, optional values, and side effects. Apply pixiv-cli-code-commenting to comments and numbered stages; English and Chinese prose are both acceptable, with valid Go doc syntax.
• Prefer concrete types and existing owners. Define small interfaces at a real consumer seam, not one interface per implementation; avoid public abstractions introduced only for tests. Keep constructors explicit and side-effect boundaries visible.
• Keep Cobra, terminal input, JSON presentation, and exit handling in CLI owners. Keep MCP schema/presentation in its tool owner. Reuse shared records and traversal rather than copying pagination, filtering, or output rules into each adapter.
• Pass context.Context as the first parameter where cancellation applies and propagate it through requests and loops. The caller owns cancellation policy. Keep goroutine lifetime and resource closure explicit; avoid detached workers, shared mutable globals, and unbounded background activity.
• Return contextual errors while preserving errors.Is/errors.As classification. Do not log and return the same failure at every layer. Keep the SDK silent by default and redact at trust boundaries; never wrap a secret-bearing upstream response wholesale.
• Distinguish absent, zero, empty, and invalid values when the wire contract does. Preserve unknown SDK fields where the record contract requires them. Do not fill unavailable upstream fields with invented defaults or advertise schema-only capabilities.
• Preserve atomic persistence and observable committed/unknown outcomes. Test credential revision races, cleanup, cancellation, and file permissions when those mechanisms change; do not claim rollback after a committed replacement.
• Optimize only against an observed cost or requested requirement. Prefer removal/reuse, standard-library or native features, existing dependencies, then a direct local implementation. Add a shared abstraction only when stable current uses make it simpler.

Use the official Go Code Review Comments for additional language guidance; the repository's concrete API, storage, and ownership contracts above still apply.