Does /pr-review sit beside or replace the second Consumer's existing reviewer? #547

Activity

1. orioltf

   added

   app:unic-archon-dlc

   wayfinder:grillingWayfinder ticket: decide it by grillingWayfinder ticket: decide it by grilling

   on Sep 23, 2026
2. orioltf

   added a parent issue on Sep 23, 2026

   • wayfinder: e2e specs from acceptance criteria, at a second Consumer #538
3. orioltf

   self-assigned this

   on Sep 29, 2026
4. orioltf commented on Sep 29, 2026

   

   orioltf

   on Sep 29, 2026

   MemberAuthor

   More actions

   Resolution

   Grilled with the maintainer on 2026-09-29. Every decision below is the maintainer's.

   /pr-review sits beside the second Consumer's reviewer, and replaces nothing. The team keeps its public review plugin, its committed settings and its README section as they are, and keeps running that plugin before it opens a pull request. /pr-review runs on the pull request after it is open, so the two work at different moments. Some findings may appear twice, once locally and once on the pull request. v1 accepts that.

   v1 runs /pr-review on the pull requests the chain opens. The Box is generic, so whether the Consumer also runs it on other pull requests is the Consumer's choice, not this map's.

   The gate stays hitl. A person approves the findings before /pr-review posts them on the Consumer's tracker. How the Consumer installs the DLC and a Practice Pack may change this later.

   What the team is asked is deferred. The proposal goes to the team once the DLC, and possibly a Practice Pack, are ready to hand over. It moves to the map's Not yet specified.

   Facts this rests on

   • unic-dlc-pr-review.yaml has no PRD precondition. bootstrap needs a slug and .archon/unic-dlc.config.yaml, nothing else. prep finds the open pull request from the current branch. It builds the Intent Brief from the linked work items, the docs pages they reference, the pull request description, and PRD.md only if it exists. With no intent source, review skips the Spec axis and records "no spec available". So /pr-review can review a pull request that never went through /build.
   • e2e changes nothing in /pr-review. It changes only context, as decision 4 of the map already says.
   • The Standards axis reads only CLAUDE.md, AGENTS.md, CONTRIBUTING.md and CODING_STANDARDS.md, in step 3 of the review node. A Consumer that keeps its conventions under .claude/skills/<name>/references/ reaches the Standards axis only if one of those four files points at them. Whether the model follows such a pointer is unmeasured. That is a constraint on Which conventions of the existing e2e suite become tenant conventions, and who owns its directory? #543, posted there. The general fix goes into Practice Packs must stack: /setup replaces .archon/methods/ wholesale, and the override tier was deleted #520's grilling, where a Practice Pack declares its standards.

   Broadening /pr-review, not decided here

   The maintainer wants the DLC's /pr-review to find as much as pr-review-toolkit does, without vendoring it, so the plugin keeps upstream's updates and costs no maintenance here. This is outside this map's destination, and it edits a Box file owned by another map. It is recorded here so it is not lost. It is not filed yet.

   History. ADR 0026-pr-review-generic-archon-harvest first gave the Box seven aspects, taken from unic-pr-review, which took them from pr-review-toolkit. § 8 of that ADR folded them into the code-review Method's two axes (#281), because the Plugin was maintaining review criteria that upstream now maintains. Broadening reverses § 8.

   pr-review-toolkit's review-pr command takes its scope from git diff --name-only and finds the pull request with gh pr view. It chooses agents by the changed files, runs code-simplifier last, and returns a prose summary grouped as Critical, Important and Suggestions.

   Two ways a Box could use the toolkit without vendoring it:

   	Spawn the toolkit's agents by subagent_type	Invoke /pr-review-toolkit:review-pr
   Upstream updates received	each agent's prompt	the prompts, and which agents run and in what order
   The Intent Brief	passed to each agent	the command does not take it, so Spec stays with the Box
   Finding contract (confidence, hash, anchor, reconcile)	each agent returns what the Box asks for	the Box must parse prose, which breaks when the format changes
   Scope	the Box passes base_ref	the command picks its own, and gh pr view does not reach every tracker
   An upstream rename	breaks the Box	costs nothing

   Neither works unless an Archon node can reach a plugin enabled in the repository, and that is unmeasured. On Archon v0.10.1 it is measured that project skills reach a node only through skills:, that MCP servers reach it only through mcp:, and that a node reads CLAUDE.md but not AGENTS.md (docs/agents/agent-tool-traps.md, #521, #425). No probe has run a plugin agent through subagent_type, or a plugin command or skill, from a node. Two runs before v0.9.0 called the toolkit's agents, but recorded no result.

   The maintainer's decisions on it:

   1. A spike comes first: a probe in a scratch repository with the toolkit enabled, testing both ways above. The probe does not change the reviewer.
   2. The broadening issue waits for Take the reviewer's variance baseline on 0.28.0, before any fix lands #501's baseline and Dispatch run 4, end it in a merge, and score the seal #502 run 4, so neither measures a reviewer other than the one it was sealed against. It also touches bug(unic-archon-dlc): reconcile marks a finding fixed when the next review omits it, and post resolves the thread #482, bug(unic-archon-dlc): synthesize dedupes before identity is assigned and merged across two files against its own rule #486 and bug(unic-archon-dlc): the summary's § "Checks this review did not run" is false when a sub-agent ran a declared command #487, which read the review node's output.
   3. The seat that owns the Box files opens both, at needs-triage, and links this comment.
5. orioltf

   closed this as completedon Sep 29, 2026