Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问许可证需确认审计通过

marketplace-liquidity市场流动性

Agent Skill

marketplace-liquidity 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

776

周安装

33

GitHub Stars

3

下载量

272
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:marketplace-liquidity(市场流动性)
来源仓库:https://github.com/oldwinter/skills
仓库路径:skills/marketplace-liquidity
安装命令:
npx skills add https://github.com/oldwinter/skills --skill marketplace-liquidity
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/oldwinter/skills --skill marketplace-liquidity

简介

marketplace-liquidity 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词快速定位候选结果。

  • 适用于需要基于任务场景或来源线索进行信息筛选的场景。
  • 通过 npx skills add 命令从指定仓库安装,需结合原始 README 核验具体用法。
  • 安装前建议确认权限范围、维护状态,以及是否会触发联网或文件读写。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

Marketplace Liquidity Management

Scope

Covers

  • Defining liquidity as reliability: how often a user can complete the marketplace’s core action (find → match → transact) within an acceptable time and quality threshold
  • Measuring liquidity where it actually happens (by “local markets” like geo × category × time window), not just in global averages
  • Diagnosing liquidity failure modes: fragmentation, supply–demand imbalance (“flip-flop”), matching/mechanics issues, and quality/trust breakdowns
  • Designing a practical liquidity operating system: scorecards, weekly review cadence, and a “whac-a-mole” rebalancing plan (move attention/inventory/incentives)
  • Producing an actionable experiment backlog to improve liquidity (supply, demand, matching, pricing/incentives, trust & safety)

When to use

  • “We need to improve marketplace liquidity / match rate / fill rate”
  • “Time-to-match is too slow” / “buyers can’t find availability”
  • “Supply and demand are imbalanced across cities/categories”
  • “Our marketplace feels unreliable” / “conversion drops due to no availability”
  • “We need a liquidity dashboard + operating cadence + experiments”

When NOT to use

  • You don’t operate a two-sided marketplace (no matching between supply and demand).
  • The primary problem is value proposition / ICP (use problem-definition or measuring-product-market-fit).
  • You only need pricing changes (use a pricing strategy skill) without a liquidity diagnosis.
  • You need a general growth plan unrelated to matching reliability (use designing-growth-loops / retention-engagement).

Inputs

Minimum required

  • Marketplace type + sides (who are “buyers” and “sellers”)
  • The core action you consider a successful outcome (e.g., request → booked; search → purchase; message → hire)
  • Top 1–3 priority segments (geo/category/user cohort) and the time window you care about
  • Best-available baseline metrics (even if rough): demand volume, supply availability, match/fill rate, time-to-match, cancellations/quality
  • Constraints: budget, incentives you can/can’t use, policy/brand/trust, engineering capacity, timebox

Missing-info strategy

  • Ask up to 5 questions from references/INTAKE.md, then proceed.
  • If data is missing, proceed with explicit assumptions and label confidence.
  • Do not request secrets or PII; prefer aggregated metrics or redacted examples.

Outputs (deliverables)

Produce a Marketplace Liquidity Management Pack (Markdown in-chat; or as files if requested) containing:

  1. Context snapshot (goal, timebox, segments, constraints, decision this informs)
  2. Liquidity definition + thresholds (reliability definition and “good enough” targets)
  3. Liquidity metric tree (north-star + driver metrics, with event definitions)
  4. Fragmentation map + segment scorecard (where liquidity is weak/strong; the “local markets” that matter)
  5. Bottleneck diagnosis (supply vs demand vs matching/mechanics vs quality; include “flip-flop” state)
  6. Intervention plan + prioritized experiment backlog (including reallocation/“whac-a-mole” plan)
  7. Measurement + instrumentation plan (dashboards, alerts, tracking gaps)
  8. Operating cadence (weekly liquidity review agenda + owners)
  9. Risks / Open questions / Next steps (always included)

Templates and expanded guidance:

Workflow (7 steps)

1) Intake + define the decision and local market(s)

  • Inputs: User context; references/INTAKE.md.
  • Actions: Clarify the goal (metric + target + by when), define the core action, pick the “local market” unit (e.g., city × category × week), and decide the decision this work will inform (what you’ll do differently).
  • Outputs: Context snapshot + local market definition.
  • Checks: A stakeholder can answer: “Which segment(s) improve by how much, by when, and what will we change based on the result?”

2) Define liquidity as reliability + set thresholds

  • Inputs: Core action, time sensitivity, quality constraints (cancellations, refunds, etc.).
  • Actions: Define liquidity as the probability of success within thresholds (time-to-match, quality). Choose 1 north-star liquidity metric and 3–6 drivers (fill rate/match rate, time-to-match, availability, acceptance, cancellation).
  • Outputs: Liquidity definition + “good enough” targets + metric tree outline.
  • Checks: The definition is measurable, segmentable, and aligned to the user’s experience (“reliability”).

3) Build a segment scorecard + diagnose fragmentation

  • Inputs: Baseline data by geo/category/time window (best available).
  • Actions: Create a segment scorecard for each local market: demand, supply, matching, and quality metrics. Identify fragmentation (thin markets, long tail categories, uneven geo distribution) and “uniform needs” vs heterogeneous needs.
  • Outputs: Fragmentation map + ranked list of worst segments (where liquidity blocks growth).
  • Checks: The scorecard avoids global averages and includes enough volume to be meaningful (or flags low-confidence segments).

4) Diagnose bottlenecks (flip-flop + mechanics + quality)

  • Inputs: Segment scorecard; any qualitative evidence (support tickets, user feedback, ops notes).
  • Actions: For each priority segment, label the primary failure mode:

- Supply-limited (not enough availability/inventory) - Demand-limited (not enough intent/requests) - Matching/mechanics-limited (ranking, discovery, response time, pricing friction) - Quality/trust-limited (cancellations, no-shows, fraud, low ratings) Also check for the “flip-flop” dynamic (which side is currently the constraint) and the graduation problem (top suppliers leaving).

  • Outputs: Bottleneck diagnosis per segment + evidence notes.
  • Checks: Each diagnosis includes at least 1 metric signal and 1 plausible causal story you can test.

5) Generate interventions + experiment backlog (including reallocation)

  • Inputs: Bottleneck diagnosis; constraints; available levers.
  • Actions: Create intervention options for each bottleneck type (supply, demand, mechanics, quality). Include a “whac-a-mole” plan: how you will reallocate attention/inventory/incentives across segments weekly. Convert interventions into experiments with clear hypotheses and success metrics.
  • Outputs: Prioritized experiment backlog + reallocation playbook.
  • Checks: Every experiment has (a) a segment, (b) a primary metric, (c) a target effect size or directional expectation, and (d) a plausible cycle time.

6) Design measurement + liquidity operating cadence

  • Inputs: Chosen metrics and experiments.
  • Actions: Specify dashboards/alerts, event definitions, and instrumentation gaps. Create a weekly liquidity review agenda and decision log (what gets rebalanced, what gets shut down, what gets scaled).
  • Outputs: Measurement plan + operating cadence (owners if known).
  • Checks: Each key metric is tied to a data source and update frequency; the cadence produces concrete decisions, not status updates.

7) Quality gate + finalize the pack

  • Inputs: Draft pack; references/CHECKLISTS.md and references/RUBRIC.md.
  • Actions: Run the checklist and score with the rubric. Tighten the pack until it is specific, segment-aware, and testable. Always include Risks / Open questions / Next steps.
  • Outputs: Final Marketplace Liquidity Management Pack.
  • Checks: The next 2 weeks of work are unblocked (data pulls, 1–3 experiments, cadence).

Quality gate (required)

Examples

Example 1 (services marketplace, geo fragmentation): “Use marketplace-liquidity. We run a home cleaning marketplace across 12 cities. Goal: increase booking fill rate from 62% → 80% in 8 weeks in our bottom 4 cities. We suspect supply is thin and response times are slow. Output a Marketplace Liquidity Management Pack with a segment scorecard, bottleneck diagnosis, and a prioritized experiment backlog.”

Example 2 (B2B marketplace, category imbalance): “Use marketplace-liquidity. We match startups with freelance designers. Liquidity is strong in ‘logo design’ but weak in ‘product design’ and ‘brand refresh.’ Goal: cut median time-to-first-qualified-match from 5 days to 2 days for product design in 60 days. Provide a liquidity metric tree, fragmentation map, and operating cadence.”

Boundary example (not a liquidity problem): “Write Google Ads copy to get more buyers.” Response: this is primarily acquisition/copy. If marketplace reliability is already strong, use copywriting / channel-specific growth work. If reliability is unknown, start with an intake to confirm a liquidity bottleneck first.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

38.14%
按下载量换算104

Claude

28.07%
按下载量换算76

Cursor

19.77%
按下载量换算54

Gemini CLI

9.37%
按下载量换算25

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills