AgentSkillsCN

verify-requirements

针对可追溯的开发生命周期(TDL),在项目实施完成后进行需求验证。通过检查代码、测试用例与验收标准,确认已完成任务的实施是否真正满足其对应的需求。当出现以下情况时,这一技能将派上用场:(1) 任务实施完毕,需对照需求进行验证;(2) 用户提出“验证需求”或“检查需求”;(3) 用户希望在实施阶段结束后获取一份验证报告;(4) 用户在任务ID后附加“/verify-requirements”。当您听到诸如“验证T-xxxxx”“检查需求是否达成”“需求验证”“实施后检查”“根据需求验证实施效果”等表述时,这一技能将助您高效完成任务。

SKILL.md
--- frontmatter
name: verify-requirements
description: >
  Post-implementation requirements verification for the Traceable Development Lifecycle (TDL).
  Verify whether a completed task's implementation satisfies its linked requirements by inspecting
  code, tests, and acceptance criteria. Use when: (1) Implementation of a task is complete and
  needs verification against requirements, (2) User says "verify requirements" or "check requirements"
  for a task, (3) User wants a verification report after finishing implementation phases,
  (4) User mentions "/verify-requirements" with a task ID. Trigger on phrases like
  "verify T-xxxxx", "check if requirements are met", "requirements verification",
  "post-implementation check", or "validate implementation against requirements".

Post-Implementation Requirements Verification

Verify that a completed implementation satisfies its linked TDL requirements.

Workflow

code
1. Identify task → 2. Collect requirements → 3. Analyze code → 4. Generate report → 5. Update docs

Step 1: Identify Task

Determine the target task from user input. Accept any of:

  • Full task ID: T-r7k2p-mission-execution-sequencer
  • Short ID: T-r7k2p
  • Task directory path: docs/tasks/T-r7k2p-mission-execution-sequencer/

Find the task directory by searching docs/tasks/T-<id>-*/.

Read these files:

  • README.md — extract Related Requirements links (FR-*, NFR-*)
  • plan.md — extract Known Gaps, Definition of Done, phase completion status

Step 2: Collect Requirements

For each requirement linked in the task README:

  1. Read the requirement file (docs/requirements/FR-<id>-<name>.md or NFR-<id>-<name>.md)
  2. Extract Acceptance Criteria (the - [ ] / - [x] checklist items)
  3. Note the requirement type: Functional (FR) vs Non-Functional (NFR)

Classify each criterion by verification method. See references/verification-guide.md for details.

Step 3: Analyze Implementation

For each acceptance criterion, determine its status using evidence:

  • Code inspection: Search for traits, structs, functions; verify signatures and error handling
  • Test verification: Search for unit tests covering the criterion; run cargo test --lib --quiet if needed
  • Build verification: Check ./scripts/build-rp2350.sh for embedded requirements
  • Static analysis: cargo clippy, check for unsafe code, verify no_std compatibility
  • Documentation check: Verify docs exist, run bun scripts/trace-status.ts --check

Step 4: Generate Report

Produce a verification report. See references/verification-guide.md for the full template and status definitions.

Summary format:

markdown
# Verification Report: T-<id>-<name>

## Summary
| Metric | Count |
|--------|-------|
| Total criteria | N |
| PASS | N |
| FAIL | N |
| PARTIAL | N |
| N/V | N |

## Results by Requirement
### FR-<id>-<name>
| # | Criterion | Status | Evidence |
|---|-----------|--------|----------|
| 1 | <text> | PASS | <file:line, test name, etc.> |

Step 5: Update Documents (optional, with user approval)

Ask the user before modifying any files. If approved:

  • Mark - [x] for PASS criteria in requirement files
  • Leave - [ ] for FAIL/PARTIAL/N/V criteria
  • Add Known Gaps to plan.md for FAIL/PARTIAL items not already documented

Rules

  • Evidence required: Every status must cite file:line, test names, or command outputs
  • Conservative judgment: When uncertain, use PARTIAL or N/V rather than PASS
  • Performance criteria: NFRs about timing/memory/latency are N/V unless benchmarks exist
  • Known gaps first: Check plan.md Known Gaps before analyzing — pre-identified issues save time
  • Scope awareness: Only verify criteria relevant to the task's stated scope