AMAZON · Read-only operations patrol

Amazon account patrol guide: Ziniao CLI, read-only checks and evidence

blues19-amazon-account-patrol Reuse the target Ziniao store's existing browser session to check Amazon Seller Central account health and performance notifications, saving verifiable local records. This turns repetitive checks across marketplaces into a fixed workflow.

Author: Blues · Updated: 2026-10-14 · Based on the public README and execution workflow

What it checks

The public version covers the US, Canada, Mexico, UK, Germany, France, Italy, Spain and Netherlands. Marketplace codes are us / ca / mx / uk / de / fr / it / es / nl . It reads account health and performance notifications separately in each marketplace, recording page text, actual URLs, summaries, recommendations and screenshot paths.

The workflow verifies the active country, domain or Marketplace ID to avoid checking the wrong marketplace after switching accounts. A clicked country button or a Seller Central domain alone does not prove the target marketplace is open.

Before you run it

Environment: Ziniao Browser, Node.js 16+, an installed and initialized ziniao-cli , and Python 3.10+. Patrol scripts use Python's standard library.
Identity and permissions: Choose a BOSS or member account; the browser and developer platform should use the same account. A member-created CLI app needs BOSS approval, and store access must be granted separately.
Target: A Ziniao store ID explicitly selected by the user, plus one supported marketplace code or all nine. Do not infer stores or marketplaces from historical examples.
Output location: Choose a private directory suitable for sensitive store data. If work-hour restrictions apply, provide both timezone and hours.

First use doctor 、 config show and store list to verify the environment, current configuration and visibility of the target store. CLI app approval does not grant all stores; ask an authorized administrator to add access if the target is missing.

Start with one marketplace

Prepare and verify Ziniao CLI. Follow the repository's environment setup for installation, initialization, app approval and terminal binding. The account owner handles authorization; agents must not retain passwords, OTPs or keys.
Install the complete Skill. Keep SKILL.md 、 agents 、 scripts 、 references 、 assets and tests , and verify that the Python version and script help are readable. The repository's Windows installation entry is:

 npx.cmd skills add ivan51769/blues19-amazon-account-patrol -y

Confirm the store and marketplace. Query stores visible to the member, then run a single-marketplace patrol from the Skill directory. Below, <ziniao-store-id> is a placeholder you must replace; do not run it unchanged.

ziniao-cli.cmd store list --format table
python scripts\amazon_account_patrol.py --store-id <ziniao-store-id> --marketplace us

Check both page types and their evidence. After reviewing one marketplace, consider changing --marketplace us to --all-marketplaces . Batch runs save failures and continue to the next marketplace; partial completion does not mean all nine are healthy.

In an agent supporting Skills, you can also ask: "Use $blues19-amazon-account-patrol to run a read-only US patrol on my selected store, saving local records only. Confirm the store ID and marketplace first; stop and tell me if required information is missing."

How to verify observable outputs

The marketplace really switched: The page should reach the target console; applicable country labels, hostname and Marketplace ID evidence must agree. An account-selection page is not a successful patrol.
Separate evidence for both page types: The actual account-health and performance-notification URL paths must match their target pages and contain nonempty rendered text. One page cannot fill a gap in the other.
Local records can be checked: The Markdown record contains two actual URLs, two original texts, summaries/recommendations and two screenshot paths; logs are timestamped. Screenshots stay at the paths returned by Ziniao CLI and are not automatically copied into the output directory. Both paths must be nonempty and files must exist.
Exceptions are retained explicitly: Review the corresponding failure record for login prompts, missing inputs, unloaded pages or unconfirmed marketplaces. A summary is interpretation; verify original text and screenshots.

Permission and capability boundaries

This Skill includes only account-health and performance-notification checks. It does not modify products, prices, inventory, ads, cases, notifications or account settings, or automatically submit appeals.
Reuse only the target store's existing session and autofill. Stop when a verification code is missing, expired or rejected; never resubmit the same old code repeatedly.
Page changes, browser failures and marketplace verification have retry limits: the documented workflow allows at most two refreshes for crashes/error pages and one marketplace-confirmation retry.
Local output is the default. Feishu delivery is a separately configured opt-in requiring app permissions and a target group. API acceptance and actual group visibility are separate checks.
Original text, screenshots and records may contain private store information; do not publish them on a website or repository. This guide explains the public workflow and does not imply your store has been checked or is risk-free.

Public sources and further reading

Based on the public materials below. Repository versions evolve; use installation instructions and arguments for your actual version.