Summary
Add a documented extension point so ce-doc-review and ce-code-review can discover and dispatch project-local reviewer personas alongside the built-in catalog.
Motivation
We run an orchestration layer that uses ce-doc-review and ce-code-review as the review step in a CI-triggered coding-agent workflow. Alongside CE's built-in personas, we maintain a couple of org-specific review lenses (an internal-runbook lens and a team-goals lens) that have no CE equivalent. Today, there is no supported way to have the CE skills include them: selection draws only from the fixed persona-catalog.md, and dispatch reads references/personas/<name>.md from inside the plugin. The only way to add ours is to drop files into the version-pinned plugin cache dir, which is wiped on every upgrade.
As a result, we maintain a parallel reviewer-dispatch layer purely to run these extra lenses and merge their findings with CE's — duplicating the fan-out and merge the CE skill already does internally.
Proposal
A discovery convention for project-local personas, for example:
- Read persona files from a project dir (e.g.
.compound-engineering/reviewers/*.md), or a config key in .compound-engineering/config.local.yaml listing extra persona paths.
- Fold discovered personas into Stage 3 selection using the same
<persona-name>.md contract and findings schema that the built-in personas already use.
- Apply the same mid-tier model default unless the persona opts up.
- Optionally, let a project persona declare a lightweight applicability hint (file globs/repo tags) so selection stays deterministic.
Custom personas would just be additional entries in the same catalog, sourced from the project instead of the plugin.
Alternatives considered
- Forking/vendoring the plugin to add personas — breaks on upgrade, high carrying cost.
- Wrapping CE from an outer orchestrator that dispatches custom reviewers separately and merges — duplicates CE's own fan-out/merge and drifts from CE's schema over time (this is what we do today).
Willing to contribute
Happy to open a PR if maintainers are open to the direction — a pointer to the preferred discovery shape (config key vs. directory convention) would help.
Summary
Add a documented extension point so
ce-doc-reviewandce-code-reviewcan discover and dispatch project-local reviewer personas alongside the built-in catalog.Motivation
We run an orchestration layer that uses
ce-doc-reviewandce-code-reviewas the review step in a CI-triggered coding-agent workflow. Alongside CE's built-in personas, we maintain a couple of org-specific review lenses (an internal-runbook lens and a team-goals lens) that have no CE equivalent. Today, there is no supported way to have the CE skills include them: selection draws only from the fixedpersona-catalog.md, and dispatch readsreferences/personas/<name>.mdfrom inside the plugin. The only way to add ours is to drop files into the version-pinned plugin cache dir, which is wiped on every upgrade.As a result, we maintain a parallel reviewer-dispatch layer purely to run these extra lenses and merge their findings with CE's — duplicating the fan-out and merge the CE skill already does internally.
Proposal
A discovery convention for project-local personas, for example:
.compound-engineering/reviewers/*.md), or a config key in.compound-engineering/config.local.yamllisting extra persona paths.<persona-name>.mdcontract and findings schema that the built-in personas already use.Custom personas would just be additional entries in the same catalog, sourced from the project instead of the plugin.
Alternatives considered
Willing to contribute
Happy to open a PR if maintainers are open to the direction — a pointer to the preferred discovery shape (config key vs. directory convention) would help.