القائمة
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.
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.
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.
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 | rejection-recovery-loop |
| description | 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. |
| origin | eoc |
Use this skill when a public submission, listing PR, community post, launch surface, or marketplace attempt is rejected, closed, ignored, or blocked.
The goal is not to "win the argument." The goal is to learn exactly what failed, fix the project surface when the criticism is valid, and decide whether to resubmit, wait, or stop.
Follow this order when instructions conflict:
Public-action carve-outs: zero inside this skill for reposting, new-account workarounds, duplicate PRs, public replies, form submissions, or account changes. This skill always stops at a recovery report and optional response draft.
Allowed action carve-outs: zero inside this skill.
Conflict behavior: when a requested action conflicts with the ordered rules above, stop after the recovery 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, hidden moderation state, or unclear rejection text as residual risk.
Before editing repo files, identify the rejected surface, target repo files, and rollback path.
Allowed edits from this skill are limited to durable recovery surfaces such as README copy, attribution notes, screenshots, public-review docs, release notes, skills, and tests that verify the corrected claim.
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 the rejection before taking action:
| Type | Signal | Meaning |
|---|---|---|
| Account gate | permission or eligibility block | account-state blocker |
| Category mismatch | wrong list, wrong section, not enough fit | target-fit blocker |
| Proof gap | asks for users, screenshots, validation, install proof | evidence blocker |
| Quality gap | broken README, unclear install, bad screenshots, CI failure | repo-quality blocker |
| Duplicate | existing PR, existing item, replacement thread | duplicate blocker |
| Policy gate | commercial, affiliate, AI-spam, self-promo rules | policy blocker |
| Maintainer request | concrete requested change | response-worthy blocker |
| Silent close | closed without reason | unverifiable close |
fix and respond: maintainer asked for a concrete change.fix and wait: repo surface was weak but no response is needed.resubmit later: target fit is real, but proof is not ready.skip permanently: target rules or audience fail to fit.A response is justified only when:
Keep it to one comment. Cite the fix. Avoid asking for special treatment.
Return exactly these fields. Status must be one of fix and respond,
fix and wait, resubmit later, or skip permanently.
## Rejection Recovery
Status: fix and respond | fix and wait | resubmit later | skip permanently
### Evidence
| Item | Link or Quote | Meaning |
| --- | --- | --- |
### Classification
[type and reason]
### Repo Fixes
- [specific file, asset, CI, or docs fix]
### Response Draft
[only if justified]
### Residual Risk
- [moderator discretion, maturity gap, missing adoption proof]