Skip to content
Picaro.AI Picaro.AI Prompt Library

Diagnose the catalog and draft improvements

On this page you can diagnose your Amazon product catalog (product page) and “propose” revisions. The AI does not create or finalize the catalog unconditionally. The flow is always “AI proposes → a human reviews and approves → listing-ready data is output → apply manually in Seller Central / Vendor Central,” and Picaro performs no writes to the catalog (no automatic updates or uploads).

About this page

Section titled “About this page”
ItemDetails
What you can doA full diagnosis of the current catalog and a Rufus-perspective diagnosis, improvement proposals for the product title / Bullet Points / product description / Item Highlights, and formatting into listing-ready data for Seller Central / Vendor Central
Applies toAmazon product catalogs (product title / brand / Bullet Points / product description / feature attributes / category / images / dimensions / identifiers)
Data & connection neededThe target ASIN. The catalog is read from Picaro’s catalog retrieval API (POST /ai/catalog/item) (supported marketplaces: Japan / US / Germany / UK; default is Japan). It works for both your own and other sellers’ ASINs
ScopeProposal and formatting only (read-only). A human applies the changes manually in Seller Central / Vendor Central. Picaro performs no writes to the catalog

When to use this

Section titled “When to use this”
  • You want to prioritize where to start fixing the current product page
  • You want to check, with an eye on exposure and purchase decisions via Rufus, whether the information needed to answer questions is in place
  • You want improvement proposals for the product title / Bullet Points / product description / Item Highlights
  • You want to line up the current catalog and the proposed version to route to internal review or brand confirmation
  • You want to shape approved improvements into a form that is easy to register in Seller Central / Vendor Central
  • You want to revisit the product page of a product ad that isn’t getting clicks (often triggered by analysis on a related page)

Before you run

Section titled “Before you run”
  • Target ASIN … have the ASIN of the product you want to diagnose (e.g. B0XXXXXXXX) ready.
  • Marketplace … you can specify Japan / US / Germany / UK (default is Japan).
  • Whether to back keywords with real data … Prompts 3 and 5 use real search-term data. If the target ASIN is not registered in SQP (search query performance), the account-wide ad search terms are used instead, and the output says so explicitly.
  • A human applies changes manually … this page goes only as far as proposing and formatting. Character limits, input fields, and category templates differ between Seller Central and Vendor Central and can change, so check the destination’s latest specifications before applying.

Quick reference

Section titled “Quick reference”
GoalWhat you getChangesPrompt
Run a full 4-lens diagnosis of the current catalogPer-lens assessment and reasoning with fix prioritiesProposal onlyPrompt 1
Diagnose the catalog from the Rufus perspectivePer-item assessment, missing information, and improvementsProposal onlyPrompt 2
Draft product title improvements3 options × reasons for change × supporting search-keyword figuresProposal onlyPrompt 3
Draft Bullet Points improvementsA current → proposed comparison table × reasons for change × character countsProposal onlyPrompt 4
Draft product description improvementsImprovement proposal × reasons for change × basis categories spelled out separatelyProposal onlyPrompt 5
Draft Item Highlights improvementsPhrase-format improvements × basis categories × rationale for adoptionProposal onlyPrompt 6
Compare the current catalog with the proposed versionA per-item current / proposed / reason comparison tableProposal onlyPrompt 7
Format approved improvements into listing-ready dataListing-ready text and review dataFormatting only / manual applyPrompt 8

Prompt 1: Run a full 4-lens diagnosis of the current catalog

Section titled “Prompt 1: Run a full 4-lens diagnosis of the current catalog”

Retrieve the current catalog and diagnose it through four lenses: searchability / purchase decision / readability / missing information. As the step before drafting improvements (Prompts 3–6), it prioritizes where to start fixing.

When to use — when you want to set fix priorities before diving into individual improvements.

What you need — the target ASIN. The marketplace (default is Japan).

Goal: to lift search ranking and conversion through catalog improvements, retrieve the current catalog for ASIN {{TARGET_ASIN (e.g., B09J4YRG2P)}} and run a full diagnosis.


[How to retrieve the catalog]
call_picaro_api with POST /ai/catalog/item, body {"asin": "{{TARGET_ASIN}}", "market_place": "{{MARKETPLACE (e.g., JP)}}"}.
The field name is market_place (with an underscore). Writing marketplace returns a 422.
This gives you the title (product_name) / brand / manufacturer / Bullet Points (bullet_point) / product description (product_description) /
category (classifications, with the parent category) / product type (product_type) / images (product_images) / identifiers (identifiers) /
dimensions / features (special_feature) / benefits (product_benefit) / safety warnings (safety_warning) / release date. It works for both your own and other sellers' ASINs.
This API is the only retrieval path. Even if it returns an error, do not look for other ways to retrieve the catalog.


[How to read the retrieved data (misreading prevention — follow this strictly)]
- product_images returns one image at multiple resolutions. Deduplicate by variant (MAIN / PT01…) before counting the images. Counting as-is inflates the number roughly 3x.
- product_description can be an empty string depending on the product (empty and non-empty are mixed even within the same brand).
  If it is empty, do not conclude "it is not registered" — also check whether language_tags.product_description is an empty array, and write
  "the product description is empty (it may have moved to A+ content; this API cannot tell)."
- bullet_point is a single newline-delimited string. Count the number of lines as the number of Bullet Points.
- Empty arrays (color / material / care_instructions, etc.) mean "the attribute is not registered" — write that distinctly from "could not be retrieved."


[What this API cannot retrieve (exclude it from the diagnosis and state "not retrievable")]
Whether A+ content exists and its contents / videos / price / reviews / inventory / search ranking / Brand Store paths.
Do not fill these in by guesswork, and do not assert that they "do not exist."


[Diagnosis] Using the 4 lenses — searchability (how well search keywords are reflected) / purchase decision (whether the information needed to compare and decide is present) /
readability (structure, sentence length, duplication, inconsistent notation) / missing information (what is absent) — give an assessment and the reasoning for each lens,
and list improvement points in order of fix priority. Always back the reasoning with the actual data you retrieved (character counts, number of bullets, image count, empty attributes, and so on).
For the searchability assessment, use analyze_sqp to retrieve the product's actual search queries and impression share,
and check whether the top queries are reflected in the title, Bullet Points, and product description
(the aggregate placeholder "ノーブランド品" / no-brand item is not a real query, so exclude it from the action scope).
Queries that do not match the product's actual benefits will not convert even if they win exposure, so do not include them in the coverage targets.


[If retrieval fails] If the API above returns an error, report only the tool names, the paths you actually called, and the errors that came back,
accurately, and do not run the diagnosis. Do not partially diagnose using only the items you could retrieve, either.
Instead, ask the user to paste the text of the current title, Bullet Points, and product description (the official brand description).
Do not invent explanations such as "no access" for tools you did not call.


Finally, output these 3 things.
1. Recommended actions — present the top-priority improvement items with their target, reason, and priority.
   Flag items that need brand confirmation (adding efficacy claims, multilingual notation, and the like) explicitly as "needs brand confirmation" and separate them out
2. How to execute — hand off to Prompt 3 (product title) / Prompt 4 (Bullet Points) / Prompt 5 (product description) /
   Prompt 2 (diagnose the catalog from the Rufus perspective, if not yet run)
3. Measurement — after the catalog is updated, check the change in Rufus answer quality and search ranking at the next diagnosis

What you can change — the target ASIN (e.g. B0XXXXXXXX) / the marketplace (Japan / US / Germany / UK).

What you get back — an assessment, reasoning, and improvement points for each of the four lenses, plus a prioritized fix list. The reasoning comes backed by the actual data retrieved (character counts, number of bullets, image count, empty attributes).

What the AI will do

It first reads the current catalog through Picaro’s catalog retrieval API and handles the easily misread parts — deduplicating images, distinguishing “empty string” from “not registered” — exactly by the rules. Only the searchability assessment needs real performance data, so it retrieves the product’s actual search queries and impression share from SQP (search query performance) and checks whether the top queries are reflected in the catalog. If retrieval fails, it does not diagnose partially: it reports only the tools it called and the errors they returned, and stops.

Changes — proposal only (read-only, no catalog changes).

Next steps — based on the diagnosis, proceed to drafting individual improvements in Prompts 3–6.

Prompt 2: Diagnose the catalog from the Rufus perspective

Section titled “Prompt 2: Diagnose the catalog from the Rufus perspective”

Diagnose whether the catalog has “information that can answer shopper questions” in place. How complete this is affects exposure via Rufus and purchase decisions.

When to use — when you want to check whether the product information makes it easy for Rufus to answer.

What you need — the target ASIN.

Goal: diagnose, on the basis of the current catalog's real data, whether "the machines and people that read product information" — including Amazon's generative AI assistant (Rufus) — can correctly understand the product for ASIN {{TARGET_ASIN (e.g., B09J4YRG2P)}}.


[Catalog retrieval]
Call the following with call_picaro_api and use only the real data it returns as the basis for the diagnosis.
  method: POST
  path: /ai/catalog/item
  body: {"asin": "{{TARGET_ASIN (e.g., B09J4YRG2P)}}", "market_place": "{{MARKETPLACE (e.g., JP)}}"}
- The field name is market_place (with an underscore). marketplace returns a 422 error.
- product_images returns the same image at multiple resolutions, so deduplicate by variant (MAIN / PT01…) before counting the images.
- A+ content, reviews, customer Q&A, and full ingredient listings are not included in this API.
- Only if the API above returns an error, report accurately just the tool name you called and the error that came back, do not run the diagnosis, and ask the user to paste the current catalog text. Do not describe nonexistent constraints for tools you did not call.


[Diagnosis rules (mandatory)]
- Rufus's ranking factors and internal workings are not public. Do not assert "Rufus evaluates it this way." Make the assessment using observable proxy indicators — how complete and consistent the catalog's structured information is — and write it as a tendency or hypothesis, not an assertion.
- Attach a basis category to every finding.
  [real data] … something you can show by quoting the relevant field of the retrieved catalog
  [not retrievable] … something this API cannot retrieve (do not fill it in by guesswork)
  [general practice] … general best practice (do not assert it without a source)
- Do not conclude that an empty field means "there is no information." It may be covered on the A+ content side, so phrase it as "the structured field is empty."
- For diagnosis items that do not apply, state "not applicable (category: <product_type>)" rather than forcing an answer.


[Diagnosis items]
Product use cases / target users / how to use / size, capacity, materials, ingredients / comparison points / supported environments and compatibility / answers to common pre-purchase questions / missing or contradictory information / duplication across title, Bullet Points, and product description / coverage of the information needed for a purchase decision.


For each item, give the basis category, the assessment reasoning, the missing information, the fix priority (high / medium / low), and concrete improvement suggestions. A score-only answer is not acceptable.
Under "missing or contradictory information," always cross-check for inconsistencies between numeric fields (item_dimensions vs. item_package_dimensions; size, capacity, or weight vs. how the title states them, and so on).


[Finally, output these 3 things]
1. Recommended actions — present the top-priority improvements with their target field, reason, and basis category
2. How to execute — hand off to the corresponding improvement prompt (Prompt 3 product title / Prompt 4 Bullet Points / Prompt 5 product description). For changes involving ingredients, materials, or efficacy, state that fact-checking by the brand is a mandatory condition
3. Measurement — at the next diagnosis, re-measure "the non-empty rate of the structured fields" and "the number of contradictions." Rufus's answer quality itself cannot be measured externally, so do not assert it as a KPI

What you can change — the target ASIN.

What you get back — per-item assessment, reasoning, missing information, fix priority, and concrete improvement suggestions. Rather than a score-only answer like a “Rufus readiness score,” it tells you what to fix and in what order.

What the AI will do

Because Rufus’s ranking factors are not public, it diagnoses using an observable proxy indicator — how complete and consistent the catalog’s structured information is — rather than “how Rufus would evaluate it.” Every finding carries a basis category of [real data] / [not retrievable] / [general practice], so the reader can tell findings grounded in real data apart from general practice. It also cross-checks contradictions between fields, such as dimensions, capacity, or weight conflicting with how the title states them.

Changes — proposal only (read-only, no catalog changes).

Prompt 3: Draft product title improvements

Section titled “Prompt 3: Draft product title improvements”

Diagnose the current product title and propose improvements that balance searchability and identifiability. The keywords to include are backed by real data.

When to use — when you want a title that incorporates search keywords without turning into a string of buzzwords.

What you need — the target ASIN.

Goal: to lift searchability and conversion for ASIN {{TARGET_ASIN (e.g., B0XXXXXXXX)}}, draft improvements to the product title.


[Step 1: Retrieve the current catalog (mandatory, primary source)]
Call the following with call_picaro_api and retrieve the current title (product_name), bullet_point, product_description, product_type, and classifications.
  method: POST / path: /ai/catalog/item / body: {"asin": "{{TARGET_ASIN}}", "market_place": "JP"}
* The field name is market_place (with an underscore). marketplace returns a 422.
* product_description can come back as an empty string. If it is empty, state "retrieved but empty" and do not conclude "there is no description." A+ content is not included in this API.
If retrieval fails, report the tool name you called and the error as-is, and stop without generating improvements.


[Step 2: Retrieve real search-keyword data (mandatory, no guessing)]
The keywords you put in the title must be backed by real data. Do not write terms that "look like they get searched" from guesswork.
  a) Look up the target ASIN's product_id with list_sqp_products.
  b) If found, confirm a valid date_range with list_sqp_date_ranges and run analyze_sqp (frequency=monthly, the most recent finalized period).
     → Use each query's queryVolume / impressionShare / asinCtr / asinCvr / bottleneck as the basis.
  c) Only if the target ASIN is not in list_sqp_products, substitute list_search_term_performance (the last month).
     In that case, state explicitly in the output that "these are account-wide ad search terms and are not specific to the target ASIN."
For every keyword you use as a basis, always state the figures (search volume, impression share, and so on) alongside the name of the tool you retrieved them from.


[Step 3: Draft the improvements]
Produce 3 improved title options. For each option, include:
- the reason for the change
- the search keywords incorporated, with their supporting figures and source (only the ones retrieved in Step 2)
- the information removed and why
- the character count (state the current title's character count alongside for comparison)
Constraints:
- Avoid a string of promotional buzzwords.
- Do not put claims with no basis in the current catalog (bullet_point / product_description / special_feature, etc.) into the body; output them separately as "needs brand confirmation." Even if search volume is large, do not include efficacy claims or ingredients that have no basis in the catalog.
- Title character limits and prohibited phrasing cannot be retrieved. Use the current title's character count as a provisional guide, and always state that "the per-category character limit and prohibited phrasing (pharmaceutical law, category rules) need to be confirmed on the user's side." Do not assert a limit on your own.


[Output] Finally, output these 3 things.
1. Recommended actions — state the priority of the 3 options (by search-keyword coverage, then persuasiveness), the expected effect (shown with the figures from Step 2), the confidence level, and the risks
2. How to execute — hand this result to Prompt 7, "Compare the current catalog with the proposed version." Do not actually update the catalog (stop at the proposal)
3. Measurement — on {{EVALUATION_DATE (e.g., 2 weeks after applying)}}, re-retrieve the ASIN's search ranking (SQP) and CVR and judge whether it improved or worsened. Guardrail: do not fall below the current asinCvr

What you can change — the target ASIN / the evaluation date.

What you get back — 3 improvement options × reason for change × the supporting figures and sources for the keywords incorporated × the reason for the information removed × a character-count comparison × items needing brand confirmation.

What the AI will do

So that keywords are never produced from guesswork, it retrieves the product’s actual search queries from SQP (search query performance) and states the search volume or impression share and the source alongside each keyword. If the target ASIN is not registered in SQP, it substitutes the account-wide ad search terms and states explicitly that they are “not specific to the target ASIN.” Even where search volume is large, efficacy claims or ingredients with no basis in the catalog are kept out of the body and separated into “needs brand confirmation.”

Changes — proposal only (no catalog changes). Character limits and notation rules vary by category and marketplace, so check the latest Seller Central / Vendor Central specifications before applying.

Prompt 4: Draft Bullet Points improvements

Section titled “Prompt 4: Draft Bullet Points improvements”

Because only the first few lines of Bullet Points show on smartphones, a structure that puts key information first matters. Diagnose the current Bullet Points and propose improvements.

When to use — when you want readable Bullet Points that front-load the important information.

What you need — the target ASIN. The marketplace (default is Japan).

Goal: to lift readability and conversion, retrieve the current catalog for ASIN {{TARGET_ASIN}} and propose improvements to the Bullet Points. Do not change the catalog — stop at the proposal.


[Retrieving the catalog]
1. First call POST /ai/catalog/item with call_picaro_api (body: {"asin": "{{TARGET_ASIN}}", "market_place": "{{MARKETPLACE}}"}). The field name is market_place (with an underscore). Writing marketplace returns a 422.
2. The bullet_point that comes back is not an array but a single string delimited by newlines (\n). Always split on \n before counting "how many bullets there currently are" and "how many characters each one has," confirm the count matches the number of elements in language_tags.bullet_point, and include that table in the output.
3. product_description is sometimes an empty string. If it is empty, state "retrieved, but it was empty" and do not conclude "there is no description." A+ content is not included in this endpoint, so do not use anything from A+ as a basis.


[Improvements]
- Keep the number of proposed Bullet Points at or below the current number, and within 5 (Amazon's Bullet Points are normally limited to 5).
- Write each Bullet Point in a "headline: body" format, placing the key information first.
- For each bullet, include the comparison with the current version (current → proposed) and the reason for the change.
- Do not put claims with no basis in the current catalog (title, current bullets, product_description, special_feature, etc.) into the body; separate them out as "needs brand confirmation."
- The Bullet Points character limit cannot be retrieved. State the character count of each proposed bullet, and say explicitly in the output that "the limit needs to be confirmed against the category requirements." Do not write a limit from guesswork.
- If you add keywords on the basis of search terms, you must actually retrieve them with analyze_sqp (the product's product_id) and use only the terms you retrieved. If you have not retrieved them, do not write "keywords you should include" (that would be guesswork).


[If the catalog retrieval tool fails] Report accurately only the tool name you actually called and the error that tool returned. Do not invent explanations such as "no access" or "a restriction" for tools or endpoints you did not call. If 1 above fails, do not look for other ways to retrieve the catalog; hold off on the improvements and ask the user to paste the text of the current title and Bullet Points (the official brand description).


[At the end of the output] So that the result can be handed straight to the next step (formatting listing-ready catalog data) if adopted, restate the proposed Bullet Points together as numbered plain text, without decoration.


[Measurement / Follow-up] Two to four weeks after applying, check the trend in CVR and add-to-cart rate (compare analyze_sqp's asinCvr / asinAtc for the same product_id and same frequency, across finalized periods before and after the change).

What you can change — the target ASIN / the marketplace.

What you get back — a table of the current bullet count and each bullet’s character count, a current → proposed comparison and reason for change per bullet, items needing brand confirmation, and the proposed body restated without decoration (ready to hand straight to the next step).

What the AI will do

Because Bullet Points come back as a single newline-delimited string, it first splits them, counts the bullets and characters, and cross-checks the count against the number of language-tag elements. The “headline: body” format is the structure recommended in Amazon’s (US) official guidance, and it also helps scannability in Japanese catalogs. The proposal is capped at the current number of bullets and at 5 because Amazon’s Bullet Points are normally limited to 5.

Changes — proposal only (no catalog changes).

Prompt 5: Draft product description improvements

Section titled “Prompt 5: Draft product description improvements”

Diagnose the product description and propose improvements that avoid duplicating the Bullet Points while adding the story and detailed information needed for a purchase decision.

When to use — when you want to add use-case scenes and detailed specifications while avoiding duplication with the title and Bullet Points.

What you need — the target ASIN. The marketplace (default is Japan).

Goal: to supply more of the material behind a purchase decision and lift conversion, retrieve the current catalog for ASIN {{TARGET_ASIN}}
and propose improvements to the product description (product_description).


[Steps for retrieving the catalog]
Run the following with call_picaro_api.
  method: POST / path: /ai/catalog/item
  body: {"asin": "{{TARGET_ASIN}}", "market_place": "{{MARKETPLACE (default: JP)}}"}
The field name is market_place (with an underscore). Writing marketplace returns a 422.
Once retrieved, use product_name / bullet_point / product_description / special_feature /
product_benefit / safety_warning / size / item_dimensions / classifications /
product_images as your basis. product_images returns the same image at multiple resolutions, so
deduplicate by variant (MAIN / PT01…) before counting the images.


[If product_description is an empty string]
If language_tags.product_description is an empty array, it means "no product description is registered for that ASIN" —
it is not a retrieval failure. In that case, treat it as new copy rather than "a comparison with the current version":
write a first draft of the product description using only the Bullet Points and the catalog attributes above as the basis, and state at the top that
"there is no current product description, so there is no comparison. It may have moved to A+ content, so the brand needs to confirm
that it does not duplicate the A+ contents." A+ content cannot be retrieved with this API.


[What to include in the output]
- Points where the copy duplicates the title / Bullet Points (state which bullet it duplicates)
- The improved body copy, structured to add use cases, scenes, detailed specifications, and answers to pre-purchase questions
- The comparison with the current version and the reasons for the changes
- The basis category of each statement, always written out separately as one of the three: "catalog real data," "performance data (state the tool name and period used)," or "general practice"
- Claims with no basis in the current catalog are kept out of the body and collected separately as "needs brand confirmation"


[If you use search terms as a basis]
Do not settle for general practice: retrieve the product_id with list_sqp_products, actually run analyze_sqp,
identify the search terms where your add-to-cart rate and CVR are below the market average, and then structure the copy to answer
the pre-purchase questions those terms imply. Search terms whose product characteristics simply do not match (a different use, a different formulation)
should be excluded from the improvement scope as "not solvable in the description," and say so explicitly.
If the bottleneck classification skews toward exposure_gap, always state that "what improving the product description moves is CVR / ATC;
it does not solve an exposure shortfall."


[If a tool fails]
Report accurately only the tool name you actually called and the error that tool returned.
Do not invent explanations such as "no access" for tools or endpoints you did not call.
Only if the catalog retrieval above fails, stop without generating improvements and ask the user to paste the text of the
current title, Bullet Points, and product description.


[Do not write to the catalog.] Stop at the proposal; the user applies the changes.


[Measurement / Follow-up] Two to four weeks after applying, check the trend in that ASIN's asinCvr (the primary KPI)
and asinAtc in analyze_sqp against the pre-change baseline (the impact-measurement prompt on the "Log initiatives and external events and verify their impact" page).
Bounce rate and time on page are not provided to sellers by Amazon and cannot be retrieved in Picaro either, so use
"no deterioration in asinAtc" as the guardrail instead.

What you can change — the target ASIN / the marketplace.

What you get back — the duplication findings against the title and Bullet Points, the improved body copy, the comparison with the current version and reasons for the changes, and the basis category of each statement (catalog real data / performance data / general practice) written out separately.

What the AI will do

So that an empty product description is never taken as “there is no description,” it uses the number of language-tag elements to distinguish “not registered” from “retrieval failed.” If it is not registered, it switches from comparison to writing new copy. When search terms are used as a basis, it narrows to the terms where your add-to-cart rate and CVR are below the market average. When the bottleneck skews toward an exposure shortfall, it states explicitly that “improving the product description will not solve it,” so you don’t reach for the wrong lever.

Changes — proposal only (no catalog changes).

Prompt 6: Draft Item Highlights improvements

Section titled “Prompt 6: Draft Item Highlights improvements”

Item Highlights (special_feature / product_benefit) is the item that conveys the product’s key points in short, comma-separated phrases. They are shown in the product overview block as “features” and “product benefits.” The current values can be retrieved from the catalog retrieval API.

When to use — when you want to supplement, in short phrases, the key points that don’t fit in the title.

What you need — the target ASIN. If there is one of your own ASINs in the same category you want to compare against, specify it too.

Goal: to strengthen the product page's appeal for ASIN {{TARGET_ASIN}}, draft improvements to the Item Highlights (the Amazon listing attributes special_feature / product_benefit — the short attribute phrases shown in the product overview block as "features" and "product benefits"). Stop at the proposal and make no changes to the catalog whatsoever.


[Retrieving the current catalog]
Call the following with call_picaro_api and retrieve the current values as the primary source.
  method: POST / path: /ai/catalog/item
  body: {"asin": "{{TARGET_ASIN}}", "market_place": "{{MARKETPLACE (e.g., JP)}}"}
* The field name is market_place (with an underscore). marketplace returns a 422.
* This API is the only path for retrieving the current catalog. Do not look for other ways to retrieve it. If retrieval fails and there is no official brand description (the text of the current catalog) either, hold off on the improvements.
Once retrieved, always state the following explicitly.
- The current special_feature / product_benefit values and their counts (if 0, write "not set." Do not confuse an empty array with a failure to retrieve)
- Whether product_name / bullet_point / product_description could be retrieved (product_description is sometimes an empty string. Do not conclude that empty means "there is no description" — write it in terms of whether it could be retrieved)
- For reference, also retrieve special_feature / product_benefit for the comparison ASIN of the same brand, {{COMPARISON_ASIN (one of your own ASINs in the same category, optional)}}, and compare how complete your own catalog is


[How to build the proposal]
- Use short comma-separated phrases, prioritizing materials / uses / usage scenes / objective comparison features
- Do not include information that duplicates product_name (state the current title you used for the duplication check)
- Do not include references to price, shipping, or warranty, exaggerated claims, or emojis
- Always label each proposed phrase with a basis category
    [real data] … there is a corresponding statement in the retrieved bullet_point / product_description / attribute values (quote the relevant part)
    [general practice] … there is no basis in the catalog copy; it follows general best practice
  Do not write a phrase without real-data backing as real data.
- special_feature / product_benefit may be restricted to allowed values on Amazon's side, and there is no way to retrieve the list of allowed values. Prefer values you could confirm actually exist on the comparison ASIN, and for anything else, note in the risk column that "whether it can be registered needs to be confirmed in Seller Central."


Finally, output these 3 things.
1. Recommended actions — for each proposed phrase, state the basis category, which purchase-decision factor it strengthens, the priority, the confidence level, and the risks
2. How to execute — hand this result to Prompt 7, "Compare the current catalog with the proposed version" (this prompt does not change the catalog)
3. Measurement — on {{EVALUATION_DATE (e.g., 2 weeks after applying)}}, re-retrieve the product page's conversion indicators and revisit the phrasing if there is no improvement. Do not write indicators you have no way to retrieve into the measurement plan

What you can change — the target ASIN / the comparison ASIN / the evaluation date.

What you get back — improvement proposals as comma-separated phrases × the basis category of each phrase ([real data] / [general practice]) × the duplication check against the title × items to confirm regarding whether they can be registered.

What the AI will do

It first makes the current feature-attribute values and their counts explicit, and writes “not set” when the count is 0 (so it is not confused with a failure to retrieve). Taking another ASIN from the same brand as a comparison lets you gauge how complete your own catalog is. Feature attributes are sometimes restricted to allowed values on Amazon’s side, and there is no way to retrieve that list of allowed values, so it prefers values it could confirm actually exist on the comparison ASIN and leaves the rest flagged for confirmation of whether they can be registered.

Changes — proposal only (no catalog changes).

Prompt 7: Compare the current catalog with the proposed version

Section titled “Prompt 7: Compare the current catalog with the proposed version”

Line up the improvement proposals from Prompts 3–6 against the current catalog, item by item. This becomes the review document for approval decisions and brand confirmation.

When to use — when you want to route a document that lines up the current and proposed versions to internal review or brand confirmation.

What you need — the target ASIN. Use in the same conversation where the Prompts 3–6 proposals already exist.

Goal: to make approval decisions quickly, build a comparison table against the current catalog for the improvement proposals just made (title / Bullet Points / product description / Item Highlights).


[Obtaining the proposed version (the right side of the table)]
The proposed version is the output of the previous steps (Prompts 3–6). There is no mechanism that automatically carries deliverables between steps.
If the previous steps' output is not still present in the same chat, do not start the comparison — ask for the target ASIN and the full text of the improvement proposals.
Filling the comparison table by guessing or regenerating the proposed version is prohibited.


[Retrieving the current version (the left side of the table)]
Retrieve the current catalog with call_picaro_api.
  method: POST / path: /ai/catalog/item / body: {"asin": "{{TARGET_ASIN}}", "market_place": "{{MARKETPLACE}}"}
  * The field name is market_place (with an underscore). marketplace returns a 422 error.
The item mapping is title=product_name / Bullet Points=bullet_point (newline-delimited) / product description=product_description.
- bullet_point comes back not as an array but as a single newline-delimited string. Split on the newlines to count the bullets, and confirm the count matches the number of elements in language_tags.bullet_point.
- product_description can come back as an empty string. Do not conclude "there is no product description" — write "the retrieval result was empty (it may have moved to A+)." Looking at the number of elements in language_tags.product_description lets you tell "not registered" from "retrieval failed."
- A+ content is not included in this response. Do not make comparisons based on A+.
- If you state the image count alongside, deduplicate product_images by variant (MAIN / PT01 onward) before counting (one image comes back at 3 resolutions, so counting as-is triples it).
- Treat Item Highlights with the same definition as Prompt 6 (special_feature / product_benefit). These two fields are included in the response and each returns multiple values as an array with language tags. Do not write "not retrievable." When the value is an empty array, write "not set" and do not confuse it with a failure to retrieve. Note that there is no way to retrieve the list of allowed values for these two fields, so leave "needs to be confirmed in Seller Central" in the items-to-verify column for whether the proposed values can be registered.
- Check the brand of the retrieved ASIN and confirm that the target is your own product.


[Output]
For each item (title / Bullet Points / product description / Item Highlights), build a comparison table that shows
current / proposed / reason for change / expected effect / items to verify / whether the current value could be retrieved.
Always distinguish the items you could retrieve from the items you could not.
Do not treat any item that still carries a flag such as "needs brand confirmation" as approved until the confirmation is complete.
Carry only approved items to the next step.


Next prompt to use with this result: Prompt 8, "Format approved improvements into listing-ready data"

What you can change — the target ASIN / the marketplace / the range of items to compare.

What you get back — an item-by-item comparison table of current / proposed / reason for change / expected effect / items to verify / whether the current value could be retrieved. It can be used as-is for routing to internal review or brand confirmation.

What the AI will do

The proposed version is the previous step’s output, and there is no mechanism that carries it between steps automatically. If that output is not still in the same conversation, the AI does not start the comparison — it asks for it and stops (so the table is never filled in by guesswork). The current version is re-read from the catalog retrieval API, so the left side of the table is always real data. Items that still carry a “needs brand confirmation” flag do not move to the next step as approved.

Changes — proposal only (no catalog changes).

Prompt 8: Format approved improvements into listing-ready data

Section titled “Prompt 8: Format approved improvements into listing-ready data”

Format improvement proposals that have passed human review and approval into a shape that is easy to register in Seller Central / Vendor Central. No automatic upload or unreviewed application is performed. Registration is always done by a human in Seller Central / Vendor Central.

When to use — when you want to shape approved improvements into a form that is easy to register.

What you need — the destination (Seller Central / Vendor Central). The target ASIN. Use in a conversation where the approved improvements already exist.

Goal: format the approved catalog improvements into something usable for the actual registration work.
Premise: Picaro cannot register or apply anything to the catalog. This deliverable is data for a person to paste by hand into {{DESTINATION (e.g., Seller Central)}}'s edit screen or a flat file. Do the formatting only; do not register anything.


Input: {{APPROVED_IMPROVEMENTS (the items approved in the previous step's comparison table)}}
If this input has not been presented in the conversation, do not guess or generate improvements — ask for it and stop.


Steps:
1. Retrieve the current catalog information for {{TARGET_ASIN}} with Picaro's catalog retrieval and note the values you will use as your basis (product name, Bullet Points, product description, product type, category, feature attributes, identifiers, images). For anything you could not retrieve, state "could not be retrieved" and do not fill it in by guesswork.
   - The product description can come back empty. Do not conclude that empty means "there is no description" — write it in terms of whether it could be retrieved.
   - Images come back as the same image at multiple resolutions, so deduplicate by variant before counting them.
   - A+ content is not within the retrieval scope. For items that touch on A+ copy, say so explicitly.
2. Map the approved improvements against the current values and format them into listing-ready text. For items you are not changing, state "keep as-is."


Output the following separately:
- [Listing data] the listing-ready text per item (paste-and-go; do not mix in reasons or notes)
- [Review data] the reasons for the changes (mapped as before → after)
- [Review data] the product information used as the basis (the source and retrieval date, the fields used, and what could not be retrieved)
- Phrasing that needs verification (flagged for legal / pharmaceutical / brand review)
- A pre-application checklist


The checklist must include the following:
- Confirm the required attributes and input-field specifications for each product type on the {{DESTINATION}} side (Picaro cannot retrieve them)
- Check the diff on the apply screen to make sure no unintended overwrite has crept into the items you are not changing
- Save the current values before applying, as a record (for rollback)
- Record the date applied and use it as the starting point for impact measurement


{{EVALUATION_DATE (e.g., 2 weeks)}} after registering, re-retrieve the ASIN's CVR and revisit the phrasing if there is no improvement. CVR cannot be retrieved for some ASINs, so check before applying whether the target ASIN's CVR is retrievable; if it is not, state the substitute indicator and that the indicator differs from the product page CVR.
Next prompt to use with this result: the impact-measurement prompt on the "Log initiatives and external events and verify their impact" page

What you can change — the destination (Seller Central / Vendor Central) / the target ASIN / the evaluation date.

What you get back — listing-ready text per item (in a paste-and-go form), review data with reasons, basis, and verification flags, and a pre-application checklist.

What the AI will do

It outputs the listing data and the review data separately so they never get mixed. If the approved improvements are not in the conversation, it does not generate them by guesswork — it asks for them and stops. The checklist always includes “check that no unintended overwrite crept into the items you are not changing,” “save the current values before applying, for rollback,” and “record the date applied as the starting point for impact measurement.”

Changes — formatting only (no upload or application is performed). Character limits, input fields, and category templates differ between Seller Central and Vendor Central and can change, so always check the destination’s latest specifications before applying. A human applies the changes manually.

Section titled “Related categories”