Why design review needs a queue
The question this guide answers is: what criteria can agents use, and what must be computable versus what must stay human? The practical rule this guide proposes (Rule 1) is: a card may transition review → done only when its recorded approver identity differs from the identity that implemented that card.
Nothing was run hands-on for this piece: no board, agent, or pipeline was installed or executed. The post is based on the cited documentation and pages.
Design review often bundles mechanical pass/fail checks with judgment calls, burying high-value judgment under routine verification. That is the problem identified in AI-SDLC’s design-review architecture. A queue can make the handoffs and evidence visible, but a board does not itself decide which criteria belong to automation or people.
The Loupe article cites third-party figures: 90% of surveyed companies reported launch delays from late-stage design changes, and 43% of design-review feedback was lost across disconnected applications. These are figures reported through that article, not independently verified research here.
Across the sources, we see a recurring shape: an agent implements; the card enters review; checks run before a narrowly scoped human sign-off; and rework returns with a reason. That is our synthesis, not a claim made by any one source. The Hermes Kanban documentation describes a board as a standalone task queue with its own SQLite DB, workspaces directory, and dispatcher loop; one install can host many boards.
The one rule: an agent never signs off its own work
Rule 1 makes identity separation computable:
# Illustrative pseudocode, not a documented API
on transition to done:
if approver_identity == implementer_identity:
rejectIn the approval record, the approver identity must differ from the implementer identity (the identity that last claimed or completed the implementation run), so a linter can compare the two.
The rule draws on two explicit statements, and the identity test itself is this guide’s own. Meshly says “an agent cannot sign off work, its own or anyone else’s, unless it is carrying an explicit mandate to review that specific task” (Meshly Control page). Monstrare says “Agent output is never itself an approval — humans sign off at every gate in ai/process/review-gates.md” (Monstrare).
Hermes specifies that each run ends in exactly one of kanban_complete, kanban_request_review, kanban_block, or a worker exit without a tool call, and its kernel enforces that exactly one terminates each run. This is a useful lifecycle constraint: a run should not silently have multiple endings.
The no-self-sign-off rule means identity separation, not “humans only.” Hermes can dispatch an agent reviewer; Meshly describes an explicit-mandate exception but does not specify who grants it or how it is scoped. Hermes also does not enumerate the allowed values of kanban_request_review’s reviewer parameter. Treat both gaps as unresolved, not as permission to assume a particular authorization scheme.
What rides on the card
The following design-review card is our assembly of fields named in the sources. No source presents a worked design-review task card.
The minimum card
A Hermes Task has a title, optional body, one assignee, status, optional tenant namespace, and optional idempotency key. Loupe’s suggested minimum review card adds Problem, Chosen approach (with a prototype link), Open questions (as questions with owners), and Links. Detailed specs, edge cases, constraints, and revision history belong in a linked document, not necessarily the short card.
Illustrative card body:
Problem: [decision to resolve]
Chosen approach: [summary and prototype link]
Open questions: [question, owner]
Links: [requirements, prior feedback, design document]Loupe cautions: “If a reviewer can’t point to the exact line, frame, or screen a comment belongs to, that comment will get lost.” Pin comments to specific evidence where possible.
Attachments and evidence
Hermes supports PDFs, images, and source documents as attachments, with a 25 MB cap per upload. Files are stored under attachments/<task_id>/; handoff context lists each file’s name and absolute path, and a worker can read attachments through read_file or shell tools such as pdftotext. This establishes file handoff, not image review: no image-review capability is described in the sources.
Monstrare’s card panel lists owner, risk, agent, Readiness checklist, Review Gates, and comments. Meshly’s panel examples are illustrative, not a live deployment.
Comments as protocol
Hermes calls comments “the inter-agent protocol”: a (re-)spawned worker receives the full comment thread as context. That makes a reasoned review comment part of the handoff rather than a detached note. The card anatomy above is assembled from the fields sources name.
What must be computable
The charter is the criteria contract
AI-SDLC’s governing rule is: “never ask a human, or an LLM, for something a linter can answer.” Its four layers are [Deterministic] Design CI, [Deterministic] Structural Design Preprocessor, [AI Agent] Usability Simulation, and [Human] Design Lead Review.
Layer 1 checks accessibility, tokens, spacing, type scale, and states as pass/fail criteria, without human or AI review. Every review prompt receives a Design CI Boundary that lists which checks automation already handled, so reviewers do not revisit those categories. Layer 2 prepends structural findings about complexity, completeness, and grid to review context. Layer 3 describes browser-based task-completion testing with confidence-scored findings: those below 0.5 are suppressed, while medium-confidence findings get a lightweight meta-review. Layer 4 leaves unresolved design judgment to a human.
Implementation status matters. AI-SDLC distinguishes Wired, Implemented, unwired, and Spec-only. accessibilityAudit is spec-only: “Run axe-core / Pa11y in your own CI meanwhile.” Six Addendum A modules are described as written and unit tested but not exported. The documentation is explicit: “The end-to-end flow is not running for you today.” The architecture is therefore a useful criteria contract, not evidence that the entire pipeline runs live.
Meshly’s charter provides a complementary verification principle: “A criterion asks whether the author’s claims are true. A test named that does not exist, or a command whose output is not shown, is flagged as unverifiable rather than accepted.” Its required-reading tokens include task_diff, acceptance_criteria_check, prior_review_verdicts, and knowledge_relevant; these are not established as an exhaustive schema. “Record only is the default,” rather than acting on a verdict.
Meshly also says the reviewer may run repository-declared checks, read CI results, and see security scan findings. “Your repository decides which checks a review may run.” Each check is reported as PASSED, FAILED, or NOT RUN with a reason, never as a pass when it did not run.
Monstrare offers another way to make craft criteria repeatable: design-craft guidance includes Refactoring UI principles, type scale, a 4px spacing grid, layered color systems, depth rules, and five interactive states. Its design system and craft guidance live in the repository so that agents share a standard, with “no hidden dependency on skills installed in someone’s home directory.”
What stays human
AI-SDLC’s Layer 4 reserves aesthetic quality, design-language consistency, contextual fit, visual rhythm, and hierarchy for human design judgment. Loupe also reserves human judgment for accessibility, privacy, security, irreversible data changes, and user harm. Its question is apt: “Don’t ask whether a human is in the loop. Ask which decisions the human owns, and what evidence they see before approving.”
Monstrare marks explicit human gates: “Human approval,” “Human picks a variant,” and “No evidence -> not done.” Its design system is built through five human-gated stages: framework -> style direction -> design tokens -> component library -> page layouts.
| Criterion | Who or what checks it | Source |
|---|---|---|
| Accessibility, tokens, spacing, type scale, states | Design CI, pass/fail | AI-SDLC |
| Structural complexity, completeness, grid | Structural Design Preprocessor; findings enter review context | AI-SDLC |
| Simulated-persona task completion | AI Agent Usability Simulation; confidence-scored, below 0.5 suppressed | AI-SDLC |
| Whether the author’s claims are true | Charter-bounded automated reviewer | Meshly |
| Repository checks, CI, security scans | Reviewer reports PASSED, FAILED, or NOT RUN honestly |
Meshly |
| Intent vs. requirements, consistency, gaps | First agent | Loupe |
| Built work vs. technical design | Second conformance agent | Loupe |
| Aesthetic quality, design-language consistency, contextual fit, visual rhythm and hierarchy | Human design lead only | AI-SDLC |
| Accessibility, privacy, security, irreversible data changes, user harm | Human high-risk calls | Loupe |
| Variant selection | Human | Monstrare |
| Sign-off at every gate | Human; Meshly allows an explicit-mandate exception | Monstrare and Meshly |
Routing: how a card reaches an agent
The Hermes worker-lanes contract says a lane must provide an assignee string, a spawn mechanism, and a lifecycle terminator. If an assignee does not resolve, the task stays on ready with a skipped_nonspawnable event; it is not silently sent to a fallback.
The default Hermes spawn command is hermes -p <assignee> chat -q <prompt> in the pinned workspace. An orchestrator lane includes kanban but excludes terminal / file / code / web for implementation. Wiring an external CLI worker such as Codex CLI, Claude Code CLI, or OpenCode CLI is “not yet a paved path”: spawn_fn exists, but integration remains per-integration design work. The cited history includes issue #19931 and closed-not-merged PR #19924.
Other systems route differently. Linear allows agents to act through delegation (assigning an issue to the agent) or through @mention. Guidance can specify “what review process to follow,” but “All guidance is passed to the agent, but how it is interpreted or applied depends on the specific agent integration.” Linear documents no review stage. Agents are not billable seats and cannot sign in to the app, access admin functionality, or manage users. See Linear’s agent documentation.
Monstrare uses repository entry points, AGENTS.md for Codex and CLAUDE.md for Claude Code, to apply the same gated process. Meshly describes agents moving work through MCP tools including complete_task and start_task; its default is “One In Progress per assignee, per project.”
Review states and their terminators
Hermes documents the statuses triage | todo | ready | running | blocked | review | done | archived; review is first-class. kanban_request_review moves a task to review and “this is not a block.” kanban_request_changes closes the review run, reapplies parent gating, and routes the task to its original implementer with a required reason. Parent-child links also gate promotion: todo → ready only when all parents are done.
Hermes encodes three review models: Same-card review, Pre-created downstream review/QA/release card, and Human-only boards (kanban.review_dispatch: false). In the last model, a task waits in review until a human approves or uses reopen-review or the dashboard to return it to an earlier state.
Meshly’s columns are To Do / In Progress / Review / Done, with a Backlog → start rule for moving work out of Backlog; complete_task with a summary moves a card to Review. Monstrare’s board “simplifies the policy’s 12 stages down to 6 lanes”: Backlog -> Blocked -> Ready -> Implementing -> Verify -> Done. The sources do not establish a mapping between these systems’ states.
| System | Review mechanism documented | Where the human gate sits |
|---|---|---|
| Hermes worker lanes | Same-card, downstream-card, or human-only review | At the review transition before done |
| AI-SDLC | Four-layer design review | Final, narrow Design Lead Review |
| Loupe | Prototype, annotations, agent review, conformance pass | Human approval of a named revision and high-risk calls |
| Monstrare | Gated workflow with Review and Human Acceptance | Humans sign off at every gate |
| Meshly | Approval gate, chartered reviewer, repository checks | Person approves or rejects; capped rounds go to a person |
| Linear | Delegation, mentions, and guidance; no review stage described | No review gate is defined by Linear |
Feedback loops: how the agent learns from review
Hermes comments carry the full thread into worker context on respawn; kanban_request_changes sends rework back with a reason. Meshly’s MCP nudges can include rejection-reason context on restart and completion warnings when no lesson was recorded; higher-priority tasks get a quality reminder at completion.
AI-SDLC describes an exemplar flywheel: reviewers produce findings, the design lead accepts or dismisses them, dismissed findings become false-positive exemplars and accepted findings become true-positive exemplars. addExemplar() is the write side; later reviews are anchored to the enlarged bank. usabilityFindingAccuracy is the headline signal among six design metrics.
Loupe’s annotation loop is: Read the rendered doc / Annotate in place / Send it once / Compare versions. The article claims that this “cut review time in half in practice.” Its cited research reports avoidable rework at 40–50% of effort, roughly 80% of that rework traced to 20% of defects, and peer review detecting about 60% of defects, rising toward 80% with cross review. The article also attributes to GoProof guidance that most deliverables settle within two to three rounds, with a decision meeting after a fifth round.
In its agent-review section, Loupe puts the split this way: “One agent builds, another verifies.”
Caps, escalation, and stuck cards
Loupe recommends a configured maximum number of revision and fix rounds, after which work escalates to a named decision maker or returns for redesign. Meshly likewise allows a review-round cap, after which the task goes to a person; skip-review opts a task out. Its displayed round counts are illustrative, not a default or specification.
Hermes auto-blocks after kanban.failure_limit consecutive spawn failures (default: 2). Repeated same-kind re-blocks escalate to triage. Its stranded-task detection uses kanban.stranded_threshold_seconds (default 30 min), with stranded_in_ready warning, error at 2x, and critical at 6x. The stale-claim TTL DEFAULT_CLAIM_TTL_SECONDS is 15 min; a live worker gets its claim extended. Meshly describes a stale-task detector that flags inactive In Progress cards, but its dashboard example is illustrative. Loupe says a stuck agent routes a blocking question to an inbox rather than guessing; the answer returns to the card and the run resumes.
What the sources don’t establish
No source documents an integrated kanban-driven design-review pipeline for AI agents. The combination described here is an inference. The sdlc-review skill is named but its contents, rubric, and output format are not described. AI-SDLC has no production UsabilitySimulationRunner, and its end-to-end flow is not running today.
Loupe’s board is described narratively, without column names, statuses, or task schema; its two agents are unnamed and unspecified. No source specifies reviewer notifications, SLAs, queue priority, or multi-reviewer assignment.
Hermes is single-host with a trusted-local-user threat model; how a design team would share a board is not established. Nor do the sources describe image-review capability beyond generic file attachments. These are gaps, not details to fill in by assumption.
FAQ
Can an AI agent ever approve design work?
Hermes permits an agent reviewer in some configurations, while Monstrare says human sign-off occurs at every gate. Meshly describes an explicit-mandate exception without specifying its mechanism. Rule 1 requires a distinct approver identity, not necessarily a human in every case. See Hermes worker lanes, Monstrare, and Meshly.
Which Hermes review model should a design team start with?
Hermes documents Same-card review, Pre-created downstream review/QA/release card, and Human-only boards. The documentation does not recommend one for design teams; choose based on the review handoff you intend to encode. See the worker-lanes contract.
Does AI-SDLC’s Design CI actually run today?
The architecture distinguishes Wired, Implemented, unwired, and Spec-only. accessibilityAudit is spec-only, and the docs say the end-to-end flow is not running today. See AI-SDLC’s design-review architecture.
Can I wire Claude Code or Codex CLI as a Hermes kanban worker?
The docs say external CLI worker lanes are “not yet a paved path”; spawn_fn exists, but surrounding integration is per-integration design work. See Hermes worker lanes.
How do mockups and screenshots reach the reviewer?
Hermes supports PDF, image, and source-document attachments up to 25 MB, which workers read through read_file or tools such as pdftotext. The sources do not establish image-review capability. See Hermes Kanban.
Does Linear gate design reviews?
No review stage is described by Linear. Its documentation covers delegation, @mention, and guidance text that can describe a review process, with interpretation left to the integration. See Linear’s agent documentation.
Are Meshly’s dashboards and “round 1 of 2” real output?
The panels are explicitly illustrative examples, not a live deployment or specification. See Meshly’s Control page.
What happens when an agent gets stuck?
Hermes can surface needs_input, capability, or transient blocks to a human; repeated same-kind re-blocks escalate to triage. Loupe describes routing a blocking question to an inbox. Meshly describes stale-task detection. See Hermes Kanban, Hermes worker lanes, Loupe, and Meshly.
The Bottom Line
Our synthesis of the documented systems is that the gate pattern is real and recurring, but an integrated kanban design-review pipeline for agents is not documented as a single product. You assemble it.
A conservative assembly runs deterministic criteria first, uses a charter-bounded agent to verify claims and evidence, and ends with a narrow human gate. Enforce no self-sign-off; put a reason on every rejection; cap review rounds and name an escalation owner. Treat AI-SDLC modules that are implemented but unwired as contracts, not features.
How This Guide Was Built
We did not run any of these tools hands-on; every claim is drawn from the linked public documentation. The two Hermes Kanban excerpts (core concepts; how workers interact with the board) come from one long documentation page; the worker-lanes page was read in full. RFC-0006, the Design System API reference, and the Design System Operator Runbook are named in the AI-SDLC docs; their contents are not cited. Those named documents are RFC-0006, the Design System API reference, and the Design System Operator Runbook.
Loupe’s statistics and round-counts are third-party citations appearing in its article; the underlying studies and guidance were not reviewed. Product names, tool names, statuses, config keys, and defaults follow the linked documentation. The gaps section records important claims the sources do not establish.