PromptKB

Review patterns → a specific revision

Fix the repeated weakness, not just the last answer.

An overall rejection tells you a response needs work. A criterion overview shows whether the same requirement is being missed across your case set—and whether there is enough current evidence to judge it.

Open criteria overviewDownload the editorial reviewDownload unrun release-brief projectDownload public source notes

A real editorial task, not an independent model experiment. This worked review uses six real product updates from PromptKB’s public history. The agent wrote both drafts and judged them in shared context. There was no separate model execution, blinded reviewer or held-out validation. Counts describe these saved self-assessments, not model accuracy, human time savings or audience impact. Read the resulting published product brief.

Start from a requirement the reader needs

The task was a short product-update brief for existing users: explain what changed, why it matters, what to do next and a material limitation. The inputs are six selected public updates from November 3, 2026, through 19:17 UTC. The source snapshot was generated at 19:34:58.041 UTC; the downloaded source notes retain timestamps and original public descriptions. This is one day’s selected product history, not a full week or a complete deployment log. The public history is agent-maintained, not independently verified.

Four manual criteria were applied: grounded claims, concrete reader value, an explicit next action with a named control/destination, and a relevant limitation. The first instructions requested concise summaries and factual limits, but did not request that next action.

The resulting A drafts were useful summaries, not deliberately corrupted answers. Under this task’s strict next-action requirement, all six lacked an explicit instruction and named place to start. Merely listing a capability or download format did not satisfy that criterion. All six were judged to meet the other three criteria. A different editorial purpose might reasonably accept these summaries; the rubric explains this decision rather than declaring them universally bad.

Use the overview to inspect the pattern

  1. Open the editorial project in the Test Bench. In step 4, expand Find recurring manual-criteria failures.
  2. For each applied criterion, inspect the A/B counts. The third criterion shows six failures among six assessed A cases and zero failures among six assessed B cases. Other criteria have no recorded failures in this self-review.
  3. Choose Inspect failures for A’s next-action criterion. The queue contains all six cases. Open one: focus moves directly to the selected variant’s recorded-response review, with case input, exact stored output, assessments and notes available. Drafts are not the review target.
  4. Use Back to criteria overview to return to the same criterion/filter. Open another case and read its explanation. The point is to check that the repeated label reflects a real shared weakness, not a misunderstood rubric or a bad test case.
  5. Compare the instructions. B explicitly requests Change / Why it matters / Next / Limit and a named action or destination. This is a specific revision motivated by the observed editorial gap, not a generic “make it better.”
  6. Read the B drafts too. Their named next actions address that requirement while preserving the limits on model execution, expected-value checks, local workflow and reviewer judgment. The agent selected these drafts for the linked public product brief. Their self-review is not evidence that B will generalize to new notes or other models.

Read coverage before reading failure counts

Assessed means this individual criterion is marked Meets or Does not meet in a current review of the latest prompt-current response. It can count even when another criterion or the overall accept/reject decision is unfinished. The separate overall acceptance panel still requires a complete review and explicit decision.

Use Inspect unfinished to locate gaps, or choose the specific awaiting/excluded filter. Changing a criterion or case check does not rerun a model; it makes bound reviews out of date. Restoring the exact original context can make them current again. Missing or outdated judgments are not silently regraded.

Keep an evidence-backed decision

Sharing with someone who does not need the editor? Download a read-only HTML review handoff: source/response pairs, saved rationales and criterion links in one offline file.

Download the full comparison report from the overview. It includes every criterion and case regardless of the selected filter, names the cases behind each state, explains denominators, and retains the underlying recorded prompts, outputs and notes. It is not redacted or re-importable; keep project JSON for editable recovery.

This view derives from your existing project. It adds no scores, model calls, storage format, uploads or persistent view settings. Use the unrun project for new samples rather than treating the editorial drafts as independent model evidence. Before publishing your own brief, verify source claims, links, task policy and review rationale; a tidy matrix is not a substitute for editorial judgment.

Define and retain manual review criteria · Compare against a saved baseline