artifact-verification
Orchestrator checklist to verify worker outputs against the approved plan before accepting artifacts. Phase 2 of orchestrator/worker context enforcement (#2020).
Best use case
artifact-verification is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Orchestrator checklist to verify worker outputs against the approved plan before accepting artifacts. Phase 2 of orchestrator/worker context enforcement (#2020).
Teams using artifact-verification should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/artifact-verification/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How artifact-verification Compares
| Feature / Agent | artifact-verification | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Orchestrator checklist to verify worker outputs against the approved plan before accepting artifacts. Phase 2 of orchestrator/worker context enforcement (#2020).
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Artifact Verification — Orchestrator Checklist
When a worker (subagent, Codex, Gemini, or parallel terminal) returns results,
the orchestrator MUST verify those results against the approved plan before
accepting them. This skill provides the verification protocol.
## Why This Exists
Workers optimize for task completion, not plan adherence. Without verification:
- Workers skip optional deliverables that the plan required
- Workers modify files outside their assigned scope (contention risk)
- Workers produce code that passes tests but drifts from the spec
- Orchestrators rubber-stamp results because the output "looks right"
## When to Use
- After any worker/subagent returns results
- After overnight batch runs (morning review)
- Before merging worker-produced branches
- Before closing a GitHub issue completed by a worker
## Verification Checklist
For each worker output, the orchestrator checks:
### 1. Scope Alignment
- [ ] Files changed match the plan's "Files to Change" list
- [ ] No files outside the worker's assigned scope were modified
- [ ] No files from other workers' negative write boundaries were touched
### 2. Acceptance Criteria
- [ ] Each acceptance criterion from the approved plan is satisfied
- [ ] Evidence exists for each criterion (test output, file content, command result)
- [ ] No acceptance criteria were silently dropped
### 3. Test Coverage
- [ ] Tests were written/updated as specified in the plan
- [ ] Tests pass (verify via `uv run pytest` or equivalent)
- [ ] Test names and coverage match the plan's TDD test list
### 4. Artifact Completeness
- [ ] All deliverables listed in the plan are present
- [ ] Documentation updates (if required by plan) are included
- [ ] Commit messages follow conventional format and reference the issue
### 5. No Unplanned Side Effects
- [ ] No unrelated files were modified (check `git diff --stat`)
- [ ] No new dependencies added that weren't in the plan
- [ ] No configuration changes outside plan scope
## Verification Markers
After verification passes, the orchestrator creates a marker:
```bash
REPO_ROOT="$(git rev-parse --show-toplevel)"
ISSUE=NNN
mkdir -p "$REPO_ROOT/.planning/verified"
cat > "$REPO_ROOT/.planning/verified/$ISSUE.md" << 'MARKER'
# Verification: Issue #NNN
- verified_by: <orchestrator agent or user>
- verified_at: <timestamp>
- worker: <worker agent identity>
- plan: docs/plans/YYYY-MM-DD-issue-NNN-slug.md
- verdict: PASS | PARTIAL | FAIL
## Checklist Results
- [x] Scope alignment
- [x] Acceptance criteria
- [x] Test coverage
- [x] Artifact completeness
- [x] No unplanned side effects
## Notes
<any deviations, partial passes, or follow-up items>
MARKER
```
### Verification Verdicts
| Verdict | Meaning | Action |
|---------|---------|--------|
| **PASS** | All checklist items satisfied | Accept artifacts, proceed to merge/close |
| **PARTIAL** | Most items pass, minor gaps identified | Accept with noted follow-ups |
| **FAIL** | Critical items missing or wrong | Reject, provide specific feedback to worker |
### On FAIL: Feedback Protocol
When verification fails, the orchestrator provides specific feedback:
1. List each failed checklist item with the expected vs actual result
2. Reference the exact plan section that was not met
3. Do NOT give generic rejection ("this doesn't meet the spec")
4. Re-dispatch the worker with the feedback and the relevant plan section
## Integration with Existing Workflow
This skill fits between the implementation step and the close step of
`issue-planning-mode`:
```
Plan Approved --> Worker Implements --> ARTIFACT VERIFICATION --> Cross-Review --> Close
```
The verification step is distinct from cross-review:
- **Verification**: Did the worker build what the plan specified? (scope check)
- **Cross-review**: Is what was built correct and well-engineered? (quality check)
## Overnight Batch Integration
For overnight batch runs with multiple terminals:
1. Each terminal produces its output
2. Morning review runs this checklist for each terminal's output
3. Verification markers are created for each terminal
4. Only verified outputs proceed to cross-review and merge
## References
- Orchestrator-worker methodology: `docs/methodology/orchestrator-worker.md`
- Plan approval gate: `.Codex/hooks/plan-approval-gate.sh`
- Cross-review policy: `.Codex/skills/coordination/cross-review-policy/SKILL.md`
- Session governance: `docs/governance/SESSION-GOVERNANCE.md`Related Skills
subagent-write-verification
Independently verify subagent-claimed file writes with filesystem and git checks before treating the artifact as real, before committing it, and before referencing the path in downstream prompts.
tdd-verification-and-adversarial-review
Verify pre-written TDD tests pass, conduct adversarial code review on committed diffs, and route findings to existing issues
tax-form-navigation-verification
Systematic workflow for verifying tax software calculations against entry guide specifications
portable-pattern-verification-workflow
Multi-package implementation with verification strategy for cross-platform configuration hardening
multi-year-tax-filing-verification-workflow
Verify and reconcile complex multi-form tax filings by cross-referencing source documents, identifying data dependencies, and validating line-by-line against authoritative records.
static-site-build-artifact-plan-review
Plan-review pattern for static-site fixes where the deployed artifact is generated from source files (e.g. sitemap/robots/static assets). Prevents review churn by separating durable regression checks from one-time migration verification and by validating built output, not just source files.
plan-review-handoff-verification
Verify a parked GitHub issue plan-review handoff across live labels, local markers, README rows, canonical review artifacts, and stale plan-body evidence before reporting next action.
plan-review-artifact-authority-and-approval-drift
Keep iterative plan-review artifacts truthful when external reruns overtake self-reviews or stale approval signals remain on older revisions.
plan-draft-review-artifact-truthfulness-and-issue-body-alignment
Keep plan drafts truthful during adversarial review loops by verifying real provider artifact state on disk and aligning the GitHub issue body to the bounded plan tranche before claiming approval-readiness.
overnight-worktree-verification-fallback
Verify overnight multi-worktree Codex batches when auto-sync, duplicate-lane convergence, and sandbox-blocked review create misleading local state or review provenance.
overnight-pre-plan-review-wave-artifact-drift
Run overnight planning-only waves for issues before status:plan-review, and reconcile cases where GitHub state advances but plan/review artifacts land in a sandbox or remote branch instead of the active local worktree.
overnight-plan-wave-artifact-drift-reconciliation
Reconcile overnight planning waves when Codex workers move GitHub issues to status:plan-review but local artifacts are missing, split across sandbox worktrees, or only present on a pushed remote branch.