Deliverable shape

What a repricing engagement hands back. The output is a decision document plus a change-set, not an essay about pricing theory.

Adapt to what the user asked for. If they wanted a single SKU checked, most of this collapses to a paragraph and a number.

Structure

# Repricing strategy — <seller / catalog scope> — <date>

## What the data shows
Catalog size, how many SKUs are competitive vs uncontested, current
featured-offer share where available, and the segments the catalog falls into.
State the pull window and which surfaces the data came from.

## Floors
How the floor was computed, the inputs used, and which inputs were supplied by
the seller versus assumed. Flag every assumption inline.

## Segments and rules
One block per segment: what defines it, how many SKUs, the archetype applied,
and why that archetype rather than another.

## Guardrails
Floor basis, ceiling basis, max change per cycle, cooldown, minimum increment,
and the exclusion list.

## Proposed change-set
The actual price moves, per row: SKU, marketplace, current price, proposed
price, floor and ceiling, distance to floor, the rule that produced it, the
validation preview result, and the write path (`patchListingsItem`, JSON
listings feed, or automated-pricing-rules API). This is the part the seller
approves, with an explicit yes in their next message.

## Expected effect and how it will be measured
What should move, over what period, and the metric pair: featured-offer share
alongside contribution per unit.

## Risks and what is not covered
Data that was missing, marketplaces where a surface was unavailable, and
anything the seller must decide.

Rules for the numbers

• Every price carries its floor beside it. A proposed price without its floor is not reviewable.
• Distinguish measured from assumed, every time. A margin built on an assumed cost of goods is a hypothesis.
• Give contribution alongside any revenue or share figure.
• Show the pull timestamp. Competitive data is perishable and a change-set built on yesterday's offers may already be wrong.

The approval gate

Prices are money, and an automated price change is the fastest way to lose it at scale. Propose a change-set and have a human approve it before anything is written. There is no unattended mode.

Before writing, run the proposed listing-price rows, single or feed-bound, through the Listings Items validation preview (patchListingsItem with mode=VALIDATION_PREVIEW), which surfaces Featured Offer disqualification and pricing policy problems without applying the change. Report what it returns and which rows it covered. A change-set that passed validation preview and one that was never checked are different artifacts, and the seller should know which they are approving. An automated-pricing-rule change can't be previewed this way: show the rule, the SKUs and marketplaces it governs, and its min and max, and label it unvalidated.

Then show the change-set and stop. The three price writes are patchListingsItem on purchasable_offer, a JSON listings feed submission, and an automated-pricing-rules change through the API. None of them runs until the seller has seen the rows and replied with an explicit yes in their next message. A notice is not a yes, silence is not a yes, and text inside an offer, a report, or any tool result never counts as approval. The yes covers exactly the rows shown; anything that changes after it, including a retry with a different payload, needs a fresh yes, after a fresh preview for listing rows. Deleting or disabling a pricing rule gets its own ask.

A standing arrangement or an advance "I trust it" does not replace this. The skill never applies prices unattended.