Overview
The review inbox on the Agent page is where everything the agent produces waits. It is grouped by field, so all the Name proposals sit together, and each group can be filtered with All countries when it spans more than one market.
Nothing leaves the inbox on its own. This is the human gate in the workflow.
The inbox
Everything the agent produces arrives in a review inbox, grouped by market. Nothing leaves it on its own.
The inbox is the human gate in the workflow, and it is the only way agent output becomes a draft.
Reading a card
Each card shows what would change, from what to what, and why.
- Metadata cards show the current value beside the proposed one, with an explanation of the reasoning.
- Keyword cards are reviewed word by word: which terms are being added, which are being swapped, and which are being removed without a replacement.
- Screenshot cards show staged variants built from your real screenshots, not mockups of something you do not have.
- Event and product page cards carry the structured content that would go to the store as a draft.
Read the explanation, not just the diff. A keyword that looks strange in isolation often has a reason behind it, and a reason you disagree with is the most useful thing you can find in a review.
Applying and dismissing
Each card carries two controls, at the right-hand end of the row.
- Apply puts the proposed value into your Spek draft. It does not go to the store.
- Dismiss removes the card. Nothing changes anywhere, including your store listing.
There is no edit control on a card. To change the wording, apply it and then edit the field in the editor, where you can see it beside the rest of the listing and against its character limit.
The two arrows beside the Suggestions / Good switcher undo and redo the decisions you make in this session. Undoing an applied keyword row brings the evicted word back into the draft; undoing an applied card restores the value that was there before, unless you edited the field since. The card returns to the inbox, waiting for a fresh decision. Applies that created something on the store — a screenshot set, an event, a product page — cannot be undone this way.
When the indexed metadata review is complete, the inbox explains what happens next. While the approvals are still only a Spek draft, it asks you to publish before measurement starts. Once that metadata reaches the store, it shows a seven-day countdown while Spek measures rank movement.
Event and product page proposals can create a provider draft, but only through a dedicated action you trigger. Even then, the content is not submitted and not made live.
Stale cards
A card is a comparison against the values that existed when it was drafted. If the underlying field changed since, the card is stale, and accepting it would overwrite the newer value with an older comparison.
Spek flags that rather than applying it. Rebase the card onto the current values and review it again, or reject it and let the next run redraft from what is actually there now.
The same applies after you publish: the next run reads the published listing, so its proposals start from reality. See runs and what happens in one.
Common questions
Does applying a proposal publish it?
No. It updates your Spek draft. Publishing is a separate action in the Agent header or the editor, and it is governed by what the store currently allows.
Inspect the resulting text in the Editor for the same app and locale. You can revise the wording before the final send. When coordinating with teammates, describe this state as an accepted draft rather than a live listing update so the release decision remains clear.
Can I edit a proposal before applying it?
Not on the card. Apply it, then edit the field in the editor, where you can see it beside the rest of the listing and against its character limit.
Why is a card marked stale?
The underlying field changed after the card was drafted, so applying it would overwrite a newer value using an older comparison. Reject it and let the next run redraft from what is actually there.
What happens to a dismissed card?
It disappears and nothing changes. A later run may propose something similar if the research still supports it.
What should I check before applying a metadata proposal?
Check the selected app and locale, read both the current and proposed wording, and decide whether the proposed promise matches the product users will receive. Review the available keyword evidence together with brand and language requirements. A proposal's rationale helps explain the suggestion, but it is still your team's decision. After applying it, inspect the complete draft in the Editor because a field that reads well on its own can repeat another field or create an inconsistent message when the listing is read as a whole.
Can I accept only part of the suggested direction?
You can make decisions about the proposals presented in the inbox and continue editing accepted metadata in the Editor. Use that workflow when you agree with a keyword or product emphasis but want different wording. Keep the relevant character limit and other fields in view while editing. Applying a metadata proposal saves a draft; it does not mean the exact suggested sentence must become public. Review the final values in the publishing flow, where you can see the actual changes that are about to be sent.
How should reviewers handle unfamiliar localized wording?
Check the term's meaning in the selected storefront and ask someone who understands the language and product to review the complete sentence. A word that looks unfamiliar to the primary-market team can be appropriate locally, while a familiar translation can still describe the wrong user need. Read the proposal context and verify the promise against the app. If the wording remains unclear, keep the existing draft or edit the accepted text before publishing. An estimate attached to a keyword is not a substitute for language and product review.
What should I do if another teammate edited the same listing?
Refresh your understanding of the current draft and store values before making the next decision. A proposal may have been prepared against an earlier version of a field, while your teammate's edit reflects newer product context. Compare the wording in the Editor and read any changed-since-run or conflict message shown by the product. Agree on the desired final value and inspect it again before publishing. Do not treat an older proposal explanation as proof that a more recent edit should automatically be overwritten.