Filter noise and tune relevance

The first few days of use decide whether you keep trusting Promptless. If you get suggestions for every internal refactor and config bump, you tune it out. If Promptless stays quiet on the changes that matter, you stop relying on it. Tuning for relevance means narrowing what reaches Promptless in the first place and teaching it, over time, which changes are worth documenting.

Promptless filters at three points, from earliest to latest:

1. What triggers analysis — scope your triggers so only documentation-worthy events reach Promptless.
2. What Promptless skips automatically — built-in filters drop changes that are never documentation-worthy.
3. What you teach it to skip — feedback on suggestions changes what Promptless proposes next time.

Start with trigger scope; it removes the most noise for the least effort.

Scope what triggers analysis

You configure triggers on the Configuration page, where each project defines the events Promptless watches. Narrowing what a project matches is the most direct way to cut noise: a change that never matches a trigger never becomes a suggestion. The settings that matter most for relevance are below, and the Configuration reference documents the full set.

Watch only the directories that change docs

Point a project at the parts of a repository that actually affect documentation. When you create or edit a GitHub project, turn on Choose specific directories to trigger this project and enter the paths you want to watch. Promptless then considers only pull requests that touch those directories and ignores changes elsewhere, so a pull request that touches only tests/ or infra/ no longer produces a suggestion. See GitHub PRs → Directory-specific triggers for the full setup.

Watch only the repositories that matter

If your organization has dozens or hundreds of repositories, most of them never need documentation. Two settings keep a project focused:

• Trigger on repos with certain topics — when editing a GitHub project, turn on this option and enter one or more GitHub topics, such as docs-watch. Promptless triggers on any repository carrying at least one of those topics, so you add or remove a repository by changing its topics in GitHub rather than editing your configuration.
• Exclude noisy repositories — watch a broad set of repositories while carving out the ones that generate noise, so those repositories never trigger a suggestion even when everything else does.

See GitHub PRs → Repository topics for how topic matching works, and the Configuration reference for the exclusion setting.

Trigger later in the release cycle

The event a project triggers on decides how often Promptless runs and how finished a change is when it does. Triggering when a pull request opens runs on every new pull request; waiting for its first approval holds until a reviewer has vetted the change; waiting for merge holds until it ships. Triggering later means fewer, higher-signal runs. Tune what Promptless suggests → Release timing covers how to match the trigger event to your release stage.

Note

Publishing policies change how a suggestion is published — where it notifies, whether it opens a PR — but they can’t stop a suggestion from being created. To keep a change from becoming a suggestion at all, scope the project that would trigger on it.

What Promptless skips automatically

Some changes are never documentation-worthy, so Promptless drops them before it creates a suggestion. You don’t configure these filters because they always apply.

• Draft pull requests. Promptless waits until a pull request is marked ready for review, so work in progress doesn’t generate premature suggestions.
• Tooling-only changes. When a pull request touches only dot-directories (like .github/ or .circleci/) or root-level dot-files (like .gitignore), Promptless skips it — these are CI and tooling changes, not product changes. If the same pull request also touches regular source files, Promptless processes it normally and ignores only the tooling files.
• Changes with no documentation impact. For every triggered event, Promptless assesses whether the change actually needs documentation before it creates a suggestion. A change that touches no documented behavior produces no suggestion.

Note

When Promptless evaluates a change and decides no documentation is needed, that decision appears on the Triggers page in your dashboard, so a missing suggestion reads as a considered “no” rather than a silent miss. See The web interface for where to find it.

Teach Promptless what to skip

Trigger scope handles the coarse cuts. For the judgment calls — a class of change that technically touches docs but that your team never documents — teach Promptless directly. Set standing guidelines up front, and refine them through feedback as suggestions come in.

Write standing guidelines in your Knowledge Base

Some sources mix documentation-worthy signal with noise no filter can catch. When Promptless passively listens to a Slack channel, for example, the same channel carries questions worth capturing and chatter that isn’t. Rather than closing the same kinds of suggestions one by one, tell Promptless what to act on up front by adding guidelines to the PROMPTLESS.md file in your Agent Knowledge Base, which admins edit under Settings. Spell out what to act on, what to ignore, and how to handle the edge cases or team processes that recur:

• “In #support, document answers to how-to questions; ignore status updates and incident chatter.”
• “When a thread resolves a bug, capture the workaround, not the back-and-forth.”
• “Treat any message prefixed with aside as out of scope.”

Promptless reads these guidelines whenever it processes a message in that channel, so it applies your judgment before drafting anything rather than learning it one rejected suggestion at a time.

Close a suggestion with a reason

When a suggestion isn’t worth keeping, close it and pick the reason that fits. The options include several that map directly to noise:

• This change is too insignificant
• This change is self-explanatory and doesn’t need docs
• This change was covered in another Promptless suggestion
• This is already in my docs

Check Remember this feedback for future suggestions so the reason shapes what Promptless proposes next time, not just this once.

Remember a durable preference

Any feedback you give — like closing a suggestion, requesting changes, or leaving a comment — can be saved for the future. Phrase it as a standing rule so Promptless generalizes it:

• “Don’t create suggestions for dependency bumps.”
• “Internal-only tooling changes don’t need docs.”

Promptless records what it learns in your Agent Knowledge Base, so the preference persists across every future suggestion. The full set of feedback channels is documented in Teach conventions with feedback.

Tip

Filtering compounds. Trigger scope removes whole categories of change up front, while feedback refines the judgment calls that slip through. Revisit both after your first week — the suggestions you keep closing point to the next trigger or convention to add.

Quiet the notifications, not the suggestions

Sometimes the suggestions are right but the alerts are too loud. That’s a notification concern, not a relevance one, and you tune it separately. You can turn off the comments Promptless posts on source pull requests and shape when and where it notifies your team in Customize notifications. Those levers change who hears about a suggestion; they don’t change which suggestions Promptless creates.