feat: repo/org-specific review tool config for pr-review

[cardene777]

Summary

The existing pr-review workflow assumes a single review agent / trigger across repositories, but in practice the review tool differs by organization and repository.

A concrete example:

• Borderless-company/Borderless-Contract uses Gemini review, triggered with @gemini review
• other repositories may use a different reviewer / trigger phrase

Because of this, the current flow is brittle:

• the wrong review command can be posted
• follow-up polling may look for the wrong reviewer account
• the automation cannot reliably complete the review-fix-review loop across multiple repos

Proposal

Add repository-aware review tool configuration to pr-review so the workflow can choose the correct reviewer and trigger phrase based on org/repo context.

Examples of configuration shape:

• review provider / reviewer identity
• trigger comment text (for example @gemini review)
• how to detect review results (review author, comments, thread matching rules)
• optional fallback/default provider when no repo-specific config exists

Desired behavior

1. pr-review resolves the active repository context.
2. It loads the review-tool config for that repo or organization.
3. It posts the correct trigger comment automatically.
4. It polls the correct reviewer output.
5. It continues the fix -> push -> re-review loop without repo-specific manual intervention.

Why this matters

This is not just a wording issue. The review loop currently depends on hardcoded assumptions about which review agent is in use. In multi-org setups, that breaks automation and forces manual correction.

Supporting repo/org-specific review tools would make pr-review reusable across teams that standardize on different reviewers, such as Gemini in one org and a different agent elsewhere.

Scope suggestion

A good first version would support:

• global default reviewer config
• organization-level override
• repository-level override
• clear docs for how to configure trigger phrases and reviewer matching

Example target case

For Borderless-company/Borderless-Contract, pr-review should know to use Gemini-specific behavior instead of assuming the default reviewer.

[raysonmeng]

Thanks for the detailed write-up, and apologies for the slow first response.

The need is legitimate: a single hard-coded reviewer/trigger assumption doesn't survive contact with multi-org reality (your @gemini review example is a good concrete case). Status on our side:

• AgentBridge now has a per-project config file (.agentbridge/config.json, read by config-service at startup) — that's the natural home for a review section mapping repo/org → reviewer tool, trigger phrase, and the account to poll for verdicts.
• The recent release train (feat: integration-test → master — multi-pair + P0a–P5 reliability hardening (12-round cross-review) #94–fix: 全项目稳定性加固（drift 复用 / 消息不丢失 / kill·doctor 可读化）/ stability hardening #101) was entirely stability-focused, so this hasn't been scheduled yet. It stays on the backlog as a config-driven enhancement rather than a workflow rewrite.

If you want to accelerate it: a proposed config schema (what fields you'd need for the Gemini case vs. the default) in this thread would make the eventual implementation mostly mechanical.

中文摘要：需求成立；.agentbridge/config.json 已存在，是 per-repo review 工具配置的天然落点；近期版本聚焦稳定性尚未排期，欢迎在本 thread 提议 schema 以加速落地。