Time suggestions to your release cycle

A documentation suggestion is only useful when it arrives at the right moment. Draft it too early and you document work your reviewers haven’t finished. Draft it too late and the docs trail the release. To get the timing right, align the event that triggers Promptless — and the moment docs publish — with the point in your release cycle when the change becomes real.

There’s no separate “timing” setting to configure. You control timing by choosing which event triggers Promptless and how eagerly it publishes, using the trigger and policy fields you already have.

Match the trigger event to your release stage

On the Configuration page, open the Triggers tab and expand your GitHub pull request trigger. Under When should Promptless run?, pick at least one moment in a pull request’s life. That choice decides how finished a change is when Promptless analyzes it, since each option maps to a stage in the change’s life:

Option	Fires when	Choose it when
When it’s opened (default)	A pull request opens	You want documentation drafted alongside the code, so reviewers evaluate both together.
When it’s first approved	A pull request gets its first approval	You want to wait until a reviewer has vetted the change, so Promptless analyzes reviewed work rather than a work in progress.
When it’s merged	A pull request merges	You only want documentation for changes that have actually made it into the code base.

If suggestions keep arriving before a change has settled, switch from When it’s opened to When it’s first approved, or from When it’s first approved to When it’s merged. Turn on more than one when you want both early feedback and a post-merge refresh. See GitHub PRs → Trigger modes for the full behavior of each mode, and the Configuration Reference for the underlying trigger_on field.

Note

When it’s first approved fires once per pull request, on the first approval only. Later approvals or re-approvals after requested changes don’t trigger another run. If you merge your own pull requests without a separate reviewer, it never fires — use When it’s merged or a commit trigger instead.

Document only what has shipped

To track shipped changes rather than proposed ones, add a commit trigger, which fires when commits land on a monitored branch. On the Triggers tab, add a rule for a GitHub commit trigger and point it at the branch you want to watch. Pair it with your PR trigger to get both timings: Promptless comments on pull requests while they’re open, then refreshes the suggestion with the final content once the change merges to your default branch.

Using commits on their own — without a PR trigger — is the quietest option. Promptless runs only after changes reach your default branch, so it fires less often.

Control when a suggestion publishes

Trigger timing decides when Promptless drafts; publishing policies decide when it ships. By default, a suggestion waits for a human to review and publish it. You change that on the Policies tab of the Configuration page. The defaults there apply to every suggestion, and a rule can override them for a specific trigger or doc collection.

When a class of change should publish without waiting for review, add a rule scoped to a trigger you trust, turn on Open a pull request automatically, and turn on Merge the pull request automatically. With both on, the documentation PR merges the moment it’s created, so no one intercepts it first — which is why auto-merge depends on automatic PR creation. This fits high-confidence workflows, like internal documentation or changelog updates you want live as soon as the change lands. Scoping the rule to a single trigger keeps full automation where you trust it and leaves everything else waiting for review. For the full list of policy fields and defaults, see the Configuration Reference.

Note

Publishing policies resolve at publish time, not when the trigger fires. If you change a policy while a suggestion is being drafted, the new values apply when that suggestion is published.

Trigger from a feature-flag rollout

When a feature ships behind a flag, the pull request can merge weeks before users see the change, so PR- and commit-based timing may draft the docs long before they’re relevant. The LaunchDarkly integration closes that gap. Once connected, Promptless watches for feature-flag changes in your LaunchDarkly projects and starts documentation work when a flag changes, rather than when the code merged.

That makes the flag rollout, not the merge, the moment documentation updates, matching how flagged features actually reach users.

Note

The LaunchDarkly integration is in beta. Connect it from the integrations page. See the LaunchDarkly integration guide for the setup and permissions it needs.

Trigger from a deploy or release pipeline

If your release stage lives in a CI/CD pipeline rather than a pull request or a flag, the API trigger lets any system request documentation work over HTTP. A deploy step can call Promptless after a release completes and pass release context with the request, so the docs update on the same event that ships the product.

curl -X POST "https://api.gopromptless.ai/triggers" \
  -H "Authorization: Bearer sk-pl-your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "instructions": "Document the rate limiting feature released in v2.5.",
    "context": { "release": "v2.5.0" }
  }'

The context object is optional metadata that appears in the trigger’s history for reference. See API triggers for the full request format.

Tip

These inputs combine. Most teams start by matching trigger_on to their review stage, then add a flag-based or pipeline-based trigger for the features whose release moment isn’t the merge. The goal stays the same throughout: documentation that lands when the change is real to your users.