← 返回 Skill 列表
extension
分类: 数据与分析无需 API Key

游戏雷达

当你需要判断“什么正在变热、为什么会传播、哪些玩法值得借鉴”时,推荐使用 game-trend-radar。它会从商店榜单、市场报告、创作者内容、直播、玩家社区和 UGC 等多类信号出发,交叉验证趋势是否真实、持续且可迁移,避免把单日榜单或一次性爆款误判为长期机会;最终按证据等级整理候选游戏、玩法机制和产品方向,并同时标出来源、数据口径、适用边界与尚未覆盖的风险盲区。

person作者: user_5a1da646hubcommunity

Game Trend Radar

Build an evidence-graded trend radar, not a pretend global ranking. Separate discovery signals from validated popularity and distinguish market performance, natural propagation, community activity, gameplay characteristics, and recommendation rationale.

Start

  1. Resolve the requested time window using Time Window Rules below. If absent, use the six months ending today.
  2. Define the requested genres, audiences, regions, platforms, time horizon, and exclusions. Use project or implementation constraints only when the user explicitly supplies them as part of the research question.
  3. Run scripts/radar-doctor.sh to learn which channels are available. Do not install tools, import cookies, or change authentication unless the user authorizes it.
  4. Read references/source-map.md before collecting data.
  5. Read references/evidence-and-scoring.md before validating claims or ranking candidates.
  6. Read references/report-template.md before composing the result.
  7. When delivering HTML, also read references/html-report.md.

Use an installed web/social research skill such as agent-reach for channel-specific access. Follow its current instructions because platform commands and authentication change frequently.

Time Window Rules

Treat time as an explicit research parameter, independent of report mode, region, platform, or genre.

  1. Prefer an exact user-supplied start and end date. Interpret both endpoints as inclusive unless the user says otherwise.
  2. Support rolling windows such as 最近 7 天, 最近一周, 最近 30 天, 最近一个月, 最近一个季度, 最近半年, and 最近一年. End them on the current local date. Treat 最近一周 as 7 inclusive calendar days. For named rolling months, subtract 1, 3, 6, or 12 calendar months while preserving the day number where possible; clamp to the target month's last day when necessary. This preserves the existing default convention, for example 2026-02-13 through 2026-08-13.
  3. Support natural calendar periods such as 本周, 上周, 2026 年 7 月, 上个月, 2025 Q4, 上季度, 2025 上半年, and 2024 年. Resolve them to that calendar period's exact boundaries, not a rolling duration. Use Monday through Sunday for calendar weeks and standard quarters: Q1 January through March, Q2 April through June, Q3 July through September, and Q4 October through December.
  4. Support arbitrary historical intervals. Do not assume a scan must begin from the present.
  5. If the user gives a duration without an anchor, anchor it to today. If the user gives an anchor such as 截至 2025-06-30 的三个月, end the rolling interval on that date.
  6. If no time request exists, or the user only says 最近, 近期, 当前趋势, or equivalent without a duration, use the default rolling six-month window ending today. State that the default was applied and print exact dates.
  7. Ask for clarification only when the user supplied a time constraint whose materially different interpretations cannot use the default safely, such as whether an otherwise unanchored 季度 means a natural quarter or rolling three months. Prefer explicit wording already present in the request.

Record these normalized fields in the internal brief and final report:

  • window_start: inclusive YYYY-MM-DD
  • window_end: inclusive YYYY-MM-DD
  • window_kind: rolling, calendar, or custom
  • window_label: the user's wording or a concise normalized label
  • as_of: the date the research was performed

Use the resolved window in search queries, source filtering, candidate inclusion, comparisons, report headings, and citations. A source published outside the window may provide retrospective evidence, but its measured event or metric period must overlap the target window and the exception must be explicit.

Research Workflow

1. Frame the Radar

Write a compact internal brief containing:

  • Exact start and end dates
  • Window kind, label, and research as-of date
  • Included regions and platforms
  • Operational definition of casual game or minigame
  • Research constraints and explicit exclusions
  • Required deliverable: discovery list, trend analysis, recommendations, or all three

Do not equate distribution format with gameplay weight. A WeChat, Roblox, Telegram, or Fortnite experience may be a heavy RPG or economy even if its container is called a minigame.

2. Scan Broadly

Cover both domestic and international sources and at least five independent signal families when available:

  • Store and platform charts
  • Market intelligence and trade reporting
  • Creator video and livestreaming
  • Player communities and social discussion
  • Web, UGC, indie, and game-jam discovery surfaces
  • Advertising creatives and publisher LiveOps materials

Search by game name, mechanic, audience intent, and region. Search in local languages where useful. Capture surprising adjacent genres; do not start with a fixed taxonomy and merely confirm it.

Treat each observation as a lead until validated. Store temporary notes outside the user's repository unless the user requests a durable artifact.

3. Validate Deeply

For each serious candidate:

  1. Resolve the canonical game name, developer, platform, region, release date, and mechanic.
  2. Prefer the platform's original chart or publisher announcement over media rewrites.
  3. Confirm important claims with a second independent signal family.
  4. Record the metric and denominator: downloads, grossing rank, revenue, DAU, CCU, watch hours, video views, post engagement, or chart position.
  5. Record publication date, measured period, and observation date separately. Include a claim only when its measured event or period overlaps the target window.
  6. Label a current chart as a snapshot. Do not use it as evidence for an earlier historical interval or claim persistence beyond its observed span.
  7. For historical scans, prefer archived charts, dated platform records, period reports, contemporaneous posts, and analytics with historical series. State when a platform exposes only current data.
  8. Reject future-dated, circularly sourced, undated, promotional, or internally inconsistent evidence.
  9. Distinguish paid acquisition from organic propagation when data allows.

Never turn search-result frequency, recommendation order, a single viral post, or a one-day chart into a durable popularity claim.

4. Decompose the Game

Analyze the game and its transferable design ideas:

  • First meaningful input and time to comprehension
  • Core action and decision density
  • Round length, reset speed, and failure cost
  • Skill, luck, construction, expression, observation, or communication
  • Solo, synchronous, asynchronous, co-op, party, audience, and agent roles
  • Spectator clarity and clip-generating moments
  • Content structure, technical shape, and moderation implications when observable
  • Meta progression, LiveOps, monetization, and acquisition dependence

Separate a naturally shareable core loop from content generated by guides, progression pressure, spending, redeem codes, or exploits.

5. Synthesize Patterns

Cluster candidates into mechanic families only after collection. Require more than one credible example before calling something a trend. Identify:

  • Cross-region convergence
  • Region-specific packaging
  • New mechanic versus old mechanic with new distribution or Meta
  • Short-lived breakout versus persistent category
  • Commercial success versus strong propagation without proven revenue
  • Popular games whose success depends on factors that do not transfer with the core mechanic

State contradictions instead of forcing consensus between incompatible metrics.

6. Make Recommendations

Recommend games, mechanic families, design ideas, or market opportunities according to the request. For each recommendation specify:

  • What is being recommended
  • Core loop or relevant pattern
  • Why it matters now
  • Supporting evidence and confidence grade
  • Transferable lesson
  • Important limitations, dependencies, or risks

Keep recommendations diverse enough to expose meaningful alternatives. Do not recommend eight variants of the same puzzle merely because that category dominates download charts.

When the user provides a concrete project, budget, team, platform, or prototype deadline, add a separate context-specific recommendation layer. Do not make that layer the default purpose of the radar.

Integrity Rules

  • Cite direct URLs and publication or observation dates for consequential claims.
  • Use exact numbers only when the source exposes them; otherwise use bounded qualitative language.
  • Keep evidence grade separate from recommendation strength.
  • Mark access failures and blind spots explicitly. Never imply direct access to a platform that was unavailable.
  • Treat social search as sampling, not census data.
  • Exclude games outside the requested research boundary even when commercially successful.
  • Do not modify a project or publish research unless explicitly asked.
  • End with what the radar cannot establish and what the next scan should verify.

Output Modes

  • Quick scan: 8-12 mechanic families, strongest examples, evidence grades, and prioritized recommendations for the resolved window.
  • Full radar: methodology, source coverage, 20-30 candidate matrix, regional comparison, commercialization, recommendations, exclusions, and blind spots.
  • Delta scan: compare against a prior radar; identify new entrants, persistence, decline, and revised confidence. Preserve the previous observation date.
  • Single-mechanic deep dive: trace origins, variants, audiences, monetization, creator propagation, and transferable design ideas.
  • HTML report: deliver the requested radar as a polished, self-contained interactive report with visible evidence grades, source links, filters, and responsive reading behavior.