verify

Files (3)

• SKILL.md
• feature-review-checklist.md · resources/
• verification-report-template.md · resources/

SKILL.md (first lines)

# Verify

This is a human-facing skill.

Use it when the user wants Darwin to inspect what has already been built and decide whether the feature is actually complete, what is missing, and what should improve next.

## Purpose

Turn the current built state of a feature into a saved verification report.

The report should answer:

- what source docs define the feature
- what slices appear complete versus incomplete
- what was verified with fresh evidence
- what is missing, weak, or inconsistent
- whether the feature feels good enough as-is
- what the next improvements should be, if any

## Dependencies

- `using-darwin`
- `clarifying-intent`
- `verification-before-completion`
- `debrief-and-learn`
- `skills/verify/resources/feature-review-checklist.md`
- `skills/verify/resources/verification-report-template.md`

## Clarification Rule

Ask at most 3 clarifying questions before starting the review.

Questions should focus on:

- which feature doc or decomposition doc is the source of truth
- what "done" means for this review
- whether the user wants correctness-only review or also UX/product improvement suggestions

## Workflow

1. Read the relevant source artifacts: feature doc, decomposition, and any definition-of-done notes.
2. Inspect the current implementation and identify what appears to be shipped.
3. Use the feature review checklist to compare the built state against the intended scope and success criteria.
4. Run fresh verification using `verification-before-completion` for the claims the report makes.
5. Save the result to `docs/verification/<date>-<slug>.md` using the verification report template.
6. Run a collaborative debrief with the operator about the quality of the feature, the review process, and whether Darwin missed anything.
7. Canonize any clear Darwin improvement immediately when it belongs in a skill, prompt, or resource.
8. End with the next best step: feature is solid as-is, build the next slice, fix a gap, or redefine the scope.

## Output To The User

Keep the interaction simple:

- a few high-value questions only when needed
- a concise readout of what is solid and what is missing
- a saved verification report in `docs/verification/`
- a clear recommendation for the next step

## Guardrails

- Do not confuse code inspection with verification. Claims still need fresh evidence.
- Do not invent problems when the feature is genuinely in a good place.
- Do not claim completeness just because the code exists.
- Do not skip UX or product-level gaps when the user asked for a fuller review.

From tykowale/darwin, MIT.

More from tykowale/darwin