Design review
When to use
Use this skill in one explicitly selected mode:
- Prepare mode: assemble an evidence-backed review packet before a review.
- Document mode: record an outcome that an authoritative human source says was made.
Do not use it to make a design decision, edit the artifact, or infer approval from a
meeting invite or silence. Not for unscoped aesthetic preference, implementation work,
or publishing requirements and decisions without preview and human confirmation.
Inputs and source discipline
- Start with the mode, review scope, timezone, and as-of date/time. Identify the artifact
and exact version, revision, or snapshot; if the version is missing, say so and do not
merge evidence from different iterations.
- Gather requirements, user stories, constraints, research, feedback, and prior decisions
from named sources. Record source path or ID, source date, artifact location, and access
date/as-of for each item.
- In document mode, identify the authoritative review record and decision authority. Do
not infer participants, owners, intent, or approval from context.
- Keep evidence tied to the artifact version reviewed. A later revision is a new subject,
not a correction to the old record.
Method
- Confirm prepare or document mode and the exact artifact/version under review.
- Build a requirement-to-evidence trace: requirement, artifact location, supporting source
and date, and observed/inferred/unknown status. Include contradictory requirements or
feedback rather than silently choosing one.
- Inspect the artifact and evidence read-only. Record strengths, risks, open questions,
and traceable findings with confidence; do not add requirements that are not sourced.
- In prepare mode, list options, trade-offs, and questions for human reviewers without
selecting an option. In document mode, record only decisions explicitly stated by the
authoritative source and label them proposed, accepted, or superseded as supported.
- Separate recommendations from authorized decisions. A recommendation is not a human
decision, and an unresolved question stays unresolved.
- Draft the packet or outcome record with sources, dates, as-of provenance, unknowns, and
contradictions. Preview the exact save before requesting confirmation.
Truth and uncertainty rules
- Observed: a requirement, design detail, feedback item, or decision directly present in
the cited artifact or dated source.
- Inferred: an interpretation of a design effect or requirement relationship; explain
the evidence and confidence.
- Unknown: missing version, requirement, rationale, participant, authority, or outcome.
- Stale: evidence tied to an older artifact/version or outside the requested as-of
boundary; do not apply it to a newer revision without re-checking.
- Contradictory: requirements, feedback, or review sources disagree; preserve the
conflict and dates and ask the human authority to resolve it.
Never invent dates, metrics, percentages, owners, intent, money, causes, status, or
evidence. Never convert a suggestion into an accepted decision.
Output contract
Return a review record containing:
- mode, review scope, artifact/version, timezone, as-of date/time, and source coverage;
- the requirement/evidence trace with source/date references and confidence;
- findings, options, trade-offs, unknowns, stale evidence, and contradictions;
- in prepare mode, recommendations and explicit decision questions;
- in document mode, only sourced proposed, accepted, or superseded decisions, with the
authoritative source and date; never imply a decision where the record is unknown.
Safety and write boundaries
Default to read-only in both modes. Do not edit design files, requirements, tickets, or
decision records while preparing or reviewing. A document-mode save or other action needs
an exact preview, explicit confirm, and human authority; perform only the confirmed write.
Recommendations do not authorize design changes or decisions.
Verification and recovery
Read back the artifact/version and every requirement/evidence reference, then reconcile
decision labels, sources, dates, and as-of scope before delivery. After an authorized save,
read back the destination and reconcile it with the confirmed preview. If the artifact
changes, a version is stale, a source is contradictory, or a read fails, stop and mark the
affected item unknown or stale. If a write fails or is partial, preserve the draft and
error, report the exact state, and wait for human authority before retrying or recovering;
do not claim a decision was documented without read-back proof.
1---2name: design-review-23description: Use when a design artifact or revision needs a prepared review packet or an evidence-backed record of a review outcome, requirements, and decisions.4---56# Design review78## When to use910Use this skill in one explicitly selected mode:1112- **Prepare mode:** assemble an evidence-backed review packet before a review.13- **Document mode:** record an outcome that an authoritative human source says was made.1415Do not use it to make a design decision, edit the artifact, or infer approval from a16meeting invite or silence. Not for unscoped aesthetic preference, implementation work,17or publishing requirements and decisions without preview and human confirmation.1819## Inputs and source discipline2021- Start with the mode, review scope, timezone, and as-of date/time. Identify the artifact22 and exact version, revision, or snapshot; if the version is missing, say so and do not23 merge evidence from different iterations.24- Gather requirements, user stories, constraints, research, feedback, and prior decisions25 from named sources. Record source path or ID, source date, artifact location, and access26 date/as-of for each item.27- In document mode, identify the authoritative review record and decision authority. Do28 not infer participants, owners, intent, or approval from context.29- Keep evidence tied to the artifact version reviewed. A later revision is a new subject,30 not a correction to the old record.3132## Method33341. Confirm prepare or document mode and the exact artifact/version under review.352. Build a requirement-to-evidence trace: requirement, artifact location, supporting source36 and date, and observed/inferred/unknown status. Include contradictory requirements or37 feedback rather than silently choosing one.383. Inspect the artifact and evidence read-only. Record strengths, risks, open questions,39 and traceable findings with confidence; do not add requirements that are not sourced.404. In prepare mode, list options, trade-offs, and questions for human reviewers without41 selecting an option. In document mode, record only decisions explicitly stated by the42 authoritative source and label them proposed, accepted, or superseded as supported.435. Separate recommendations from authorized decisions. A recommendation is not a human44 decision, and an unresolved question stays unresolved.456. Draft the packet or outcome record with sources, dates, as-of provenance, unknowns, and46 contradictions. Preview the exact save before requesting confirmation.4748## Truth and uncertainty rules4950- **Observed:** a requirement, design detail, feedback item, or decision directly present in51 the cited artifact or dated source.52- **Inferred:** an interpretation of a design effect or requirement relationship; explain53 the evidence and confidence.54- **Unknown:** missing version, requirement, rationale, participant, authority, or outcome.55- **Stale:** evidence tied to an older artifact/version or outside the requested as-of56 boundary; do not apply it to a newer revision without re-checking.57- **Contradictory:** requirements, feedback, or review sources disagree; preserve the58 conflict and dates and ask the human authority to resolve it.5960Never invent dates, metrics, percentages, owners, intent, money, causes, status, or61evidence. Never convert a suggestion into an accepted decision.6263## Output contract6465Return a review record containing:6667- mode, review scope, artifact/version, timezone, as-of date/time, and source coverage;68- the requirement/evidence trace with source/date references and confidence;69- findings, options, trade-offs, unknowns, stale evidence, and contradictions;70- in prepare mode, recommendations and explicit decision questions;71- in document mode, only sourced proposed, accepted, or superseded decisions, with the72 authoritative source and date; never imply a decision where the record is unknown.7374## Safety and write boundaries7576Default to read-only in both modes. Do not edit design files, requirements, tickets, or77decision records while preparing or reviewing. A document-mode save or other action needs78an exact preview, explicit confirm, and human authority; perform only the confirmed write.79Recommendations do not authorize design changes or decisions.8081## Verification and recovery8283Read back the artifact/version and every requirement/evidence reference, then reconcile84decision labels, sources, dates, and as-of scope before delivery. After an authorized save,85read back the destination and reconcile it with the confirmed preview. If the artifact86changes, a version is stale, a source is contradictory, or a read fails, stop and mark the87affected item unknown or stale. If a write fails or is partial, preserve the draft and88error, report the exact state, and wait for human authority before retrying or recovering;89do not claim a decision was documented without read-back proof.
davekilleen