skills/cali-product-workflow/skills-domain-libraries/cali-product-marketplace-playbook/SKILL.md
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.
npx skillsauth add renatocaliari/agent-sync-public-skills cali-product-marketplace-playbookInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
tools
Auto-initialize structured documentation for any project using lat.md (knowledge graph of markdown files with [[wiki links]], // @lat: code refs, and semantic search). Detects cali-product-workflow artifacts (spec-product.md, spec-tech.md, critiques) and uses them as seed material. Falls back to extracting business rules, architecture, and design decisions directly from the codebase. Use when a project lacks structured documentation or when lat.md/ is missing. After seeding, lat.md extension hooks keep documentation alive automatically.
testing
[Cali] Server security audit and hardening for private servers behind Tailscale. Use when: auditing server security, hardening SSH/firewall/Docker, checking for vulnerabilities, setting up fail2ban, reviewing port exposure, or responding to security alerts. Covers 6 layers: CloudFlare, UFW, Tailscale, SSH, Docker, Application. Triggers: "server security", "security audit", "harden server", "SSH hardening", "firewall rules", "UFW config", "fail2ban", "port security", "Docker security", "vulnerability check", "security review".
tools
Run supply chain security scans before installing packages or before releases. Triggers when: user installs a package (npm, pip, go get, brew), user asks to 'scan dependencies', 'check vulnerabilities', 'supply chain', 'security audit', 'run trivy', 'run socket', or before any release/deployment. Also triggers on mentions of: socket.dev, trivy, OSV-scanner, dotenvx, CVE, dependency audit. Covers all four tools with concrete commands.
tools
Create GitHub releases following project conventions. Triggers when: user says 'release', 'create release', 'push release', 'deploy to main', 'merge to main', user merges a PR to main, or when git push to main is detected. Also triggers on mentions of: gh release, semver, version bump, changelog, release-please. Covers: config-driven (read .release.yml and execute) and fallback (gh CLI) release flows, versioning rules, tag management, and the mandatory release-on-merge convention.