Review solicitation policy
Design or audit platform-specific public rating and review request eligibility, native request surfaces, cooldowns, policy-required audience exclusions, no-display behavior, and request-state evidence for apps, games, web products, and storefronts. Use when the requested artifact is an authentic public review solicitation policy or request state machine, including an audit of sentiment gating, star steering, review rewards, suppression, or retaliation. For private feedback intake, review ingestion or response, evidence clustering, support routing, product action, or close-loop learning, use product-feedback-learning-loop; compose both only when the request asks for both artifacts.From its SKILL.md
npx -y skills add SylphxAI/skills --skill review-solicitation-policyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 28 days oldThe repository was created 28 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.7 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it
Review Solicitation Policy
Produce one platform-current public review request policy. Optimize for authentic participation and durable trust, never predicted star value.
Resource guide
Read references/review-platform-policy-and-state.md for the adapter record, eligibility rules, request state machine, current official platform findings, prohibited transitions, and tests. Refresh every platform rule from current first-party authority before execution.
Composition contract
Begin a composed artifact with the
product artifact envelope.
Set ownerSkill: review-solicitation-policy and give the public request policy
its own artifactId, artifactVersion, artifactRevision, and
artifactState. The top-level artifact never self-hashes.
Every typed input names the exact producer contract through
fulfillsHandoffId. A draft input carries identity/revision/state but no digest;
a sealed input additionally requires artifactDigest and
digestRule: sha256-exact-bytes. Never invent a digest or resolve a moving
“latest” alias.
For a combined public-review/private-feedback request, produce two sibling
artifacts with distinct identities and stable producer-owned handoffIds.
They may share exact upstream product/value-event inputs. Add a one-way input
edge only when one sibling truly consumes a contract emitted by the other;
never create a cycle or merge their state machines.
Workflow
- Record each platform, storefront, territory, audience, product surface, meaningful-value event, accessibility context, current authority, and policy evidence gap. Treat each platform as an independent adapter.
- Retrieve current first-party policy and native API documentation. Record the publisher, effective/retrieved/expiry times, exact allowed surface, quotas, wording constraints, and no-display behavior. Disable an adapter whose authority is unknown or stale.
- Define neutral eligibility from verified meaningful value and a stable product context. Exclude cold launch, failures, outages, payment/refund or support pressure, safety incidents, purchase/reward moments, ineligible audiences, excess frequency, and accessibility blockers.
- Specify the independent request state machine from ineligible through native invocation and cooldown. A platform may suppress the sheet; the underlying product flow must still complete. Never infer a displayed sheet or selected star unless the platform supplies an authorized result.
- Prove that sentiment, predicted positivity, payer value, spend, tier, vulnerability, private feedback, complaint absence, or support outcome cannot affect public eligibility. Prove that review state cannot affect money, access, remedies, support, rewards, accounts, or product behavior.
- Hand authorized review ingestion, response, clustering, and product learning
to
product-feedback-learning-loop. Hand event implementation to Product Analytics and store submission/rejection work to Distribution Readiness. - For a combined public-review and private-feedback request, invoke
product-feedback-learning-loopas a sibling and return two independently accepted, versioned artifacts with stable handoff IDs and explicit one-way evidence handoffs where a real dependency exists.
When not to use
- For private feedback intake, review ingestion or response, evidence
clustering, product action, or customer close-loop state, use
product-feedback-learning-loop. - For listing conversion, analytics implementation, support operations, or store submission, use the corresponding specialist instead of expanding public review solicitation into those jobs.
Boundaries
- Never ask whether the user likes the product before deciding whether to show the public route. Do not target likely-positive users or hide the route from likely-negative users.
- Never steer toward five stars, draw a five-star cue, fabricate or filter reviews, ask for a higher rating, or reward posting, rating, editing, deleting, or improving a review.
- Never condition flow, compensation, refund, warranty, appeal, dispute, entitlement, account, data, or support treatment on a review action.
- Do not import one platform's rules into another. In particular, do not add an in-product Steam review prompt while current Steam rules prohibit it.
- Do not own private feedback, public review ingestion or replies, product prioritization, support operations, analytics implementation, listing conversion, or platform submission.
Output
Artifact envelope, exact inputs, proof state, stable handoff outputs, and assumptions:
Scope and current authority:
Adapter matrix:
- platform/territory/audience
- allowed native surface and policy proof
- meaningful-value event and neutral eligibility
- suppression, cooldown, no-display, error, and offline behavior
Request state machine and persisted fields:
Prohibited couplings and audit findings:
Sibling handoffs:
Validation, unresolved authority, and next proof:
What ships with it: 3 files
15.4 KB alongside SKILL.md
agents/
- openai.yaml321 B