verification

Étoiles0

Forks0

Mis à jour14 juin 2026 à 07:22

Trigger only after an implementation exists and must be validated against an explicit plan, acceptance criteria, or expected behavior by running relevant checks and reporting evidence-backed pass/fail results.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

haoyiyin

haoyiyin/yi-workflow

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name	verification
description	Trigger only after an implementation exists and must be validated against an explicit plan, acceptance criteria, or expected behavior by running relevant checks and reporting evidence-backed pass/fail results.
requires	[]

verification — Evidence-Backed Acceptance Skill

1. Trigger Boundary

Use this skill only after implementation exists and must be checked against:

Approved plan criteria.
Acceptance criteria.
Expected behavior.
Regression test requirements.
Wave-level or final execution verification.

Do not use this skill to implement fixes, perform root-cause debugging, review style, or create a plan.

2. Non-Negotiable Constraints

Verify only. Do not modify implementation files.
Criteria-by-criteria judgment. Every acceptance criterion must be marked passed, failed, skipped, or blocked.
Evidence required. Each pass/fail decision must cite command output, file inspection, runtime observation, or explicit reasoning.
Failed required check means not verified. verified: true is valid only when all required criteria pass.
Skipped checks must be explicit. Record reason, risk, and whether user approval is needed.

3. Verification State Machine

State A — Load Requirements

Identify plan, implementation summary, expected behavior, and acceptance criteria. If criteria are absent, derive minimal criteria from the user request and label them as derived.

State B — Select Checks

Choose the smallest sufficient check set:

Automated tests.
Build/typecheck/lint commands.
Targeted runtime checks.
Static inspection for non-executable criteria.

State C — Execute Checks

Run checks and capture exact results. If a command cannot run, mark the corresponding criterion blocked or skipped, not passed.

State D — Decide Verification

Return verified: true only when every required criterion passes and no required command failed.

4. Negative Prompts

Never change code while verifying.
Never return verified: true after failed tests.
Never omit failed command output from the report.
Never collapse multiple criteria into a vague “looks good”.
Never silently skip checks.
Never treat unavailable evidence as success.

5. Final Output Format

status: verified | failed | blocked
verified: boolean
criteria:
  - id: string
    description: string
    result: passed | failed | skipped | blocked
    evidence: string
commands:
  - command: string
    result: passed | failed | skipped
    summary: string
passed: string[]
failed: string[]
skipped: string[]
blockedReason: string | null
nextAction: none | fix | debug | provide-environment | accept-risk

Plus depuis ce dépôt

même dépôt

execute-plan

haoyiyin/yi-workflow

Trigger only when an already-approved PLAN.md or equivalent structured plan must be executed through wave-ordered tasks, isolated git worktrees, wave-level verification, final integration, and controlled merge handling; never create the plan or execute unapproved work.

2026-06-140

review-diff

haoyiyin/yi-workflow

Trigger only to inspect an existing diff, commit, branch, or PR for correctness, regression, security, performance, and maintainability issues; do not use to implement changes or run acceptance verification.

2026-06-140

systematic-debugging

haoyiyin/yi-workflow

Trigger only when an observed failure, reproducible bug, regression, stack trace, failing test, or merge conflict requires evidence-based root-cause diagnosis before applying or recommending a fix.

2026-06-140

tdd

haoyiyin/yi-workflow

Trigger only when the user explicitly requests test-driven implementation or when an assigned task requires adding behavior by first writing a failing test, then minimal code, then refactoring without behavior change.

2026-06-140

to-plan

haoyiyin/yi-workflow

Trigger only when a coding task requires a written implementation plan before execution, especially multi-file or multi-step work needing dependency analysis, wave classification, and file-isolation-safe task partitioning; dispatches Planner to write a timestamped plan under ~/.yi-workflow/docs/plans/ and performs no implementation.

2026-06-140

name	verification
description	Trigger only after an implementation exists and must be validated against an explicit plan, acceptance criteria, or expected behavior by running relevant checks and reporting evidence-backed pass/fail results.
requires	[]

verification — Evidence-Backed Acceptance Skill

1. Trigger Boundary

Use this skill only after implementation exists and must be checked against:

Approved plan criteria.
Acceptance criteria.
Expected behavior.
Regression test requirements.
Wave-level or final execution verification.

Do not use this skill to implement fixes, perform root-cause debugging, review style, or create a plan.

2. Non-Negotiable Constraints

Verify only. Do not modify implementation files.
Criteria-by-criteria judgment. Every acceptance criterion must be marked passed, failed, skipped, or blocked.
Evidence required. Each pass/fail decision must cite command output, file inspection, runtime observation, or explicit reasoning.
Failed required check means not verified. verified: true is valid only when all required criteria pass.
Skipped checks must be explicit. Record reason, risk, and whether user approval is needed.

3. Verification State Machine

State A — Load Requirements

Identify plan, implementation summary, expected behavior, and acceptance criteria. If criteria are absent, derive minimal criteria from the user request and label them as derived.

State B — Select Checks

Choose the smallest sufficient check set:

Automated tests.
Build/typecheck/lint commands.
Targeted runtime checks.
Static inspection for non-executable criteria.

State C — Execute Checks

Run checks and capture exact results. If a command cannot run, mark the corresponding criterion blocked or skipped, not passed.

State D — Decide Verification

Return verified: true only when every required criterion passes and no required command failed.

4. Negative Prompts

Never change code while verifying.
Never return verified: true after failed tests.
Never omit failed command output from the report.
Never collapse multiple criteria into a vague “looks good”.
Never silently skip checks.
Never treat unavailable evidence as success.

5. Final Output Format

status: verified | failed | blocked
verified: boolean
criteria:
  - id: string
    description: string
    result: passed | failed | skipped | blocked
    evidence: string
commands:
  - command: string
    result: passed | failed | skipped
    summary: string
passed: string[]
failed: string[]
skipped: string[]
blockedReason: string | null
nextAction: none | fix | debug | provide-environment | accept-risk