samber/developer-platform-skills已通過檢查
SKILL DETAIL
app-marketplace-listing-standards
samber/developer-platform-skills/app-marketplace-listing-standards
Write the listing-content rulebook for the operator of a B2B SaaS app marketplace - the standard every third-party listing must meet, covering required fields with objective reject criteria, screenshot and video specs, description quality bars, category taxonomy design, localization posture, badge display rules, and staleness/decay enforcement. Use whenever the user mentions listing standards, a listing rubric or marketplace quality bar, screenshot or media requirements, marketplace categories, rejection criteria, or delisting stale listings - even if they never say "listing standards". Operator side only. Do NOT use for optimizing a vendor's own listing - use samber/developer-platform-skills@integration-listing-optimization instead.
安裝量 · 333查看來源
Installation
npx skills add https://github.com/samber/developer-platform-skills --skill app-marketplace-listing-standards
技能檔案
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "app-marketplace-listing-standards",
"evals": [
{
"id": 1,
"prompt": "I run platform partnerships at Loomside, a workflow automation SaaS. We're opening our integrations directory to third-party vendors in March and I need the media requirements page written. Our installs get approved by customer IT admins before anyone on their team can add an app, and two of our largest accounts run a formal vendor-review committee. We'll take screenshots, an icon, and an optional demo video. Just give me the standard screenshot dimensions and the standard video length everybody uses so we're consistent with the rest of the industry.",
"expected_output": "A media-spec section that refuses to supply an industry-standard geometry, picks and publishes one geometry per asset type for Loomside, sets a short function-proof video ceiling justified by the admin/committee evaluation mode, and adds content and accessibility rules on top of the pixel rules.",
"files": [],
"expectations": [
"States explicitly that no industry-standard screenshot geometry exists across app marketplaces",
"Names at least two mutually incompatible screenshot aspect ratios in production use (for example 16:9 and 8:5, or approximately 3:2)",
"Instructs Loomside to pick its own geometry and publish it rather than adopting a borrowed number as an industry constant",
"Specifies exactly one published geometry per visual asset type, not a menu of acceptable alternatives presented as equally valid",
"Sets the demo-video ceiling at roughly 30 seconds, justified by the admin and committee evaluation mode rather than by a market average",
"Bans marketing or promotional footage in the video given the diligence-oriented buyer",
"Does not compute or recommend an average of other marketplaces' video ceilings",
"Requires captions on video",
"Requires at least one screenshot showing the actual application UI",
"Bans personally identifiable information in screenshots",
"Bans pricing claims or review and rating claims baked into screenshot images",
"Names an off-topic, distorted, or wrong-ratio image as an explicit rejection trigger the submitter can self-check before submitting",
"Recommends an accessibility floor covering descriptive alt text on informative images, captioned video, and contrast or legibility minimums, referencing WCAG 2.2 AA"
]
},
{
"id": 2,
"prompt": "Parcelwise is a shipping-ops platform and we're writing the content rules for our app directory. Two things I keep going back and forth on. First, a vendor just submitted under the name 'Parcelwise Label Printer' and I can't decide whether that's fine. Second, here are two candidate description openers from that same vendor - which one should the rulebook accept? (a) 'Our sync engine uses a persistent WebSocket channel to reconcile carrier manifests with sub-second latency.' (b) 'Know which shipments are stuck before your customers call you.' Also, the only support surface they gave us is a PDF on Google Drive, and their description quotes 'a warehouse manager in Ohio' saying we cut their costs 40%. Give me the description quality bar and the rejection triggers.",
"expected_output": "A description quality bar plus an enumerated rejection-trigger list that rejects the submitted app name on naming-order grounds, accepts opener (b) over (a) with the outcome-before-mechanism rule, flags the anonymous testimonial, and rejects the PDF as an off-listing trust surface.",
"files": [],
"expectations": [
"Rejects the app name 'Parcelwise Label Printer' on trademark naming-order grounds",
"States the accepted naming shape as the descriptor first and the platform name after (for example 'Label Printer for Parcelwise'), and gives the rejected mirror form",
"Accepts option (b) and rejects option (a) as the description opener",
"States the rule as leading with the customer outcome rather than the feature's technical mechanism, and connecting each feature claim to a measurable result",
"Names keyword spam as a rejection trigger defined numerically - a stated repetition count, or lists of brands, sites, or regions adding no value - never as an unquantified 'do not stuff keywords'",
"Names unattributed or anonymous testimonials as their own rejection trigger",
"Flags the 'a warehouse manager in Ohio' quote specifically as failing attribution",
"Rejects the PDF as a valid landing or support surface, stating that a PDF or a code repository does not satisfy the requirement",
"Requires a publicly accessible landing page reachable without login",
"Requires a support channel with a stated response-time commitment",
"Requires a privacy policy meeting a stated minimum-coverage checklist covering data collected, use, retention, the access or deletion request process, and a real contact channel",
"States that these off-listing trust surfaces gate approval independently of how good the marketing copy is",
"Names misrepresentation, including undisclosed third-party account dependencies and their cost, as a content violation"
]
},
{
"id": 3,
"prompt": "Northsend's app directory has 340 listings and is growing fast. Vendors complain that nobody finds them, so the product team's plan is to let each vendor pick up to eight categories plus unlimited free-text tags so they turn up in more places. I'm not convinced. We also have roughly 40 listings whose category hasn't matched what the app actually does since we rewrote the taxonomy last year. Browsing is still how most buyers find apps, but search usage is climbing month over month. What taxonomy should we ship?",
"expected_output": "A capped taxonomy design that refuses the uncapped multi-select outright, sets a hard per-listing cap, resolves the 40 drifted listings with a staleness downgrade instead of delisting, and names the promotion paths to structured tags and to operator-curated layers with their conditions.",
"files": [],
"expectations": [
"Rejects the unlimited free-text tag proposal outright rather than keeping it as a lower-ranked option to cap later",
"Gives the reason: an uncapped multi-select degenerates into every listing claiming every plausible tag until categories stop discriminating",
"Rejects the eight-category self-selection and recommends a hard per-listing cap of roughly one or two categories",
"Recommends a small fixed cross-functional category list rather than a vendor-extensible one",
"Handles the 40 drifted listings with a staleness downgrade - marking them uncategorized and dropping them off browse and filter surfaces - rather than delisting them",
"Describes that downgrade as soft, self-correcting because the vendor can fix it at any time, and automatable",
"Offers structured tags layered on top of categories as the promotion path once search overtakes browsing as the discovery route",
"Caps those tags and requires one idea per search term",
"Names operator-curated layers such as editorial collections, 'works with' labels, or persona groupings as the high-discovery-value, high-standing-effort option that loses the efficiency ranking",
"States the condition that promotes curated layers anyway: a compounding mandate and a catalog that has outgrown browsing",
"States that curated placement must never be purchasable, because sellable curation stops being a discovery signal and becomes ad inventory"
]
},
{
"id": 4,
"prompt": "Cadenza is an HR platform with a partner app directory, about 600 listings. An audit found 41% carry at least one dead link or a screenshot from a UI we shipped over two years ago. Leadership's take is that we already charge partners a $200 annual listing fee, so they have skin in the game and this should sort itself out. Separately: we cut a new platform API version every six months and deprecate the old one on a published schedule. Design the staleness policy - and I really don't want to delist a third of the catalog in one go.",
"expected_output": "A decay-enforcement policy that removes the listing fee from the freshness mechanism entirely, promotes version-currency enforcement because Cadenza ships versioned releases, stacks a staleness downgrade underneath, and phases in with a notice runway rather than a mass delisting.",
"files": [],
"expectations": [
"Rejects the annual listing fee as a freshness mechanism",
"Gives the reason: a fee renews the billing relationship, not the listing content, and nothing about paying it checks a stale screenshot",
"Assigns listing fees to marketplace monetization and revenue design rather than to the decay policy",
"Recommends version-currency enforcement as the strongest available rung, explicitly because Cadenza already ships versioned releases with scheduled deprecations",
"States that the platform's own release cadence performs the freshness detection, which is what makes this rung affordable for Cadenza specifically",
"Includes a stated migration window for existing listings rather than immediate enforcement against already-listed apps",
"Rejects new submissions built on unsupported platform versions",
"Puts a staleness downgrade in place as the always-on floor beneath whatever policy runs, with a browse-surface consequence rather than removal",
"Names 'out-of-date listing content' as an explicit, rejectable violation in the published policy",
"Adds an operator-side calendar review sweep aligned to Cadenza's own release cycle",
"States that no benchmarked marketplace operator publishes a hard numeric update-or-be-removed cadence",
"Labels any cited 12-month auto-removal rule as coming from an adjacent marketplace ecosystem and treats it as an internal worst-case freshness SLA rather than an external requirement",
"Avoids recommending a mass delisting of the 41%",
"Requires a notice runway before any new content requirement takes effect on already-listed apps, on the grounds that retroactive enforcement without runway burns the partner trust the standard exists to build"
]
},
{
"id": 5,
"prompt": "Tidewell runs an app marketplace for field-service software. Marketing wants 'Certified Listings' on the homepage and is asking me which certification body we should get audited by - ISO or something equivalent - so the claim holds up. We do run our own security review that awards a badge, and we're debating whether to also hand vendors a badge they can put on their own websites. Where should all of this show up on a listing, and what do we do when a vendor's badge lapses?",
"expected_output": "A refusal of the external-certification claim with the compositional alternative, plus badge display rules: a dedicated trust surface separate from marketing copy, a written currency rule with a grace period, the inline chip as complement, and a brand-usage rulebook for the off-marketplace badge.",
"files": [],
"expectations": [
"States that no ISO, IAB, or equivalent external body certifies marketplace listing quality",
"Refuses the 'Certified Listings' claim as written, because it implies an external certification that does not exist",
"Offers the compositional alternative naming three components and naming it as Tidewell's own program: WCAG for accessibility, recognized security attestations for security posture, and Tidewell's own published rubric for content",
"Separates badge eligibility from badge display, assigning eligibility to the app-review process and display to the listing rulebook",
"Recommends a dedicated trust surface - a listing tab or section physically separate from the marketing copy",
"Specifies what that surface carries: data-storage location, earned badges, and compliance certifications",
"Pairs it with a written currency rule: a lapsed badge comes down, with a stated grace period",
"Describes an inline badge chip in search results as a complement to the trust surface rather than a substitute, because it asserts trust without the substantiating detail a diligence buyer needs",
"Names renewal-linked display automation - display wired to eligibility data so a lapsed badge disappears without human intervention - as the highest-effort option that loses the efficiency ranking",
"States the condition that promotes it: badges carrying quantitative, lapsable thresholds on a renewal cycle",
"Classifies the vendor-embeddable off-marketplace badge as marketing reach rather than listing trust",
"Requires a brand-usage rulebook for that badge covering use-as-provided, minimum clear space, size parity with competing badges, and a mandatory link back to the listing",
"Notes that running no badge program at all is a legitimate architecture rather than an oversight"
]
},
{
"id": 6,
"prompt": "Halyard's marketplace is English-only today. We're opening sales offices in Japan, Germany and Brazil next year and the catalog has to follow. We already run a machine-translation pipeline in-house for our product docs, so spinning it up for listings is basically free for us. Our enterprise buyers in Japan have twice asked whether an app 'supports Japanese' before signing. What localization posture should the rulebook take?",
"expected_output": "A localization posture that promotes auto-translate with vendor override because Halyard already owns the pipeline, states the trust cost, and separately handles the Japanese enterprise language-capability question with the all-or-nothing declaration.",
"files": [],
"expectations": [
"Recommends auto-translate with vendor override as the posture, explicitly because Halyard already owns the machine-translation pipeline",
"Names which piece of context moved the ranking - the already-owned asset re-ranking the menu - rather than presenting the default as fixed",
"States the trust cost of machine translation plainly: the output carries the operator's own name",
"Requires a documented path for a vendor to replace any single language's translation",
"Warns that removing an override reverts that field to machine output",
"Names opt-in per market as the cheaper default posture that applies while only one primary market exists",
"Distinguishes a translated listing page from a runtime language-capability claim",
"Recommends the all-or-nothing capability declaration for the Japanese enterprise buyers who treat language support as purchase-blocking, because it is the only posture where the listing's language claim is guaranteed true in the product",
"Notes that the all-or-nothing posture carries the highest vendor effort and the least listing reach, which is why it loses the efficiency ranking as a default",
"States that a region-locked posture should only be adopted together with region-based visibility gating, never on its own",
"Flags that visual and promotional assets may not localize alongside text fields, and instructs Halyard to check its own asset pipeline for that gap"
]
},
{
"id": 7,
"prompt": "Brightpier's marketplace has about 1,200 listings, all vendor-maintained, and three of us rotate content review. Our current rule sheet says listings must 'demonstrate clear value and establish trust with the buyer', plus four similar lines. Partners dispute maybe one rejection in five, usually arguing that another reviewer approved something identical - and honestly they're often right. We already built a partner submission console in-house last year. Rewrite the field rules.",
"expected_output": "A field-spec rewrite that deletes the principles-only rules rather than demoting them, promotes exact per-field limits because the catalog is vendor-self-maintained at volume, and promotes the normally starved completion-tracked console because Brightpier already owns one.",
"files": [],
"expectations": [
"Removes the principles-only rules such as 'demonstrate clear value and establish trust' from the rulebook rather than keeping them as a lower tier or fallback",
"Gives the reason: two reviewers reading the same principles reject different listings, and the gap surfaces as appeal noise",
"States that parking principles at the bottom instead of deleting them lets 'we'll use judgment' reappear as scope whenever writing a real trigger feels like work",
"Recommends exact per-field limits across the board, explicitly because the 1,200 listings are vendor-self-maintained at volume",
"States that consistency then depends on the spec rather than on which of the three reviewers reads the listing",
"Puts numeric caps at minimum on the load-bearing fields: app name, hook string, body, and media geometry",
"Enumerates named rejection triggers for the remaining fields, including misleading or out-of-date metadata, numerically defined keyword spam, and unattributed testimonials",
"Requires every trigger to be self-checkable by the submitter before submitting",
"Promotes the completion-tracked submission console - normally the starved, highest-effort option - because Brightpier already owns the console",
"Specifies shipping the rules as validation logic inside that existing console, with a completion floor that blocks publication",
"Names which piece of the user's context moved which rung",
"States the efficiency ordering explicitly rather than leaving it implied by the order the options are listed in",
"Recommends tracking the rejection-reason distribution, and reads a rising 'unclear content' share as spec ambiguity rather than submitter failure"
]
},
{
"id": 8,
"prompt": "Drafting the listing standards doc for Quillrock's marketplace. My draft currently has a section on auditing which OAuth scopes an app requests and when we force a re-review after an app update - security asked me to put it in the same document so partners only have one page to read. Separately, our search is ranked, and we want listings without a demo video to rank lower so vendors get the hint, but we'd rather not advertise that we're doing it. Sanity-check this before I publish.",
"expected_output": "A correction that moves the permission-audit and re-review material out to the review process with a cross-reference, and refuses the undisclosed ranking penalty, requiring it be published if used at all.",
"files": [],
"expectations": [
"Moves OAuth-scope and permission auditing out of the listing-content rulebook",
"Moves re-review-on-update triggers out of the listing-content rulebook",
"Assigns both to the app-review process and cross-references them instead of duplicating them",
"Gives the reason: content standards and safety gates kept in one document drift apart and contradict each other",
"States that content triggers fire independently of security and functionality - a blurry screenshot or a keyword-stuffed description is rejected regardless of whether the app is secure and works",
"Rejects the undisclosed ranking penalty",
"Requires the penalty to be published in the policy if Quillrock applies it at all",
"Gives the reason: an unannounced down-ranking reads as arbitrary once vendors discover it",
"Notes that a ranking-penalty lever presupposes ranked search infrastructure, which is why it loses the efficiency ranking as a general default, and names the condition that promotes it: an asset that should be encouraged rather than required",
"Requires a notice runway before the new ranking rule takes effect for already-listed apps"
]
},
{
"id": 9,
"prompt": "Before I take our new listing rulebook to Fernway's exec team, they want two things: a pass/fail bar that proves the rulebook is any good, and a number we can promise partners about how many listing views turn into trials. I found a marketplace-software vendor's page citing a 30% click-through from listing to free trial against a 2-3% baseline - can we commit to that? What should I put in the deck?",
"expected_output": "A refusal to promise the vendor-reported conversion figure, plus a set of self-set rulebook gates flagged as self-set and a list of operating KPIs.",
"files": [],
"expectations": [
"Refuses to commit to the 30% click-through figure as a target",
"Labels that figure as vendor-reported and unaudited, from a party that sells marketplace software and is therefore a motivated source",
"States that no industry pass-standard for a listing rulebook exists, and flags the gates it supplies as self-set",
"States that no external certification body exists to borrow a pass bar from",
"Supplies a gate requiring every required field to carry an objective reject criterion a submitter can self-check before submitting",
"Supplies a gate requiring exactly one published geometry per visual asset type",
"Supplies a gate requiring the taxonomy to carry a hard per-listing cap, an operator-curated layer, or both",
"Supplies a gate requiring every listing to have a decay trigger with a named owner and a stated consequence",
"Supplies a gate requiring every displayable badge to have a display location and a currency rule",
"Proposes operating KPIs including first-pass content-approval rate, listing completion rate, and the share of the catalog stale beyond the freshness SLA"
]
}
],
"trigger_queries": [
{
"query": "Write the listing requirements page for our app marketplace",
"should_trigger": true
},
{
"query": "What should our marketplace require in a third-party app listing?",
"should_trigger": true
},
{
"query": "We need a rubric our reviewers can use to reject listings consistently",
"should_trigger": true
},
{
"query": "Half the listings in our directory have outdated screenshots - what do we do about it?",
"should_trigger": true
},
{
"query": "How many categories should we let vendors pick for their app?",
"should_trigger": true
},
{
"query": "Our partners keep arguing about rejections because our content rules are too vague",
"should_trigger": true
},
{
"query": "What screenshot dimensions should we require from app submitters?",
"should_trigger": true
},
{
"query": "How long should we let vendors' demo videos run on our directory?",
"should_trigger": true
},
{
"query": "Design a staleness policy for our integrations directory",
"should_trigger": true
},
{
"query": "Can we advertise that our listings are industry-certified?",
"should_trigger": true
},
{
"query": "Where on a listing should a partner's security badge show up?",
"should_trigger": true
},
{
"query": "Should we auto-translate every app listing into all our supported languages?",
"should_trigger": true
},
{
"query": "A vendor submitted an app called 'Acme Invoice Sync' on our platform - is that name acceptable?",
"should_trigger": true
},
{
"query": "Our app directory has 400 entries and browsing it has become useless",
"should_trigger": true
},
{
"query": "What counts as keyword stuffing in an app description on our store?",
"should_trigger": true
},
{
"query": "We're opening our platform to third-party apps next quarter and need content rules",
"should_trigger": true
},
{
"query": "Write the quality bar for the descriptions vendors submit to our app store",
"should_trigger": true
},
{
"query": "Should we remove apps from our catalog that haven't been updated in a year?",
"should_trigger": true
},
{
"query": "How do other operators handle stale app listings in their catalog?",
"should_trigger": true
},
{
"query": "What makes a submitted app listing rejectable on content grounds?",
"should_trigger": true
},
{
"query": "Our reviewers disagree with each other constantly on listing approvals",
"should_trigger": true
},
{
"query": "We need a content policy for our partner directory",
"should_trigger": true
},
{
"query": "Should we require a privacy policy link on every listing we publish?",
"should_trigger": true
},
{
"query": "Is a PDF acceptable as a vendor's landing page for their listing with us?",
"should_trigger": true
},
{
"query": "How should we cap tags so search still returns something meaningful in our app directory?",
"should_trigger": true
},
{
"query": "Set the rules for what vendors are allowed to put in their screenshots on our store",
"should_trigger": true
},
{
"query": "Can we quietly rank listings without a demo video lower to nudge vendors?",
"should_trigger": true
},
{
"query": "We want a certified program for our listings - what do we display, and where?",
"should_trigger": true
},
{
"query": "Our category assignments have drifted from what the apps actually do",
"should_trigger": true
},
{
"query": "Build a self-check checklist partners can run before they submit to our directory",
"should_trigger": true
},
{
"query": "What belongs on a listing's trust tab?",
"should_trigger": true
},
{
"query": "We're rewriting our app store content guidelines now that we're at scale",
"should_trigger": true
},
{
"query": "How prescriptive should our per-field limits be for submitted listings?",
"should_trigger": true
},
{
"query": "The same submission gets approved by one of my reviewers and rejected by another",
"should_trigger": true
},
{
"query": "What do we do when a partner's certification lapses but their badge is still showing?",
"should_trigger": true
},
{
"query": "How do we stop vendors from claiming every category we offer?",
"should_trigger": true
},
{
"query": "Our integration catalog looks abandoned - dead links everywhere",
"should_trigger": true
},
{
"query": "Define what 'out of date listing' means precisely enough that we can enforce it",
"should_trigger": true
},
{
"query": "Should accessibility be part of what we require from submitted listings?",
"should_trigger": true
},
{
"query": "Do we need to make submitters supply alt text for the screenshots they upload?",
"should_trigger": true
},
{
"query": "We charge partners an annual directory fee - doesn't that keep their listings current?",
"should_trigger": true
},
{
"query": "Draft the media spec sheet for our partner app gallery",
"should_trigger": true
},
{
"query": "How many screenshots should we require, and what do they have to show?",
"should_trigger": true
},
{
"query": "Our copy rules for the app store are one paragraph of principles and it isn't working",
"should_trigger": true
},
{
"query": "What KPIs tell us whether our listing rulebook is actually working?",
"should_trigger": true
},
{
"query": "Should vendors be allowed to put our product name first in their app's name?",
"should_trigger": true
},
{
"query": "We want partners to put an 'available on our marketplace' badge on their own sites - what rules do we publish?",
"should_trigger": true
},
{
"query": "Write the rules for taking an app listing down for content reasons",
"should_trigger": true
},
{
"query": "Help me optimize our AppExchange listing so we get more installs",
"should_trigger": false
},
{
"query": "How do I rank higher in the HubSpot app marketplace search results?",
"should_trigger": false
},
{
"query": "Rewrite our Shopify App Store title and tagline for keywords",
"should_trigger": false
},
{
"query": "How do we get more reviews on our Atlassian Marketplace listing?",
"should_trigger": false
},
{
"query": "Which marketplace badge should we pursue to boost our listing's rank?",
"should_trigger": false
},
{
"query": "Our marketplace listing gets plenty of views but nobody installs - fix the funnel",
"should_trigger": false
},
{
"query": "Should we reorder the screenshots on our Slack app listing?",
"should_trigger": false
},
{
"query": "Is Built for Shopify worth pursuing for our app?",
"should_trigger": false
},
{
"query": "Design our app review pipeline for third-party submissions",
"should_trigger": false
},
{
"query": "What permission scopes should trigger a manual security review of a submitted app?",
"should_trigger": false
},
{
"query": "When should an app update force a full re-review?",
"should_trigger": false
},
{
"query": "Write the appeal process for developers whose apps we rejected",
"should_trigger": false
},
{
"query": "How do we revoke a malicious app across every tenant that installed it?",
"should_trigger": false
},
{
"query": "Set up automated pre-screening before a human reviews an app submission",
"should_trigger": false
},
{
"query": "How do we harden our publish channel against a compromised developer account?",
"should_trigger": false
},
{
"query": "What revenue share should we take on paid apps in our marketplace?",
"should_trigger": false
},
{
"query": "Should we be merchant of record for marketplace transactions?",
"should_trigger": false
},
{
"query": "Design the payout cadence and hold window for our app store developers",
"should_trigger": false
},
{
"query": "How do marketplace facilitator VAT rules apply to our app sales?",
"should_trigger": false
},
{
"query": "Should we waive our marketplace fee for a partner's first year?",
"should_trigger": false
},
{
"query": "Should we build our own app marketplace or just list on other vendors' marketplaces?",
"should_trigger": false
},
{
"query": "Open admission or curated - which model should our integration marketplace run?",
"should_trigger": false
},
{
"query": "Are we ready to launch a two-sided developer ecosystem at all?",
"should_trigger": false
},
{
"query": "What take-rate makes an integration marketplace viable for us?",
"should_trigger": false
},
{
"query": "Pick the launch partners for our marketplace debut",
"should_trigger": false
},
{
"query": "How should featured placement work on our marketplace homepage?",
"should_trigger": false
},
{
"query": "Design our app-of-the-month spotlight program",
"should_trigger": false
},
{
"query": "How much MDF should we allocate to each partner tier?",
"should_trigger": false
},
{
"query": "Plan the keynote announcement for our app store launch",
"should_trigger": false
},
{
"query": "Design the signup flow for partner developers joining our platform",
"should_trigger": false
},
{
"query": "Should partner registration be self-service or application-gated?",
"should_trigger": false
},
{
"query": "How do we provision sandbox tenancies for partner developers?",
"should_trigger": false
},
{
"query": "Redesign the information architecture of our developer portal",
"should_trigger": false
},
{
"query": "How do we cut time to first API call on our developer console?",
"should_trigger": false
},
{
"query": "Audit our API reference for undocumented endpoints and error codes",
"should_trigger": false
},
{
"query": "Our OpenAPI docs keep drifting from the implementation",
"should_trigger": false
},
{
"query": "Which technology partners should we integrate with first?",
"should_trigger": false
},
{
"query": "Design our ISV partner tier ladder and graduation gates",
"should_trigger": false
},
{
"query": "Should we build a Fivetran source connector for our product?",
"should_trigger": false
},
{
"query": "Design the consent screen third-party apps show when requesting scopes on our API",
"should_trigger": false
},
{
"query": "Should we ship an MCP server for our product?",
"should_trigger": false
},
{
"query": "Write the product description standards for our ecommerce catalog",
"should_trigger": false
},
{
"query": "ASO for our iOS app - improve the App Store screenshots and keywords",
"should_trigger": false
},
{
"query": "Optimize our Amazon product listing images and bullet points",
"should_trigger": false
},
{
"query": "Set content standards for postings on our jobs board",
"should_trigger": false
},
{
"query": "Write the submission guidelines for our conference CFP",
"should_trigger": false
},
{
"query": "Design the quality bar for articles submitted to our content marketplace",
"should_trigger": false
},
{
"query": "Standardize how we photograph products for our online store",
"should_trigger": false
}
]
}
references/decay-and-badge-programs.md›
# Decay enforcement and badge programs across the benchmarks
Same sourcing rule as the field benchmarks: operator-published documentation unless labeled otherwise. Two source conflicts are carried below as-is, per the label on each - do not silently resolve either.
## Decay-enforcement inventory
No shared industry term or standard for listing decay exists; each operator handles staleness through a different mechanism:
- **Policy-as-violation** - Chrome and Google Workspace both classify "out of date" metadata (description, category, developer name, title, icon, screenshots, promo images) as a rejectable/removable policy violation outright. Google additionally re-reviews its most popular apps on a recurring basis.
- **Staleness downgrade** - Atlassian marks an app whose categorization goes stale post-launch as "uncategorized", removing it from every category browse/filter surface: soft, self-correcting (fixable any time by updating the listing), no delisting fight.
- **Substantial-change trigger** - Slack names "a listing not updated to reflect substantial changes" to the app as a rejection/removal risk. Note the trigger is subjective ("substantial"), which is exactly the trap the skill's field-spec menu warns about - if you adopt this shape, define "substantial" objectively.
- **Version-currency enforcement** - HubSpot is the most systematic mechanism surveyed:
- The platform ships a new developer-platform/API version every six months (March/September).
- New apps built on unsupported versions are rejected outright.
- Existing apps must be on a supported version at certification or recertification time, with roughly 60 days to migrate.
- Deprecated components (classic CRM cards, deprecated 2025-06-16) make an app unlistable.
The platform's own release cadence does the freshness-detection work.
- **Fee-as-renewal** - Salesforce charges paid apps a $150 annual listing fee (Partner Community FAQ): an ongoing-cost nudge, not a content-freshness gate; no published content-update cadence is tied to delisting. This is why the skill deletes fees from the decay menu - nothing about a fee checks content.
- **Discretionary monitoring** - Zoom monitors published apps for continued compliance and may remove or require revisions, with no published calendar trigger; developers must maintain ongoing support surfaces (terms, privacy policy, self-serve docs, support URL).
**Adjacent-ecosystem hard cadences** - the only explicit numeric auto-removal rules found live outside the eight-marketplace benchmark set, in the neighboring e-commerce/enterprise marketplace ecosystem; label them as adjacent when citing:
- Adobe Commerce Marketplace ("Abandoned listings" policy, verbatim):
- The app or extension must be updated at least once every year.
- A monthly automated checker collects everything not updated for 11 months or more.
- At 12 months without an update, after automated notification, the listing is removed.
- Microsoft's commercial marketplace (AppSource documentation): publishers must keep listings updated across the lifecycle, with a staged deprecation/removal timeline running from T+1 to T+150 after a listing is flagged.
Use Adobe's 12-month rule as an internal worst-case freshness SLA even where nothing external forces one.
**Resolved, not a live conflict**: the $2,550 one-time Security Review fee is the pre-March-2023 model (paired with a $150 annual fee); Salesforce replaced it in March 2023 with the current $999-per-attempt fee, charged on the initial submission and on every resubmission after a failed review. Cite $999 as current; treat $2,550 as historical only. (The fee itself belongs to the review/monetization siblings' scope - it is recorded here only because the listing-fee source carried the now-resolved conflict.)
## Badge programs and their display rules
Badge eligibility mechanics belong to the review process; what follows is the display-relevant detail per operator:
- **Atlassian - the dedicated trust surface**: the Trust & Security tab is physically separate from the marketing description; it must state data-storage location, display relevant earned badges (Cloud Fortified, Bug Bounty participation), and list compliance certifications. The clearest surveyed example of splitting persuasive content from trust content.
- **Google Workspace - two badges, and the brand rulebook**:
- An independent security-verification badge earned via CASA assessment, displayed on the marketplace homepage, in search results, and to admins in the admin console; mandatory for "Recommended" status. **Resolved**: "Tier 3" and "Assurance Level 2 (AL2)" name the same CASA requirement - Google's own get-featured page uses AL2 in its current English version and "Tier 3" in other cached/localized versions of the identical page (French, German). Cite AL2 as the current name; "Tier 3" is the same tier under its older name, not a different requirement.
- A developer-embeddable promotional badge governed by the most detailed brand-usage spec surveyed (create-badge page, last updated 2026-07-22):
- Use as provided and never alter.
- Clear space equal to one-quarter of badge height.
- Equal to or larger than any other app-store badge alongside it.
- Any online use links back to the listing.
- Caption must read "from" the marketplace, never "on" it.
- **HubSpot - renewal-linked certification**: App Certification is reviewed against seven quality categories (security, privacy, reliability, performance, usability, accessibility, value).
- Requires ≥6 months listed and ≥60 active unique installs over a trailing six-month window (floor raised from 6 to 60 effective 2024-05-15).
- Falling below removes certified status (app stays listed, uncertified) with a six-month wait before re-applying.
- Certification renews on a rolling two-year cycle.
The most systematic recertification mechanism surveyed, and the model for wiring badge display to lapsable eligibility data.
- **Salesforce - self-service badges**:
- Lightning Ready, via a self-attested checkbox in the publishing console.
- 100% Native, via a support case.
Lightweight to run, and the trust they carry is correspondingly self-attested.
- **Zoom - no badge program, by architecture**: no software-app trust/certified badge exists on the marketplace at all; "Zoom Certified" applies only to hardware, run as a separate program. A genuine design choice, not a documentation gap - present "no badge program" as a legitimate option.
- **Chrome - identity, not quality**: a linked "Official URL" renders under the listing title only for publishers who verify site ownership - an identity-verification display distinct from any quality/security badge; worth offering because it costs the operator almost nothing.
## The external-certification gap
No ISO standard, IAB standard, or independent certification body exists for B2B SaaS marketplace listing quality. Only two substitute classes exist:
- Operator-proprietary programs (the badges above, none portable across marketplaces).
- General security/quality-management standards (SOC 2, ISO/IEC 27001, ISO 9001, CASA/ASVS, FedRAMP) that certify an organization's posture, never a listing page's content.
Practical consequence: an operator claiming its listings are "certified to an industry listing standard" is making an unverifiable claim. The honest positioning is compositional, named as its own:
- WCAG for accessibility.
- Recognized security attestations for security posture.
- The operator's own published rubric.
## The accessibility gap
- Atlassian is the only operator across all eight that names listing-content accessibility as an approval requirement: descriptive alt text on every informative image, no color-only meaning, enforced contrast/legibility on visual assets.
- HubSpot scores "accessibility" as a certification category, but for the app's own UI, not the listing page.
- Nobody else requires submitter-supplied alt text for uploaded screenshots at all.
WCAG 2.2 AA (text alternatives per SC 1.1.1, captions, contrast) is the de facto external reference an operator would adopt voluntarily - a low-cost differentiator today and future-proofing against tightening accessibility law (EU accessibility legislation, ADA exposure).
## Conversion figures - vendor-reported, unaudited
Marketplace-tooling vendor Partner Fleet (a party selling marketplace software, so a motivated source) publishes:
- "84% of businesses say integrations are 'very important' or a 'key requirement'" (attributed to a 2024 State of SaaS Integrations report).
- "One Partner Fleet customer sees a 30% click-through rate" from marketplace to free trial.
- "An average 2-3% CTR on most SaaS pages", as its comparison baseline.
Treat all three as vendor marketing, never as a target to promise. Its recurring UX recommendations are more transferable than its numbers:
- Lead with a media section.
- Rank calls-to-action: embedded scheduler above lead-capture form above generic link.
- Require attributed social proof.
- Run operator-side "listing scorecards" - a configurable rubric (e.g. minimum screenshot count, at least one attributed testimonial) enforcing consistency across partner-maintained listings, which is a vendor-tool implementation of exactly the rulebook this skill writes.
Notably, the listing UX this vendor cites as best-in-class belongs to the one operator with no badge program at all - listing quality and certification are independent axes.
references/marketplace-listing-benchmarks.md›
# Eight-marketplace listing-content benchmarks
Sourced from each operator's own published listing/approval documentation unless a row says otherwise. These are reference points for calibrating your own rulebook, never numbers to copy as an industry standard - the geometries and caps below genuinely disagree with each other.
Marketplaces surveyed: Shopify App Store, Atlassian Marketplace, Slack Marketplace, Salesforce AppExchange, Google Workspace Marketplace, Zoom App Marketplace, Chrome Web Store, HubSpot App Marketplace.
## The shared skeleton
All eight converge on the same six-part listing structure despite different field names:
1. A short hook string (app introduction / tagline / short description).
2. A longer benefit-oriented body (app details / summary plus details / long description).
3. A visual gallery with a fixed count and, in six of eight, an exact geometry.
4. An optional short video with a runtime ceiling.
5. A category/keyword assignment with an explicit cap (seven of eight).
6. Off-listing trust surfaces - privacy policy, support contact, documentation/landing link - that gate approval independently of the marketing copy.
## Text-field limits
| Marketplace | Name | Hook | Body |
| ---------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Shopify | ≤30 chars, must lead with brand name | app introduction ≤100 chars | app details ≤500 chars; feature list items ≤80 chars |
| Atlassian | ≤60 chars; bans "Atlassian", "plugin", "beta", "add-on", "app" in the name | tagline ≤130 chars | summary ≤250 chars; exactly 3 mandatory highlight blocks ("Rule of 3"): title ≤50, summary ≤220 each |
| Slack | unique, readable, spellable | short description ≤10 words (tightest hook cap surveyed), plain text only | long description: what the service does, the problem, and how it works inside the platform specifically |
| Salesforce | title + tagline (no published char caps found) | - | full description + key features; completion tracked in the Listing Builder rather than gated per field |
| Google Workspace | ≤50 chars; must match the OAuth consent screen; cannot use the operator's product names | short description ≤200 chars | detailed description <16,000 chars (largest body cap surveyed) |
| Zoom | informative and unique, ≤50 chars | principles-based, no numeric caps published | principles-based ("Value", "Trust") - see the spec-strictness menu's deletion argument |
| Chrome | - | - | blank description = automatic rejection; violations enumerated, not capped (see below) |
| HubSpot | brand rule: never combine the operator's name with the app's own name/logo | - | content must be integration-specific, not generic product marketing; all URL fields ≤250 chars |
## Media specs and geometries
No universal screenshot ratio exists - this is the load-bearing negative finding:
| Marketplace | Screenshot geometry | Count | Icon | Distinctive mechanism |
| ---------------- | ----------------------------------------------------------------------------------- | --------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Shopify | 1600×900 (16:9) | 3-6, ≥1 of actual app UI | 1200×1200, no text/trademarks on it | feature media: video or 1600×900 image, ≥4.5:1 contrast |
| Atlassian | 1840×900 full + 580×330 cropped highlight | per Rule of 3 + gallery | - | every screenshot requires a caption ≤220 chars |
| Slack | 1600×1000 (8:5), <2MB | - | - | screenshots must show the app inside the platform's own UI, not the third-party tool's; wrong-ratio/off-topic image is a named rejection trigger |
| Salesforce | 700×467 (≈3:2), ≤1MB | - | 60×60 PNG; 224×164 tile for top search results | media specs spread across Partner Community docs, not one canonical sheet - verify against the live console before citing |
| Google Workspace | 1280×800 recommended (640×400, 2560×1600 accepted), square corners, no letterboxing | 1-10 | ≥32×32 and 128×128 | 220×140 application-card banner required |
| Zoom | no published geometry | - | 160×160, separate light-mode and dark-mode images | Technical Design Document required before submission is accepted at all - the only artifact-gated submission surveyed |
| Chrome | 1280×800 (640×400 accepted) | 1-5 | 128×128 | 440×280 promo tile: optional but ranking-penalized when absent - "items without it are ranked below items that have one", the only ranking-penalty enforcement lever surveyed |
| HubSpot | no published geometry; content/URL correctness policed instead | screenshots + demo video required | - | every URL verified live and public by the operator's own crawler; a Shared-data table must match the app's actual OAuth scopes |
## Video ceilings
The runtime ceiling tracks the buyer evaluation mode, not the market:
- Atlassian: 30 seconds (strictest - live functionality only, explicitly anti-marketing).
- Slack: 30-90 seconds (public video link, captions on, ads off, realistic environment).
- Shopify: 2-3 minutes (loosest - promotional tone allowed, screencast content capped at 25% of runtime).
- Zoom: permits local-language or English demo video.
Pick a ceiling from your own question-4 answer. Do not average these.
## Description philosophy - the convergent rule with the worked pair
Shopify and Atlassian arrived independently at the same instruction: lead with the customer outcome, connect features to measurable results. Shopify's worked pair (Partner Dashboard requirements) is the cleanest accept/reject example surveyed:
- Accepted: "Reports that show you sales data in real time."
- Rejected: "Reports that use the latest push technology to offer you sales data with only 250ms of latency." - technical mechanics the buyer doesn't evaluate on.
Chrome's Listing Requirements policy (last updated 2024-07-10) enumerates the violation side most explicitly:
- Misleading, inaccurate, incomplete, or non-descriptive text.
- Out-of-date metadata.
- Keyword spam, defined concretely as unnatural repetition of a keyword more than five times, or lists of sites/brands/regions with no added value.
- Unattributed or anonymous user testimonials - the only surveyed marketplace naming testimonial attribution as its own trigger.
## Naming-order rule - three independent enforcements
- Atlassian: "Time Tracker for Jira" accepted; "Jira Time Tracker" treated as a trademark issue.
- Slack: "Task notifications for Slack" accepted; "Slack task notifications" not.
- Zoom: "for Zoom" explicitly permitted to describe compatibility; the operator's name or trademarks in the app name itself are not.
Three operators converging on the identical shape makes this a default rule for any marketplace whose name carries trademark weight.
## Taxonomy caps - the full spectrum
| Marketplace | Shape | Cap |
| ---------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Salesforce | fixed list | 1 category + 2 industries (tightest surveyed) |
| Chrome | single fixed-list pick | 1 category; soft cross-locale consistency warning only |
| Atlassian | fixed flat list of 10 | 2 categories + 4 keywords; stale categorization → marked "uncategorized" and removed from every browse/filter surface (soft, self-correcting) |
| Shopify | categories + structured tags | up to 25 structured features per category; 5 search terms, one idea per term ("email marketing" accepted, "email marketing for leads" rejected for stacking two ideas) |
| Google Workspace | 1 self-selected category + operator-curated layers | Editor's Choice, "Works with…" labels, "Recommended" status - all operator-assigned, none purchasable |
| HubSpot | 1 category + feature tags + operator-curated persona collections | collections curated for marketer/sales/designer personas |
| Slack | browse categories | no explicit cap documented in the fetched guidelines |
| Zoom | overlapping product-based and function-based categories | no published per-listing cap; the widely cited "15+ categories" figure is third-party analysis (UC Today), not an operator spec - treat as unverified |
## Localization - the three shapes plus one asymmetry
- **Auto-translate with override** (Shopify):
- An English listing auto-translates into eight languages across every text field.
- A vendor can override any one language.
- Deleting the override silently reverts to machine translation.
- **Region-locked** (Google Workspace): for each distribution region selected, that region's language must be present in the listing details, or users in that region cannot find or open the listing at all.
- **All-or-nothing declaration** (Slack): declaring a language commits the vendor to every message, interactive component, and related interface being available in that language - a runtime-capability claim, with no machine-translation fallback.
- **Opt-in per market** (Salesforce): market-specific listings (e.g. a per-country storefront listing) via a documented setup, fully optional.
- **The asymmetry** (Chrome): text, screenshots, and video localize per locale, but the two promo tiles cannot be localized at all - the one ranking-relevant visual asset stays locked to a single design across every locale. Worth checking your own asset pipeline for the same accidental gap.
## Off-listing trust surfaces
Slack documents the strictest requirements beyond the marketplace page itself:
- A landing page publicly accessible without login, covering the integration and install path (a PDF, document, or code repository explicitly disqualified as a substitute).
- A support page offering contact without a new account signup, committing to a response within 2 business days.
- A privacy policy with a minimum-coverage checklist: data collected, usage, retention duration, access/transfer/deletion request process, and a real contact channel (a physical address alone explicitly insufficient).
HubSpot adds the enforcement mechanism: every URL verified live by crawler, setup guide not behind a login, listed pricing required to match the vendor's own website. Atlassian adds the commercial-hygiene variant: paid apps must use a company email domain, not a personal one.
## Merchant/customer eligibility gating
One upstream mechanism worth copying from Shopify: the vendor sets machine-checkable install eligibility (sales channel, country, currency) so poor-fit customers are excluded _before_ the install-then-uninstall-then-negative-review cycle - listing-quality enforcement acting upstream of the review score rather than policing content after the fact.
SKILL.md›
---
name: app-marketplace-listing-standards
description: Write the listing-content rulebook for the operator of a B2B SaaS app marketplace - the standard every third-party listing must meet, covering required fields with objective reject criteria, screenshot and video specs, description quality bars, category taxonomy design, localization posture, badge display rules, and staleness/decay enforcement. Use whenever the user mentions listing standards, a listing rubric or marketplace quality bar, screenshot or media requirements, marketplace categories, rejection criteria, or delisting stale listings - even if they never say "listing standards". Operator side only. Do NOT use for optimizing a vendor's own listing - use samber/developer-platform-skills@integration-listing-optimization instead.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# App Marketplace Listing Standards
You are a marketplace-content advisor to the platform team that operates a B2B SaaS app marketplace. Write the listing-content rulebook the marketplace enforces against every third-party submission: what a listing must contain, what gets it rejected on content grounds, and what happens to it when it goes stale. The output is a published rulebook a submitter can self-check before submitting and a reviewer can enforce consistently - because across the benchmarked operators, the ones with the fewest review disputes are the ones whose rules are objective enough to fail against before submission.
This skill is the mirror image of submitter-side listing optimization: the rubric a vendor optimizes their listing against is exactly the rubric being written here. Content standards also stay deliberately separate from safety: a blurry screenshot, a keyword-stuffed description, or a trademark-infringing name gets a listing rejected regardless of whether the app is secure and functional - those gates belong to the review process, not this rulebook.
**Memory (advised):** When memory lives in a file, consider using `developer-platform-context.md`; if a different memory system is in use, rely on that instead. The file is an advisory reference, not a mandatory requirement. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.
## Interview
Ask these before proposing anything. One question per message, multiple-choice where offered - each answer redirects a menu below.
1. Where is the listing standard today? (a) designing from scratch pre-launch (b) marketplace live, content rules ad-hoc (c) rulebook exists, revising for scale or friction (d) revising after a quality incident - low-quality listings, buyer complaints, stale catalog.
2. How many listings now and in 12 months, and who maintains each one - the vendor self-service, or your team on the vendor's behalf? The maintenance model sets how prescriptive the spec must be.
3. Which curation rung did the marketplace strategy choose - open, hybrid with a certified tier, or hard gate? The content bar enforces that decision; it does not re-make it (see `samber/developer-platform-skills@connector-marketplace-strategy`).
4. Who evaluates a listing before install - an end user installing self-serve, or an admin or committee doing diligence? This moves video length, tone, and description philosophy.
5. Does your platform ship versioned releases or scheduled deprecations on a cadence? This enables the strongest decay-enforcement rung.
6. Which languages and regions must listings serve, now and in 24 months?
7. Does a review, certification, or badge program exist or is one planned? Badge display rules only apply when there is something to display - eligibility lives with the review process.
8. By when must the rulebook be live - a hard date, or open-ended?
9. Is this a one-off win (unblock a launch, satisfy a flagship partner) or a compounding asset (a quality bar that appreciates as the catalog grows)?
10. What is the effort ceiling - reviewer hours per week for content review, engineering time for automated checks (link crawlers, image validators), and appetite for partner friction?
Questions 8-10 exist because the menus below diverge sharply on time-to-effect, durability, and effort:
- A hard deadline promotes rungs that ship as policy text.
- A compounding mandate promotes tooling and curation layers.
- A low effort ceiling rules whole shapes out, rather than demoting them.
## Who evaluates and who maintains
The eight marketplaces benchmarked for this skill span consumer-adjacent browser extensions to enterprise B2B suites, and all eight converge on the same listing skeleton ([references/marketplace-listing-benchmarks.md](references/marketplace-listing-benchmarks.md)):
- A short hook string.
- A benefit-oriented body.
- A fixed-geometry visual gallery.
- A capped optional video.
- A capped category assignment.
- Off-listing trust surfaces (privacy policy, support channel, landing page) that gate approval independently of the marketing copy.
What actually diverges tracks two other variables:
- **Who evaluates the listing.** Marketplaces whose buyers self-serve install tolerate promotional pacing (the loosest benchmarked video ceiling is 2-3 minutes, promotional tone allowed); marketplaces whose listings face an evaluating admin demand terse function proof (the strictest ceiling is 30 seconds, marketing footage banned).
- **Who maintains listings at what volume.** A vendor-self-service catalog needs machine-checkable prescriptive specs; an operator-assisted boutique catalog can run on judgment.
So write the same skeleton whatever the market, and set strictness and tone from questions 2 and 4.
## Workflow
1. Fix the design inputs: curation rung inherited from strategy, listing volume and maintenance model, buyer evaluation mode, platform release cadence, language/region targets.
2. Write the field skeleton and choose the spec-strictness rung (menu 1).
3. Set media specs and the accessibility floor (menu 2).
4. Write the description quality bar and the content-rejection trigger taxonomy.
5. Design the category taxonomy (menu 4).
6. Set the localization posture (menu 5).
7. Write the badge display rules (menu 6).
8. Write the decay-enforcement policy (menu 7).
9. Set measurement, then check the rulebook against the gates in Measurement.
Draft the rulebook section by section in that order, validating each with the user before the next:
- A wrong strictness rung caught at step 2 is cheap.
- The same rung discovered at step 8 rewrites every spec between.
## 1. Field-spec strictness
How prescriptive the rulebook's field requirements are. Four rungs, ranked. Efficiency here means consistent rejections bought per hour of rulebook authoring and maintenance:
- effort, authoring plus tooling (descending): `completion-tracked builder > exact per-field limits > named rejection triggers > principles-only`
- rejection consistency bought: `exact per-field limits > named rejection triggers > completion-tracked builder > principles-only`
- efficiency: `named rejection triggers > exact per-field limits > completion-tracked builder > principles-only`
- **Default rung: named rejection triggers, plus exact limits on the load-bearing fields only** - name, hook string, body, media geometry get numeric caps; everything else gets an enumerated list of violations (misleading or out-of-date metadata, keyword spam defined numerically, unattributed testimonials - the pattern of the most explicitly enumerated benchmarked policy). A trigger a submitter can self-check costs one sentence to write and removes a whole class of review disputes.
- **Promote to exact per-field limits across the board** once listings are vendor-self-maintained at volume - the most granular benchmarked rulebook puts a character or pixel cap on nearly every field precisely because thousands of self-service submitters cannot be reviewed on judgment. Consistency then depends on the spec, not on which reviewer reads it.
- **Starved option: the completion-tracked builder** - a submission console that tracks listing completion percentage and blocks publication below a floor. Highest effort (it is partner-console engineering, not policy text), best submitter completion rates, so it loses every efficiency round. Promote it when a partner console already exists and the rulebook can ship as validation rules inside it - an asset already owned re-ranks this menu.
- **Deleted, not demoted: principles-only rules** ("listings should demonstrate value and trust") once more than one person reviews content. Two reviewers reading the same principles reject different listings, and the gap surfaces as appeal noise. Not parked at the bottom, because "we'll use judgment" silently reappears as scope every time writing a real trigger feels like work.
This ranking is a default, not a law - and so is every menu below. Re-rank each against the interview: question 2 moves this menu, question 4 moves menu 2 and the quality bar, question 5 moves menu 7, question 7 moves menu 6 - and against assets the team already owns (an existing partner console, an existing localization pipeline, an in-house editorial function). Say which answer moved which rung.
## 2. Media specs
The single most important fact from the benchmarks: **there is no industry-standard screenshot geometry**. The eight operators ship 16:9, 8:5, and roughly 3:2 in production, and two skip pixel rules entirely ([references/marketplace-listing-benchmarks.md](references/marketplace-listing-benchmarks.md)). Never borrow one vendor's numbers as an industry constant - pick one geometry for your marketplace, publish it, and hold every submission to it. Three enforcement postures, ranked:
- effort (descending): `ranking-penalized optional assets > fixed-geometry hard spec > content-correctness-first`
- browse-surface quality bought: `fixed-geometry hard spec > ranking-penalized optional assets > content-correctness-first`
- efficiency: `fixed-geometry hard spec > content-correctness-first > ranking-penalized optional assets`
- **Default rung: fixed-geometry hard spec plus content rules** - one published ratio and count per asset type, and content requirements that matter more than pixels: at least one screenshot of the actual app UI, no PII, no pricing or review claims baked into the image, a quality floor (an off-topic, distorted, or wrong-ratio image is a named rejection trigger, stated as directly as the strictest benchmarked policy states it).
- **Content-correctness-first** - live URLs and truthful imagery policed, pixels not - is the right posture only while the operator's team maintains listings itself (question 2); it survives at scale in exactly the benchmarked marketplaces whose review process verifies every URL with a crawler.
- **Starved option: the ranking-penalty lever** - an optional asset that publishes without penalty of rejection but ranks below listings that provide it (one benchmarked operator does this for a promotional tile). It requires ranked search infrastructure to exist, so it loses every efficiency round; promote it when ranking already exists and an asset should be encouraged rather than required - and disclose the penalty in the published policy, as the operator that invented it does.
- **Video ceiling** (set deliberately from question 4): 30-second function-proof with marketing footage banned at the diligence end, 2-3 minutes with promotional tone allowed at the self-serve end, captions required either way.
- **Accessibility floor** (adopt voluntarily): descriptive alt text on informative images, captioned video, contrast and legibility minimums per WCAG 2.2 AA.
Only one of the eight benchmarked operators mandates listing-content accessibility, which makes it a cheap differentiator while adoption stays rare, and future-proofing against tightening accessibility law ([references/decay-and-badge-programs.md](references/decay-and-badge-programs.md)).
## 3. Description quality bar and rejection triggers
Two independent benchmarked operators - a commerce platform and a dev-tools platform - arrived at the same description rule separately, which is strong enough evidence to adopt as the default: **lead with the customer outcome, not the feature's technical mechanism**, and connect each feature claim to a measurable result. The worked accept/reject pair lives in [references/marketplace-listing-benchmarks.md](references/marketplace-listing-benchmarks.md).
Write the rejection triggers so a submitter can self-assess every one:
- **Keyword spam, defined numerically** - unnatural repetition of a term past a stated count, or lists of brands/regions with no added value; never just "don't stuff keywords".
- **Unattributed or anonymous testimonials**, and unsubstantiated outcome guarantees.
- **Trademark naming order** - "Task Tracker for {YourPlatform}" is the accepted shape; "{YourPlatform} Task Tracker" is rejected. Three benchmarked operators enforce this independently with near-identical worked examples; adopt the rule and publish your own pair.
- **Misrepresentation** - the listing must describe what the app actually does; undisclosed third-party account dependencies and their cost are a content violation.
- **Off-listing trust surfaces as hard gates**: a publicly accessible landing page (a PDF or code repository is explicitly not one), a support channel with a stated response commitment, and a privacy policy meeting a minimum-coverage checklist - approval-gating regardless of how good the marketing copy is.
## 4. Category taxonomy
Every benchmarked taxonomy that works has some cap or curation mechanism; the design question is which. Three shapes, ranked. Efficiency here means discoverability bought per unit of standing operator effort:
- standing operator effort (descending): `operator-curated layers > category plus structured tags > fixed capped list`
- discovery value bought: `operator-curated layers > category plus structured tags > fixed capped list`
- efficiency: `fixed capped list > category plus structured tags > operator-curated layers`
- **Default rung: a small fixed cross-functional category list with a hard per-listing cap** of one or two (the benchmarked spectrum runs from one category plus two industries to two of ten), enforced by a **staleness downgrade rather than delisting**: a listing whose categorization drifts from the app gets marked uncategorized and drops off every browse surface - soft, self-correcting, automatable.
- **Promote to structured tags on top of categories** (per-category feature tags plus a handful of search terms, each capped and one-idea-per-term) once search overtakes browsing as the discovery path - the tag caps are what keep search results meaningful.
- **Starved option: operator-curated layers** - editorial collections, "works with" labels, persona groupings assigned by the operator and never purchasable. Highest discovery value and a standing editorial cost every cycle, so it loses every efficiency round; promote it on a compounding mandate (question 9) once the catalog outgrows browsing, and keep placement unpurchasable - the moment curation is sellable it stops being a discovery signal and becomes inventory, which is the launch-marketing skill's territory.
- **Deleted, not demoted: uncapped self-selection.** An uncapped multi-select taxonomy degenerates into every listing claiming every plausible tag until categories stop meaning anything. Not parked at the bottom, because "let vendors pick more categories later" silently reappears every time a partner asks for broader placement.
## 5. Localization posture
Rank by market reach bought per unit of combined operator-plus-vendor effort:
- effort, setup plus per-listing (descending): `all-or-nothing declaration > auto-translate with override > region-locked > opt-in per market`
- reach bought: `auto-translate with override > region-locked > opt-in per market > all-or-nothing declaration`
- trust of the language claim: `all-or-nothing declaration > region-locked > opt-in per market > auto-translate with override`
- efficiency: `opt-in per market > auto-translate with override > region-locked > all-or-nothing declaration`
- **Default rung: opt-in per market** - listings launch in one language; a vendor may add per-market listings through a documented path. Cheapest real localization, and the honest floor while question 6 names one primary market.
- **Promote to auto-translate with vendor override** when the operator has machine-translation infrastructure to amortize: every listing gains every supported language by default, and a vendor can replace any one translation - the benchmarked default-on model. The trust cost is real: machine output carries the operator's name.
- **Region-locked** is the posture forced when distribution-region selection controls visibility: each selected region's language must be present or users there cannot find the listing at all. Adopt it only together with region gating, never alone.
- **Starved option: all-or-nothing capability declaration** - declaring a language commits the vendor to the full runtime experience in that language, not just a translated listing page. Highest vendor effort and the least listing reach, so it loses every efficiency round; promote it when buyers treat language support as a purchase-blocking capability claim (enterprise multi-region rollouts), because it is the only rung where the listing's language claim is guaranteed true in the product.
## 6. Badge display
- **Eligibility** (what earns certification) belongs to the review process (`samber/developer-platform-skills@app-marketplace-review`).
- **Display** (where an earned badge renders and how its currency is enforced) is what this rulebook owns.
First check question 7: **running no badge program at all is a legitimate architecture, not an oversight** - one of the eight benchmarked operators does exactly that, and its listing UX is still cited as best-in-class, which shows listing quality and certification are independent axes. If badges exist, four display mechanisms, ranked:
- effort (descending): `renewal-linked display currency > off-marketplace promotional badge with brand rulebook > dedicated trust surface > inline badge chip`
- buyer trust bought: `renewal-linked display currency > dedicated trust surface > inline badge chip > off-marketplace promotional badge`
- efficiency: `dedicated trust surface > inline badge chip > renewal-linked display currency > off-marketplace promotional badge`
- **Default rung: a dedicated trust surface** - a listing tab or section physically separate from the marketing copy, stating data-storage location, displaying earned badges, and listing compliance certifications (the benchmarked trust-tab pattern). Pair it with a written currency rule: a lapsed badge comes down, with a stated grace period.
- **The inline chip** (a badge next to the listing name in search results) is the cheap complement, not a substitute - it asserts trust without the substantiating detail a diligence buyer needs.
- **Starved option: renewal-linked display currency automation** - badge display wired to the review program's eligibility data so a badge that lapses (a failed recertification, a threshold no longer met) disappears without human intervention. Highest effort, and the only mechanism where displayed badges are guaranteed current; promote it once badges carry quantitative, lapsable thresholds - the benchmarked certification that works this way runs on a rolling renewal cycle.
- **The off-marketplace promotional badge** (vendors embed "available on X" on their own sites) is marketing reach, not listing trust; if offered, ship it with a brand-usage rulebook - use as provided, minimum clear space, size parity with competing badges, mandatory link back - because the most detailed benchmarked badge spec is exactly that rulebook.
One hard rule whatever the rung: **never claim or imply an external listing-quality certification.** Targeted research found no ISO-, IAB-, or equivalent external body certifying marketplace listing quality anywhere in the industry - every real program is operator-proprietary. The honest positioning is compositional, named as yours ([references/decay-and-badge-programs.md](references/decay-and-badge-programs.md)):
- WCAG for accessibility.
- Recognized security attestations for security.
- Your own published rubric for content.
## 7. Decay enforcement
Listing content expires on its own whenever the app changes and the listing doesn't. Every benchmarked operator handles this differently and none publishes a hard numeric cadence - the only explicit "update every N months or be removed" rules live in adjacent ecosystems ([references/decay-and-badge-programs.md](references/decay-and-badge-programs.md)). Five mechanisms, ranked:
- operator effort (descending): `version-currency enforcement > calendar cadence with auto-removal > policy-as-violation > staleness downgrade > discretionary monitoring`
- freshness bought: `version-currency enforcement > calendar cadence with auto-removal > policy-as-violation == staleness downgrade > discretionary monitoring`
- efficiency: `staleness downgrade > policy-as-violation > calendar cadence with auto-removal > version-currency enforcement > discretionary monitoring`
The `==` holds because both mechanisms catch drift only when a review touchpoint notices it - they differ in consequence (removal risk versus a browse downgrade), not in detection, and detection is what limits the freshness either one buys.
- **Efficiency leader, and the always-on floor under whatever else runs: the staleness downgrade** (menu 4's uncategorized penalty) - automatable, self-correcting, no delisting fight. Its consequence is a browse downgrade rather than removal risk, so it stacks under a policy instead of replacing one.
- **Default rung: that downgrade plus policy-as-violation backed by a calendar sweep.** Name "out-of-date listing content" an explicit, rejectable violation in the published policy (two benchmarked operators do), then run a self-set operator-side review cadence - align it to your own release cycle, and treat the adjacent-ecosystem 12-month auto-removal benchmark as the internal worst-case freshness SLA even though nothing external forces it.
- **Starved option: version-currency enforcement** - new listings rejected outright on unsupported platform versions, existing listings required current at recertification, with a stated migration window. The most systematic mechanism in the whole benchmark set and the highest effort, because it presupposes versioned platform releases and deprecation discipline; promote it the moment question 5 says yes, since the release cadence then does the freshness-detection work for free.
- **Discretionary monitoring** - continuous compliance watching with no published trigger - is the floor, not a choice: it is what an operator does when it has not written a policy.
- **Deleted, not demoted: fees as a freshness mechanism.** One benchmarked operator charges an annual listing fee, and it renews the listing's billing relationship, not its content - a fee gates nothing a stale screenshot violates. Listing fees are revenue design and belong to the monetization model; keeping "the fee handles staleness" on this menu would let the rulebook believe decay is covered when nothing checks content at all.
Whatever the rung: every new content requirement applied to already-listed apps needs a notice runway before it takes effect - retroactive rule changes without runway burn the partner trust the standard exists to build.
## Failure modes
- **Borrowing a vendor's pixel numbers as an industry standard.** There is none - three geometries coexist in production. Fix: pick and publish your own, one per asset type.
- **Uncapped taxonomy.** Every listing claims every tag; browse surfaces stop discriminating. Fix: a hard cap or an operator-curated layer, chosen in menu 4.
- **Claiming an external listing-quality certification.** No certifying body exists; the claim is unverifiable at best. Fix: the compositional positioning in menu 6.
- **Review-once-and-forget.** A listing approved once with no decay mechanism drifts from the app until buyers notice before you do. Fix: menu 7's default rung at minimum.
- **Principles-only rules with multiple reviewers.** Inconsistent rejections, then appeal noise, then submitters learning the reviewer instead of the rulebook. Fix: menu 1's deletion argument.
- **Scope creep into security review.** The rulebook starts encoding permission audits and re-review triggers that belong to the review process; the two drift apart and contradict. Fix: content triggers fire independently of safety - keep the boundary and cross-reference.
- **Undisclosed ranking penalties.** Quietly down-ranking listings that skip an optional asset reads as arbitrary when discovered. Fix: if you rank-penalize, publish it, as the benchmarked operator does.
## Measurement
Rulebook gates first - self-set, and flagged as such: no industry pass-standard for a listing rulebook exists, and no external certification body to borrow one from. Iterate until all five pass:
1. Every required field carries an objective reject criterion a submitter can self-check before submitting.
2. Exactly one published geometry per visual asset type.
3. The taxonomy carries a hard per-listing cap, an operator-curated layer, or both.
4. Every listing has a decay trigger with an owner and a stated consequence.
5. Every displayable badge has a display location and a currency rule.
Operating KPIs once live:
- First-pass content-approval rate.
- Listing completion rate.
- Share of the catalog stale beyond the freshness SLA.
- Rejection-reason distribution (a rising "unclear content" share signals spec ambiguity, not submitter failure).
- Review turnaround against listing completeness - one benchmarked operator states outright that clear listing content shortens its review, so the correlation is worth instrumenting.
Listing-to-install conversion benchmarks exist only as vendor-reported marketing figures - usable as direction, never as a promised target ([references/decay-and-badge-programs.md](references/decay-and-badge-programs.md)).
If your harness has persistent memory, record:
- The chosen spec-strictness rung.
- The published media geometry.
- The taxonomy cap.
- The freshness SLA.
- Each menu's rung, with its promotion condition.
Review, onboarding, and launch-marketing runs should inherit these decisions instead of re-asking.
## Invocation examples
- "We're opening our app marketplace to third-party vendors next quarter - write the listing requirements page."
- "Half our marketplace listings have outdated screenshots and dead support links. Design a staleness policy that fixes this without delisting half the catalog."
- "Partners keep disputing listing rejections. Turn our ad-hoc content review into an objective rubric they can self-check against."