Skip to content

Scribe agent: support multiple target repositories per run #895

@ascerra

Description

@ascerra

What happens

The scribe agent currently supports a single SCRIBE_TARGET_REPO value — one owner/repo string per workflow run. The pre-script fetches the issue backlog from that one repo, the LLM matches topics against those issues, and the post-script writes comments and new issues to that one repo.

This works for the fullsend-ai org where the team sync maps cleanly to the fullsend-ai/fullsend repo. It does not work for orgs like konflux-ci where a single community meeting covers topics spanning 100+ repos and no single repo is the right target for all topics.

What should happen

The scribe agent should accept a list of target repositories and route each extracted topic to the appropriate repo. The LLM already has enough context to make this decision — it matches topics to existing issues. If the backlog context includes issues from multiple repos, the LLM can determine which repo each topic belongs to.

Concretely:

  1. Configuration: Accept a comma-separated list or YAML array of target repos (e.g., SCRIBE_TARGET_REPOS=konflux-ci/build-service,konflux-ci/integration-service,konflux-ci/release-service). Fall back to SCRIBE_TARGET_REPO (singular) for backward compatibility.
  2. Pre-script: Fetch the open issue backlog from all listed repos. Tag each issue with its source repo in the context passed to the LLM.
  3. Agent prompt: Extend the output schema so each topic includes a target_repo field. The LLM picks the best-fit repo from the configured list based on issue matching. New issues that don't match any existing issue backlog need a repo assignment — the LLM should pick the closest match or a configured default.
  4. Post-script: Route each comment and new issue to the target_repo specified in the agent output. Validate that the value is in the configured allowlist before writing.

Context

This is the primary blocker for enabling scribe on the konflux-ci org for the community meeting. The meeting covers cross-cutting topics that span build-service, integration-service, release-service, and other repos. Filing everything into a single catch-all repo defeats the purpose of connecting meeting decisions to the relevant issue backlogs.

The cross-org authentication problem (#402) is orthogonal — this feature is about routing within a single org where the GitHub Apps already have access to all target repos. The credential model does not need to change; the triage app token generated with owner: ${{ github.repository_owner }} already has issues:write across the org.

Open questions

  • Should there be a maximum number of target repos? More repos means a larger backlog context for the LLM, which affects token cost and may degrade matching quality.
  • How should new issues be routed when no existing issue matches? Options: a configured default repo, the LLM picks the closest-fit repo, or the topic is omitted with an omit_reason.
  • Should the pre-script fetch the same number of issues per repo (e.g., 50 each) or a global limit distributed by repo activity?
  • Does the public_safe gate need any changes? The security model should be identical — each repo gets the same deterministic checks.

Related

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions