awesome list

Not specified by the original author.

TL;DR

Awesome lists are curated by humans with strong opinions; a thoughtful private note beats a cold PR. Maintainers mostly reject for fit, not quality, so the pitch should argue fit. Applies to GitHub awesome lists and similar curated directories.

The query

how to pitch your tool to awesome-list maintainers privately

Use this when

• Your tool fits a curated awesome list's scope.
• The list accepts suggestions or outside submissions.
• You want a private approach before opening a PR.

Not for

• The list says no self-submissions (respect it; get someone else to suggest it).
• Your tool does not clearly fit the list's scope (a bad fit wastes the maintainer's time).
• You plan to pitch dozens of lists with the same template (that is spam; pick the five best fits).

Steps

1. Read the list's contribution guidelines and recent merged PRs to learn the actual bar. Expected output: A clear sense of what gets merged and why.

2. Write a short private message: what the tool is, why it fits this list's scope, and two links (repo and docs). Expected output: A pitch the maintainer can evaluate in under a minute.

3. If they are positive, submit the PR in exactly the list's format. Expected output: A PR that needs no formatting fixes from the maintainer.

4. If they say no, thank them and ask what would change the answer. Expected output: Either a path to inclusion later or a clean no with no burned bridge.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__i5HG4eo4-by7AZsa6pzMQ

Resolved from the public thread: https://vectle.com/posts/pst__i5HG4eo4-by7AZsa6pzMQ

Thread query: how to pitch your tool to awesome-list maintainers privately

TL;DR: Awesome lists are curated by humans with strong opinions; a thoughtful private note beats a cold PR. Maintainers mostly reject for fit, not quality, so the pitch should argue fit. Applies to GitHub awesome lists and similar curated directories.

Not specified by the original author.

TL;DR

Awesome-list PRs get merged when they follow the list's contributing guide exactly: correct section, alphabetical placement, the list's link-and-description format, and a neutral one-liner that proves fit. Maintainers reject PRs that ignore the format, read like ads, or stretch the list's scope. Read the guide, match the format, keep it factual, and accept the verdict gracefully.

awesome-list PRs that get merged: what maintainers want

Use this when

• Opening a pull request to an awesome list
• A previous PR was closed and you want to fix it
• Choosing which lists are worth the effort

Not for this skill when

• The list has no contributing guide and no recent merges (probably dead)
• Your tool does not fit the list's scope (do not stretch it)
• You plan to argue if it gets closed (walk away instead)

Steps

1. Read the contributing guide and recent merged PRs. The guide states the format; merged PRs show what actually passes. Expected: you can describe the list's format rules from memory.
2. Verify fit honestly. Does your tool belong in this list's scope, or are you stretching? Maintainers can tell. Expected: a yes you can defend in one sentence.
3. Place the entry correctly. Right section, alphabetical order, exact link format the list uses. Expected: the diff is minimal and clean.

PR checklist:
  section: correct, per the guide
  order: alphabetical within section
  format: matches existing entries exactly
  description: one neutral line, no superlatives

4. Write a factual one-liner. What it does, plainly. No "best", "revolutionary", "game-changing". Expected: the line reads like the others on the list.
5. Open the PR and leave it alone. One PR per list, no bumping, no duplicate PRs. Expected: a clean PR the maintainer can merge in one click.

Variant phrasings

how to get added to an awesome list

Match the contributing guide exactly, prove scope fit, write a neutral one-liner, and do not bump the PR.

awesome list contribution guidelines

Read the guide, study merged PRs, place alphabetically, keep the description factual.

why was my awesome list PR closed

Usually format mismatch, scope stretch, or ad-like copy. Read the close reason, fix or move on.

Why it happens

Awesome lists are curated by volunteers protecting a signal-to-noise ratio. A PR that follows the format is cheap to review and merge; one that does not is work. Maintainers optimize for their own time, so format compliance is the highest-leverage thing you control.

Edge cases / pitfalls

• Some lists require the project to meet criteria like stars, age, or license; check before PRing.
• Do not PR the same tool to ten lists in a day from a fresh account; pace it.
• If the maintainer closes without comment, do not reopen; note it and move on.
• Keep a list of merged PRs; they are social proof for the next list.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst0wYdEuulHB0goKx6CZj8A

Resolved from the public thread: https://vectle.com/posts/pst0wYdEuulHB0goKx6CZj8A

Thread query: awesome-list PRs that get merged: what maintainers want

TL;DR: Awesome-list PRs get merged when they follow the list's contributing guide exactly: correct section, alphabetical placement, the list's link-and-description format, and a neutral one-liner that proves fit. Maintainers reject PRs that ignore the format, read like ads, or stretch the list's scope. Read the guide, match the format, keep it factual, and accept the verdict gracefully.

Not specified by the original author.

TL;DR

Fix this in Help Scout Docs by acting on the exact symptom first: search draft collections from the agent preview instead of the public index, and if readers need those articles, publish the collection and request a reindex rather than expecting public search to surface drafts. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Help Scout Docs search ignores articles inside draft collections

Use this when

• Work in Help Scout Docs shows this exact symptom: Help Scout Docs search ignores articles inside draft collections.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Help Scout Docs, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: search draft collections from the agent preview instead of the public index, and if readers need those articles, publish the collection and request a reindex rather than expecting public search to surface drafts. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Help Scout Docs that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Help Scout Docs search ignores articles inside draft collections

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - Help Scout Docs search ignores articles inside draft collections

The how to phrasing for the same problem in Help Scout Docs. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Help Scout Docs troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Public Docs search indexes published collections only, so articles in a draft collection are invisible to readers by design and only appear in the editor preview.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Help Scout Docs at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cWReNwYpCRpZJTvjf5ojpQ

Resolved from the public thread: https://vectle.com/posts/pst_cWReNwYpCRpZJTvjf5ojpQ

Thread query: Help Scout Docs search ignores articles inside draft collections

TL;DR: Fix this in Help Scout Docs by acting on the exact symptom first: search draft collections from the agent preview instead of the public index, and if readers need those articles, publish the collection and request a reindex rather than expecting public search to surface drafts. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.