Use ONLY after analyze-dag has produced the DAG artifact — review the task DAG (review-dag single gate) — OR when auditing the <instance-root>/ process infrastructure itself (audit-process). Spawns N parallel Explorer reviewers (1 dimension each) against the matching checklist, synthesizes findings with a Worker Synthesizer, and iterates with a Worker reviser until convergence. The legacy roadmap / design-space / iteration-plan targets were archived 2026-08-21 ([org-internal #3072] phase 3, <instance-root>/archive/). Do NOT use for code review — use the review-code skill for that.
triggers:
- audit-process
- review-dag
- dag review
- DAG 评审
- process audit
- parallel review
- reviewer
- checklist review
- mandatory gate
# `stage` is set to the primary gate `audit-process`; the second live target
# (review-dag) carries its own stage id in the Target Selection table below.
> **Retired targets (historical)**: the `roadmap`, `design-space`, and `plan`
> targets were archived on 2026-08-21 per [org-internal #3072] phase 3 (ruling:
> `docs/workflow-refactor/phase3-retirement-ruling.md`) — the legacy
> production skills they gated no longer exist (see `<instance-root>/archive/`).
> Their stage ids (`review-roadmap`, `review-design-space`,
> `review-iteration-plan`) were retired from the stage registry in the same
> ruling. Historical review pages under `{slug}/reviews/roadmap|design-space|plan/`
> remain readable; no new reviews run against those targets.
The stage IDs remain as-is — they are used by the stage registry and auto-approve system. The skill name is `review-artifact`, but the stage IDs do not change.
> **Progressive disclosure ([org-internal #3734])**: this skill has two disjoint live
> targets — dispatch an auditor/reviewer with
> `skills: ["review-artifact:target-process"]` or
> `["review-artifact:target-review-dag"]` (preamble + that target only)
> instead of the full body. Tool availability, target selection, and shared
> pipeline mechanics are unmarked preamble and always inject. Full-body
> remains the default when no selector is passed.
## Shared Pipeline Mechanics
This skill follows the standardized parallel-review pipeline. The full mechanics are in:
- `<!-- inject: ../_shared/review-pipeline-phases.md -->` — Phase A through Phase E
- **Phase A step 0**: move the source issue to the `review` column on the
Pipeline Stages board per `_shared/gitea-write-patterns.md` Pattern 7.5
(see `_shared/review-pipeline-phases.md` for the canonical orchestrator
The Orchestrator MUST use the standardized reviewer prompt template at `core/skills/_shared/review-reviewer-prompt.md` when dispatching each reviewer. The template is the same for all reviewers; the Orchestrator fills in skill-level constants and per-dimension values. Each target defines its own constants in its section below.
revision role Planner) — were archived on 2026-08-21 together with the
production skills they gated (ruling:
`docs/workflow-refactor/phase3-retirement-ruling.md`; skills and exclusive
checklists/templates recoverable under `<instance-root>/archive/`). Their stage ids
are retired from the stage registry; no new reviews run against them, and
historical review pages under `{slug}/reviews/{roadmap|design-space|plan}/`
stay readable as produced. Live targets: **process** (below) and
**review-dag** (single gate).
---
<!-- section:target-process -->
## Target: process (audit)
The audit target is the **SDLC factory itself** — the set of skills, checklists, templates, and schemas under `<instance-root>/` — judged for internal consistency, cross-reference integrity, and conformance to audit standards (ISO 19011:2018, IEEE 1028-2008) and `AGENTS.md` conventions.
**Scope boundary**: This skill audits the *definition* of the pipeline. It does NOT audit whether a project *followed* the pipeline — that is the `retrospective` skill's responsibility.
No `.artifacts/{slug}/` inputs are required — the audit reads `<instance-root>/` itself. Audit outputs are published as Gitea wiki pages under `audit/{date}/`.
The process target has 10 dimensions, so Phase A is satisfied when **≥8 of 10
dimension findings are produced after retries** (≥75% coverage). If fewer
than 8 dimension JSONs are available after
retries, abort the round with FAIL — an audit round must not proceed with an
underspecified fraction of dimensions covered. Crashed/timed-out dimensions are
marked `UNRESOLVED` and retried in the next round.
### Auditor Constants
In auditor output, the `dimension` field carries the audit dimension code (INV, XREF, FM, ...) and `slug` in the commit status is the literal `audit`.
The Orchestrator MUST use the standardized auditor prompt template from `core/skills/_shared/review-reviewer-prompt.md` with these constants:
- Model tier: default session reviewer model (`Reviewer` Explorer role, `_shared/roles/reviewer.yaml`) — the process target sets no `reviewer-tier` override; record any assignment change here so sibling review skills stay comparable (TRC 10.5)
- `{REVIEWER_ROLE}`: process auditor
- `{BASELINE_SECTION}`:
```
## Audit Subject
You are auditing the <instance-root>/ process infrastructure ITSELF — the SDLC factory of skills, checklists, templates, and schemas. You are NOT auditing any application code, and NOT auditing whether a project followed the process.
```
- `{READ_FIRST_STEPS}`:
1. Read every file listed above. Do NOT skip any file.
2. For XREF/SCH dimensions: for every path or field referenced in a skill, actually resolve it (Read/Glob) and confirm it exists and matches. A referenced-but-missing path or a field-name mismatch is a finding.
3. For all other dimensions, read every assigned file and flag any cross-file inconsistency (terminology, numbering, drift) you find.
- `{ARTIFACT_NOUN}`: process infrastructure
- `{FINDING_DETAILS}`: file path and line number, a summary, detailed explanation, and quoted evidence from the file
- `{FINDING_ID_EXAMPLE}`: INV-F001
- `{CONTRADICTION_RULE}`:
6. (not applicable — the audit is a self-contained inspection, not a baseline comparison)
- `{SEVERITY_DEFINITIONS}`:
- BLOCKER: broken cross-reference (skill references a non-existent checklist/template/schema/path), missing required frontmatter `description` (skill never triggers), a pipeline stage with no producer for its declared precondition, schema field mismatch that would make written artifacts invalid
- MAJOR: orphan checklist/template/schema, dimension count mismatch between a review skill and its checklist, naming inconsistency for a dimension code or role, missing convergence/approval gate, AGENTS.md command divergence (e.g. `bun test` instead of `bun run test:parallel`)
- MINOR: terminology drift, duplicated rule that should live in one place, inconsistent standard-number formatting, missing cross-reference comment
- INFO: observation or improvement suggestion beyond the checklist
| Output mode | Tier 1 local files under `<runs-root>/audit/reviews/audit-process/round{N}/findings-{DIMENSION_CODE}.json` (validated by `core/schemas/reviewer-output.schema.json`); synthesis wiki page + commit status stay Tier 2 |
| Commit status context | `pipeline/audit-process` |
| Wiki namespace | `audit/{date}/` |
| Status tracking | Commit status `pipeline/audit-process` (via REST, `_shared/gitea-write-patterns.md` Pattern 8) — `slug: "audit"` |
| Date resolution | `{date}` resolved as `YYYY-MM-DD` |
The DAG review is a **single gate** (spec-02 §1 D-02) that replaces `review-design-space` +
`review-iteration-plan` for a DAG artifact. It reviews one artifact — the DAG
at wiki page `{epic-slug}/dag` (NOT per-size-tier pages) — against
`core/checklists/dag-single-gate.md` with three fixed dimensions. It saves
orchestration overhead, not the revision loop — the three dimensions each
review an independent risk surface.
### Preconditions
- [ ] The DAG artifact exists at wiki page `{epic-slug}/dag` (read via `wiki 读写 API（见 TERMINOLOGY）`).
- [ ] The DAG's `dag_metrics.review_depth` is set (D1–D4) — review depth, reviewer count, `dim_split`, and the Phase D round cap are all derived from this field, NOT from `Size/*` labels.
- [ ] `core/checklists/dag-single-gate.md` is accessible.
files MUST be slot-prefixed (`{DIM}R{k}-F{NNN}`, e.g. `TOPOR1-F001`) so ids
stay unique across a dimension's slot files. This preserves per-reviewer
attribution (retrospective overlap analysis, [org-internal #2996] step ①a) and makes the
write race impossible by construction.
- Synthesis input for a dimension = ALL `findings-{DIM}*.json` in the round
directory — the synthesizer already globs every `findings-*.json`; the slot
files of one dimension aggregate as that dimension's findings.
- Phase A's "dimension produced" check: a dimension counts as produced only
when EVERY assigned slot's file exists.
### Reviewer Constants
- Model tier: `reviewer-tier` (per `analyze-dag` §Exec-Resource Configuration — reviewer-tier's only allowed consumer; corresponds to the `Reviewer` Explorer role, `_shared/roles/reviewer.yaml`)
The artifact under review is the DAG at wiki page `{epic-slug}/dag` (read via `GET <gitea-base-url>/api/v1/repos/{owner}/{repo}/wiki/page/{mangled-name}`, `sub_url` resolved from `GET .../wiki/pages` first). Read it first for orientation. Its `dag_metrics.review_depth` (D1–D4) sets this review's depth and round cap.
1. Read the DAG artifact at `{epic-slug}/dag` first for orientation.
2. Read `core/checklists/dag-single-gate.md`.
3. For REQMAP when AC detail is sunk: follow the `{node-id} → {epic-slug}/dag-nodes/{node-id}` pointers to read the subpage ACs.
- `{ARTIFACT_NOUN}`: DAG artifact
- `{FINDING_DETAILS}`: location in the document, a summary, detailed explanation, quoted evidence from the document
- `{FINDING_ID_EXAMPLE}`: TOPO-F001
- `{CONTRADICTION_RULE}`:
6. When a DAG element contradicts its own declared topology, requirement mapping, or rolling-release plan, this is at minimum a MAJOR finding. When a required DAG section is entirely absent, this is a BLOCKER.
- `{SEVERITY_DEFINITIONS}`:
- BLOCKER: cycle in the DAG edge graph (TOPO 环检测), milestone missing at a `cross_session_in ≥ 2` convergence point (TOPO 里程碑位置), ≥3 task nodes below the granularity floor (`estimated_sessions < 0.25`, TOPO 粒度下限), a requirement with zero node coverage (REQMAP 需求覆盖)
- MAJOR: missing or reversed dependency edge (TOPO 依赖正确性), giant node (`estimated_sessions ≥ 2`) needing split (TOPO 大小均匀性), `estimated_hours`/`estimated_sessions` field inconsistency (`|estimated_hours − 8 × estimated_sessions| > 2`), a single task node below the granularity floor, AC missing error/boundary-path coverage (REQMAP AC 路径覆盖), contract↔node AC inconsistency (REQMAP 契约↔节点一致性), task node with empty/invalid `req_refs` (REQMAP 节点溯源)
- MINOR: `1 < estimated_sessions < 2` (over-upper-limit, suggest split), formatting issue, missing cross-reference, terminology drift, revision record not initialized
- INFO: observation or recommendation beyond the checklist, including the TOPO page-size signal (see below) — does not affect any gate verdict
| Output mode | Tier 1 local files under `<runs-root>/{epic-slug}/reviews/review-dag/round{N}/findings-{DIMENSION_CODE}.json` — one file per reviewer slot when dim_split > 1 (`findings-{DIM}-r{k}.json`, see §"Reviewer slots & findings files") — validated by `core/schemas/reviewer-output.schema.json`; synthesis comment + commit status stay Tier 2 |
| Commit status context | `pipeline/review-dag` |
| Wiki namespace | `{epic-slug}/reviews/review-dag/` |
`TOPO` / `REQMAP` / `RELEASE`, and the commit status context is
`pipeline/review-dag`. Revision role = **Analyst** (the DAG author).
### Phase A Threshold
Unlike the process target (≥8 of 10 dimensions), review-dag has only 3 dimensions, so
Phase A is satisfied when **ALL THREE dimension findings are produced (3/3 = 100%)**.
- "3/3=100%" applies to a **full round** only (all 3 dimensions assigned and produced).
- In a **partial re-review round** (rounds ≥3 re-review only FAIL/WARN/UNRESOLVED dimensions), Phase A is satisfied when the assigned dimensions' findings are all produced.
- In a **full round where one dimension is UNRESOLVED** (e.g. a reviewer crashed, only 2/3 produced), that round proceeds with the produced dimensions and the UNRESOLVED dimension defers to the next partial re-review round — do NOT abort and do NOT apply the 8-file threshold.
### Phase D MAX_ROUNDS (per depth)
review-dag's Phase D convergence loop round cap is read from
`dag_metrics.review_depth`, NOT the shared `review-artifact` skill default of 3:
| Depth | MAX_ROUNDS |
|---|---|
| D1 | ≤2 |
| D2 | ≤3 |
| D3 | ≤3 |
| D4 | ≤4 |
**D4 override**: the shared `review-artifact` skill MAX_ROUNDS is 3 (see
`_shared/review-pipeline-phases.md` Phase D "`{MAX_ROUNDS}` binding"), but
review-dag overrides it per depth. D4 reaches round 4 (≤4), which exceeds the
shared default — the D4 round cap MUST take precedence for review-dag.
### Round-3 Escalation Guardrail interaction
The Round-3 Escalation Guardrail (see `_shared/review-pipeline-phases.md`
Phase D) applies to review-dag. Its interaction with the per-depth round cap:
- **D1–D3** (cap ≤3): the guardrail and the per-depth cap coincide — no conflict.
- **D4** (cap ≤4): when the Round-3 guardrail triggers, it MUST offer the option "(b) 继续进入第 4 轮" (continue into round 4) rather than a hard stop. The guardrail means "escalate to human / give the user a choice", not "force-stop at round 3" — so D4's round 4 is reachable via that option. Independently of the guardrail, entering round 4 at all is gated by the shared **Round-4 user-choice escalation point** (`_shared/review-pipeline-phases.md` Phase D) — the choice is offered unconditionally at the round-3→4 transition, whether or not the guardrail's >50% condition fired.
### TOPO Page-Size Signal
The TOPO reviewer reads the `> 页尺寸自检: 超限` flag at the top of
`{epic-slug}/dag`. If present, the TOPO reviewer records it as an **INFO
finding** in the synthesis — summary = page-size over-limit, with the
acceptance-criteria detail sunk to the `{subpages}` of the DAG. This INFO
finding does NOT change any gate verdict and does NOT trigger re-derivation of
