Menú
Build reputation-safe open-source marketing from verifiable project evidence, not hype, spam, or repeated public pings. Use for launch copy, directory targeting, community posts, proof packets, and maintainer-facing positioning.
Use this skill to monitor and verify a deployed URL or public OSS launch surface after releases — checks HTTP endpoints, SSE streams, static assets, console errors, performance regressions, PR queue health, maintainer feedback, and listing-review blockers after deploys, merges, submissions, or dependency upgrades. Smoke / canary / post-deploy / PR-watch verification.
Turn public launch, directory, community, or list rejections into repo fixes and better proof without arguing, spamming, or resubmitting blindly. Use after Hacker News, Product Hunt, GitHub list PR, marketplace, or community rejection.
Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports.
Build an evidence-backed ecc install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ecc should be trimmed to what a project actually needs instead of loading the full bundle.
Build a source-derived writing style profile from real posts, essays, launch notes, docs, or site copy, then reuse that profile across content, outreach, and social workflows. Use when the user wants voice consistency without generic AI writing tropes.
Baseline cross-project coding conventions for naming, readability, immutability, and code-quality review. Use detailed frontend or backend skills for framework-specific patterns.
| name | proof-led-oss-marketing |
| description | Build reputation-safe open-source marketing from verifiable project evidence, not hype, spam, or repeated public pings. Use for launch copy, directory targeting, community posts, proof packets, and maintainer-facing positioning. |
| origin | eoc |
Use this skill when an open-source project needs attention without damaging trust. The job is to turn real validation, docs, CI, screenshots, usage, and maintainer behavior into credible distribution.
Follow this order when instructions conflict:
Public-action carve-outs: zero inside this skill for public posting, form submission, listing PR creation, account actions, or paid placement. This skill always stops at an evidence report and draft copy.
Allowed action carve-outs: zero inside this skill.
Conflict behavior: when a requested action conflicts with the ordered rules above, stop after the evidence report and name the conflicting rule.
This skill does not define or call tools directly. If tools are needed, use only
the active runtime tool schema and treat missing authentication or low confidence
as improve first or watch, not as permission to guess.
Own the marketing plan and proof packet.
Excluded actions:
Prefer one strong, cited claim over five vague claims.
Before recommending channels, fill these fields:
If the user does not specify the context, explicitly state these defaults:
If a target depends on unknown local market, budget, account permission, or
private community access, classify it as watch until that context is verified.
Approval contract: channel analysis is acceptable only when the Decision Context table includes market, budget, user preference, timing, constraints, and ranking criteria as either sourced facts or intentionally stated defaults.
Before editing repo files, state the target surface and rollback path.
Allowed edits from this skill are limited to durable marketing surfaces such as README copy, public-review docs, screenshots, release notes, skill guidance, and tests that verify those claims.
Excluded technical changes from this skill:
Verification must include the relevant docs tests, catalog checks when counts change, PromptGuard for prompt-like files, and a final diff summary.
Classify every claim by the strongest available proof:
| Level | Proof | Example |
|---|---|---|
| L0 | Intent only | roadmap, idea, draft |
| L1 | Repo proof | README, docs, commands, examples |
| L2 | Verification proof | CI run, tests, audit report, screenshots |
| L3 | External proof | accepted listing, user issue, maintainer review |
| L4 | Adoption proof | stars, installs, forks, real users, case study |
L0 claims stay labeled L0; L3 or L4 wording requires L3 or L4 proof.
publish: enough proof, correct audience, no active blocker.improve first: proof exists but the repo surface is weak.watch: no action needed or review is pending.skip: wrong audience, paid gate, duplicate, or spam risk.Produce this table before writing copy:
| Claim | Proof | Level | Risk |
|---|---|---|---|
| What we want to say | URL, file, command, or screenshot | L0-L4 | What could be challenged |
If a claim has no proof, either remove it or turn it into a roadmap statement.
Return exactly these fields. Status must be one of publish, improve first,
watch, or skip.
## Proof-Led OSS Marketing
Status: publish | improve first | watch | skip
### Proof Packet
| Claim | Proof | Level | Risk |
| --- | --- | --- | --- |
### Decision Context
| Field | Value | Source |
| --- | --- | --- |
| Market | developer and open-source maintainer audiences | sourced or defaulted |
| Budget | no paid placement or sponsorship | sourced or defaulted |
| User preference | reputation-safe proof over maximum reach | sourced or defaulted |
| Timing | current repo state on the audit date | sourced or defaulted |
| Constraints | maintainer rules and must-avoid options | sourced or defaulted |
| Ranking criteria | category fit, proof level, maintainer rules, audience size | sourced or defaulted |
### Candidate Channels
| Channel | Fit | Action | Reason |
| --- | --- | --- | --- |
### Copy Draft
[short draft]
### Guardrails
- [specific no-spam or proof limits]