StartConceptsWorkflowsReferenceTroubleshoot

Artifact Review Assessor

How the assessor triages reviewer findings into MUST-FIX, NICE-TO-HAVE, and DISMISS — judging against the artifact's contract, not subjective quality.

What is the Artifact Review Assessor?

The artifact-review-assessor skill triages reviewer findings into MUST-FIX, NICE-TO-HAVE, or DISMISS. It runs inside catalog atoms AF-REVIEW and AF-REVIEW-TRIAGE — the governance layer that prevents over-zealous reviews from blocking delivery without evidence.

The assessor does not re-review the artifact. It reads the reviewer's findings and judges each one against the artifact's contract — the specific requirements and quality dimensions that the reviewer is authorised to enforce for that artifact type. Subjective quality preferences that fall outside the contract are dismissed.

No self-review loop. The assessor is always a separate invocation from the reviewer. A reviewer produces findings; the assessor triages them. The author cannot serve as their own assessor — triage happens after review, not during it.

How It Works

The assessor receives three inputs:

  1. The artifact — the document being reviewed (e.g. SPEC.md, ROADMAP.md, REVIEW.md)
  2. The reviewer's findings — the list of issues and observations produced by the reviewer skill
  3. The artifact contract — the quality dimensions and requirements that the reviewer is authorised to enforce for this artifact type

For each finding, the assessor asks: Is this finding a violation of the artifact's contract?

  • If yes, and it blocks the artifact's purpose → MUST-FIX
  • If yes, but it is a quality improvement that does not block → NICE-TO-HAVE
  • If no, or it is outside the contract's scope → DISMISS
Contract-only judgment. The assessor does not enforce stylistic preferences, opinionated restructuring suggestions, or quality improvements that are not part of the artifact's contract. These findings are dismissed regardless of how the reviewer framed them. This prevents review fatigue and scope creep.

The Three Verdicts

VerdictMeaningAction required
MUST-FIX Finding is a contract violation that blocks the artifact from being approved. The artifact cannot advance until this is resolved. Fix before next review round. Resets the 2-consecutive-clean-pass counter.
NICE-TO-HAVE Finding is a genuine quality improvement that is within the contract's scope, but does not block approval. The artifact can advance without fixing it. Fix if time permits. Does NOT reset the pass counter.
DISMISS Finding is outside the artifact's contract scope, is a stylistic preference, or is not actionable in the context of this artifact type. No action. The finding is noted and dropped from the review record.

The Review Cycle

The full review cycle for any artifact follows this sequence:

  1. Reviewer produces findings — the domain-specific reviewer skill (e.g. review-spec, review-roadmap) examines the artifact and produces a findings list.
  2. Assessor triages findings — artifact-review-assessor reads the findings and assigns MUST-FIX / NICE-TO-HAVE / DISMISS to each.
  3. Fix MUST-FIX items — the author addresses all MUST-FIX findings. NICE-TO-HAVE items are optional. DISMISS items are ignored.
  4. Reviewer re-checks — the reviewer runs again on the updated artifact. If no MUST-FIX findings remain, this counts as one clean pass.
  5. 2-pass enforcement — the cycle repeats until two consecutive clean passes are recorded. State is tracked per artifact using SHA256-keyed JSON in ${SB_RUNTIME_HOME_ROOT}/.silver-bullet/review-state/.
Clean pass definition. A clean pass means zero MUST-FIX findings in a review round. NICE-TO-HAVE findings do not prevent a clean pass. Two consecutive clean passes — on two separate reviewer runs — constitute approval. A single clean pass is not sufficient.

When It Runs

The artifact-review-assessor runs inside the catalog review atoms: AF-REVIEW and AF-REVIEW-TRIAGE. It also runs after planning/specification artifact reviewers in compositions that include AF-SPECIFY or AF-PLAN.

Specifically, the assessor is invoked after these reviewers:

  • review-roadmap — triages ROADMAP.md findings for bootstrap/planning evidence
  • review-requirements — triages REQUIREMENTS.md findings for AF-SPECIFY and decision evidence
  • review-spec — triages SPEC.md findings (AF-SPECIFY)
  • review-context — triages CONTEXT.md findings (AF-PLAN)
  • review-research — triages RESEARCH.md findings (AF-DECIDE / AF-PLAN)
  • Plan checker reviewer — triages PLAN.md findings (AF-PLAN, max 3 iterations)
  • review-uat — triages UAT.md findings (AF-VERIFY)
  • silver:review — triages code review findings (AF-REVIEW)
Cross-artifact review. At milestone completion (AF-RELEASE), a cross-artifact reviewer checks SPEC-to-REQUIREMENTS-to-ROADMAP-to-DESIGN alignment. The assessor triages these cross-artifact findings using the same MUST-FIX / NICE-TO-HAVE / DISMISS framework before the release proceeds.

See Also

← Previous Composable Workflow Orchestration Back to Core Concepts