Route changes across multiple repos

When organizations juggle a multitude of docs and code repositories, a few questions commonly come up: which code repositories feed which doc sites, how do you keep one team’s changes out of another team’s docs, and how do you work across several GitHub organizations at once? The answer to these questions is to scope each trigger to activate only on the changes that matter and to give Promptless the context it can’t research, like your team preferences. This page shows how those pieces fit together across many repositories.

One repository per doc collection

Each doc collection is tied to a specific documentation repository. Each collection carries its own settings, such as where the repo lives, the docs framework it uses, its default branch, where the docs are published, and any path scopes that limit which files Promptless can modify.

Promptless can publish to multiple doc collections at once, reusing the same trigger events and context sources across different doc sites. When a trigger is relevant to more than one doc collection, Promptless automatically identifies and suggests changes for all applicable docs across suggestions, so related docs stay in sync.

Scope which triggers activate

Routing across many repos comes down to activating the right triggers on the right changes. When you set up a trigger on the Triggers tab of the Configuration page, its filters scope what it watches, so a change in one repo starts documentation work only where you’ve told it to:

Which repositories? — choose All repositories, or pick Specific repos. This is the primary control over which repositories a trigger watches.
Skip these repositories — repositories to leave out, useful when you watch All repositories but want to exclude a few.
Only repos owned by these accounts — restrict a trigger to repositories owned by specific accounts (the owner segment of owner/repo).
Only repos tagged with these GitHub topics — restrict a trigger to repositories carrying specific GitHub topics, so you can opt repos in by topic rather than listing each one.
Only when files in these folders change — activate only when a change touches specific folders, so unrelated changes in the same repo don’t start documentation work.
Only pull requests targeting these branches — activate only for changes targeting specific branches.

Scoping a trigger limits which code changes start documentation work. No setting binds a trigger to a specific collection. Collection targeting is relevance-based, not a configured route. Team separation comes from configuring these levers yourself. Scope each team’s triggers to the repositories it owns, and use each collection’s Only watch these folders path scope to limit which files Promptless can modify. See the Configuration Reference for the full trigger and doc-collection schema.

Work across multiple GitHub organizations

Connect multiple GitHub organizations to one Promptless account when your repositories span more than one org. After connecting the first organization, click Connect another GitHub Org on the Integrations page. Each organization appears as its own card with its own repository list and refresh and disconnect controls. When you create or edit projects, repositories from every connected organization appear in the dropdowns, shown as organization/repository. See the GitHub integration guide for details.

See which collection a suggestion targeted

When suggestions span several collections, the suggestions list makes the target explicit. Each suggestion shows a Docs target chip with a document icon marking which doc collection it targets. Hover over the chip to see the full repository path, or click it to filter the list to suggestions targeting that collection. This is especially useful when your organization has multiple doc collections. See Use the web interface for the rest of the suggestions list.

Apply rules per collection

Publishing and notification behavior can differ by collection. On the Policies tab, add a rule and set its Doc collection condition so the rule applies only to that collection — for example, routing one collection’s announcements to a different Slack channel for new suggestion announcements, or changing Open a pull request automatically for its suggestions. When more than one rule matches, the later one wins, field by field. See the Configuration Reference for the policy schema.

Set per-collection preferences in your Knowledge Base

A policy rule applies based only on a trigger and a doc collection, and it sets only notification, publishing, and archiving fields. Preferences that don’t fit those fields belong in PROMPTLESS.md and other files in your Agent Knowledge Base, which Promptless reads when performing documentation tasks. That’s where each team’s own conventions and exceptions live — the judgment a policy rule has no field for.

In the left sidebar, open Settings and select Agent Knowledge Base. Open PROMPTLESS.md in the editor and click Save. The change commits directly to the repository. Organization admins edit these files, while other members have read-only access. If you’re not an admin, ask Promptless to make the change for you — it edits PROMPTLESS.md and commits the change.

The Knowledge Base is shared across your whole organization, so name the doc collection in each instruction to keep it scoped to that team’s docs. For example:

“Customer-facing guides belong in acme/docs. Keep internal runbooks in acme/internal-docs.”
“Treat reference/ in acme/docs as generated. Its source of truth lives elsewhere, so leave those pages alone.”
“Never revise a released changelog entry in acme/docs. Add a new entry instead.”
“When acme/api-docs changes, check the authentication overview in acme/docs for staleness.”