---
name: project-evidence
description: Use when capturing, reviewing, or requesting evidence for completed planning, architecture, implementation, validation, or decision work.
---

# Project Evidence

Use this skill to make claims verifiable.

Boundary vs `project-evidence-ledger`: this skill **creates** an individual
`EV-*` record for a specific claim; `project-evidence-ledger` **indexes and
reviews** the full set of evidence records.

## Deterministic Record Path

Plan and run `evidence.record` when enabled. It owns duplicate-safe
`prd_record_evidence` creation and exact `prd_get` confirmation. When the
workflow is disabled, call those tools directly; never calculate an `EV-*` ID
or edit the registry.

## Rules

- Use `EV-*` IDs for evidence records.
- Store evidence under `docs/evidence/` unless the repo already has a clear convention.
- Evidence should link to the claim it supports.
- Prefer command output, test results, screenshots, reviewed docs, or source links over narrative claims.
- Binary evidence such as PNG images, PDFs, audio, and video is valid under
  `docs/evidence/`. State consistency skips binary evidence while continuing to
  scan intentional textual claim sources: Markdown, JSON, JSONL, and plain text.
  A malformed file with a textual extension remains a validation error.
- Follow `.prd_plugin/method/grounding.md`: do not claim a record, file, or
  result you have not confirmed exists or run.
- Evidence for document-branch promotion should include anchors and regression
  conditions, not only narrative agreement.
- Evidence that promotes agent memory should cite the target `MEM-*`, `TRK-*`,
  or `CHG-*` record and the source `SES-*` session or artifact.
- Evidence that resolves a health finding should cite the target `HLT-*`
  record.
- Do not claim `MEM-*`, `TRK-*`, `CHG-*`, `OBS-*`, or `SES-*` updates landed
  unless the canonical state records exist.
- Run the required downstream validator
  `python scripts/state_consistency_check.py --repo-root .` before publishing
  evidence that claims memory, tracking, changelog, session, registry, or
  timestamped fixture updates.

## Staleness Coverage

Apply the shared policy in `.prd_plugin/method/staleness-rules.md`.


Evidence used to refresh stale `REQ-*`, `TRK-*`, `DBR-*`, `MEM-*`, or `HLT-*`
records must include current command output, reviewed artifact timestamps, or
other inspectable proof. Do not mark stale records fresh from narrative alone.

## Evidence Record

Each evidence record should include:

1. Evidence ID
2. Claim
3. Linked requirement/task/decision IDs
4. Source artifacts
5. Commands or checks
6. Result
7. Limitations
8. Regression condition, when supporting a promoted document branch
9. `AGENT-*` and `SES-*` provenance, when supporting promoted memory or tracking state
10. Linked `HLT-*` finding, when evidence resolves a health issue

## Review Checklist

- The evidence supports the claim directly.
- Limitations are stated.
- The linked IDs exist.
- Claimed state IDs exist in canonical PRD Plugin state, not only in narrative
  evidence text.
- The result is reproducible or inspectable.
- Promoted memory claims are source-backed and non-sensitive.