菜单
Strategies and tactics for stimulating marketplaces by balancing supply and demand. Covers 19 proven tactics from getting the harder side first to creating urgency through constraints.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | stelow-product-marketplace-playbook |
| description | Strategies and tactics for stimulating marketplaces by balancing supply and demand. Covers 19 proven tactics from getting the harder side first to creating urgency through constraints. |
| metadata | {"frequency":"rare","category":"research","context-cost":"low","author":"calionauta","author-url":"https://github.com/calionauta"} |
| disable-model-invocation | true |
Get the harder side first. When the harder side (supply or demand) reaches its critical activity point, network effects kick in and value is created organically for the easier side. Discovering this through the sales and onboarding process, typically the harder side is the most valuable — once you have enough of them, the other side is 2-3 times easier to bring aboard.
Strongly attract to a niche and repeat. Find the small groups in your community that care most about your market ("white-hot center") and go after them. Usually, this is discovered by going broad enough to collect data that shows the most activity.
Subsidize the most valuable side of the market. Pay in cash to the most valuable side of the market — or to the most valuable niche within the most valuable side — to join the marketplace.
Make supply look bigger with automation. Start the supply side by aggregating as much web data as possible to create a "perceived aura of activity".
Build one side as an email list. An easy and cheap way to start a market, especially if many buyers are also sellers and vice versa.
Hold meetups and gatherings. In the beginning, they can be effective for generating community, demonstrating activity, and getting direct customer feedback.
Create a SaaS tool for one side of the market. When you give or sell a SaaS tool to one side of the market, it helps keep them in the market, giving time to attract the other side.
Provide software to third parties who can bring one side of the market.
Find a giant user for initial supply or demand.
Make only one side change their behavior.
Make something free suddenly. Transforming something that used to cost money into something free will attract users.
Create a product first and then open a market.
Connect the two sides manually.
Prefer markets where buyers are also sellers. Avoid building a single-sided market altogether.
Create exclusive access. Restrict access and create fear of missing supply or demand can generate strong word of mouth and rush of participation when the idea goes viral. However, this almost never works.
Define a geographic constraint. It's easier to generate a lot of activity when limiting the operating area at launch.
Define a time constraint. One can program enthusiasm into the market with time constraints.
Define a demand constraint.
Pay users with tokens. If you create a token for the market, you can pay people to join, even when there's no activity.
[Cali] Generate and maintain project AGENTS.md files using semantic analysis. Triggers when: a project has no AGENTS.md, user asks to 'create AGENTS.md', 'generate agents md', 'setup agents md', or when starting work on a project that lacks one. Also triggers when user asks to 'check if AGENTS.md is stale', 'update agents md', or when evolving an existing AGENTS.md. Covers: initial generation from codebase analysis, sem-based staleness detection, pre-commit hooks, and CI guards. Always offer hook installation when invoked for any reason.
[Cali] Validate project AGENTS.md files against best practices and the canonical template. Use when: user says 'validate agents md', 'check agents md quality', 'audit my agents md', or after creating/updating AGENTS.md. Checks: structure, size, content quality, template compliance, and provides fix recommendations. Can offer automatic corrections via ask tool.
[Cali] Tool priority rules for code navigation: Cymbal-first, FFF fallback, batch guidance for token efficiency, and semantic diff workflow. Activates on any file-task within a Git repository to guide agent tool selection.
[Cali] Use this skill whenever the user wants to analyze a codebase and generate a detailed product spec document. Triggers for: "analyze this codebase", "generate a spec", "document this project", "reverse engineer this app", "what does this system do", "create product documentation", "map out the features", "extract product rules from code", "what does this codebase do", "generate product spec from code", "document this app", "spec out this repo", "read this code and tell me what it does", "create a product spec", "reverse engineer the product", "what features does this app have", "document the flows", "extract the prompts from this code", or any request to extract product knowledge from source code. Supports any input method: file uploads, pasted code, filesystem paths, or zip archives. Always use this skill when the user shares code AND wants to understand what the product does — even if they don't explicitly say "spec" or "documentation".
[Cali] Go web stack: Datastar, Templ, DaisyUI, NATS, PocketBase/SQLite, GoAI LLM, Zenflow agents. Scaffold, real-time, hypermedia, auth, DB, embeddings, voice AI, AI agents, durable workflows, queues. Queues use NATS JetStream or goqite. Workflows use go-workflows, turbine, ebind, dagnats, or Hatchet per decision tree below.
Use this skill for any Go (Golang) backend task — writing services, APIs, CLI tools, concurrent code, or reviewing/refactoring existing Go code. Triggers on: any .go file, mention of goroutines, channels, mutexes, Go modules, or requests to build backend systems in Go. Also triggers when setting up linters, running tests, managing Go dependencies, or running the app locally during development.
