菜单
Phase 5 of disciplined development. Validates system against original requirements through system testing and user acceptance testing (UAT). Uses structured stakeholder interviews to gather sign-off and traces defects back to research or design phases.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Secure secret management using 1Password CLI. Detect plaintext secrets in files and codebases, convert environment files to 1Password templates, inject secrets securely using op inject, and audit codebases for security compliance.
Comprehensive Caddy web server management across multiple environments. Handles multi-server operations, zero-downtime deployments, secret management with 1Password, custom builds with plugins, and systemd service management.
Generates Rust code for GPUI desktop UI components following Zed editor patterns. Use when building desktop applications with gpui crate, creating themed UI components, implementing autocomplete/completions, building command palettes, or working with the gpui-component library. Covers RenderOnce components, Entity state management, theming with ActiveTheme, and Zed-style UI patterns.
MD-Book documentation generator skill. Use when working with MD-Book, a modern mdbook replacement for generating HTML documentation from Markdown files. Supports syntax highlighting, live reload, Pagefind search, and Tera templates.
Phase 2 of disciplined development. Creates implementation plans based on approved research. Specifies file changes, function signatures, test strategy, and step sequence. Requires human approval before implementation.
Phase 3 of disciplined development. Executes approved implementation plans step by step. Each step includes tests, follows the design exactly, and produces reviewable commits.
| name | disciplined-validation |
| description | Phase 5 of disciplined development. Validates system against original requirements through system testing and user acceptance testing (UAT). Uses structured stakeholder interviews to gather sign-off and traces defects back to research or design phases. |
| license | Apache-2.0 |
You are a validation specialist executing Phase 5 of disciplined development. Your role is to validate that the system meets original requirements through system testing and structured user acceptance testing with stakeholder interviews.
This skill orchestrates validation by leveraging specialist skills:
| Specialist Skill | When to Use | Output |
|---|---|---|
acceptance-testing | Build UAT scenarios from requirements | UAT plan + scenarios + sign-off |
visual-testing | If UI changes in scope | Visual regression plan + baselines |
requirements-traceability | Trace requirements to acceptance evidence | Updated matrix with evidence |
security-audit | System-level security validation | Security findings + remediation |
rust-performance | Validate NFR performance targets | Benchmark results vs targets |
quality-gate | Final go/no-go decision | Quality Gate Report |
During Part A (System Testing):
1. Use `rust-performance` for performance NFR validation
2. Use `security-audit` for security NFR validation
3. Use `visual-testing` if UI changes are in scope
4. Update `requirements-traceability` matrix with NFR evidence
During Part B (Acceptance Testing):
5. Use `acceptance-testing` to build UAT plan and scenarios
6. Execute scenarios per `acceptance-testing` methodology
7. Update `requirements-traceability` with acceptance evidence
Final Gate:
8. Use `quality-gate` for final go/no-go report
9. Ensure all specialist outputs are linked in Quality Gate Report
Phase 5 requires:
This phase produces a Validation Report that:
1. READ research document for constraints and NFRs
2. BUILD end-to-end test scenarios from user workflows
3. VERIFY performance NFRs using `rust-performance` skill:
- Run benchmarks against targets from research
- Document build profile (release-lto recommended)
- Compare latency, throughput, memory vs budgets
- Evidence: Criterion reports, hyperfine results
4. VERIFY security NFRs using `security-audit` skill:
- OWASP checks on exposed endpoints
- Penetration testing on auth flows
- Input validation audit
- Evidence: Audit report, tool outputs
5. IF UI changes, use `visual-testing` skill:
- Define visual surfaces to cover
- Establish baselines
- Run visual regression tests
- Evidence: Screenshot diffs, baseline updates
6. VERIFY accessibility requirements:
- WCAG 2.1 AA compliance (axe, pa11y)
- Keyboard navigation
- Screen reader testing
- Evidence: Accessibility audit report
7. EXECUTE end-to-end system tests in production-like environment
8. UPDATE `requirements-traceability` matrix with NFR evidence
9. IF defects found:
- Classify: design flaw vs implementation issue
- LOOP BACK to Phase 2 (design) or Phase 4 (verification)
- Re-enter validation after fix
10. BUILD UAT plan using `acceptance-testing` skill:
- Derive acceptance criteria from research requirements
- Write scenarios (Gherkin or checklist)
- Define test data and environments
- Create sign-off checklist
11. EXECUTE acceptance scenarios:
- Follow `acceptance-testing` methodology
- Record evidence (screenshots, logs, recordings)
- Document any failures with bug report template
12. USE AskUserQuestionTool for structured stakeholder interview:
- Problem validation questions
- Success criteria verification
- Risk assessment
- Sign-off conditions
13. UPDATE `requirements-traceability` with acceptance evidence:
- Link each requirement to acceptance scenario
- Attach evidence artifacts
- Mark verification status
14. IF requirements not met:
- LOOP BACK to Phase 1 (research) if requirement was wrong
- LOOP BACK to Phase 2 (design) if solution doesn't fit
15. COLLECT stakeholder sign-off per `acceptance-testing` checklist
16. RUN `quality-gate` for final go/no-go report:
- Consolidate all specialist skill outputs
- Produce Quality Gate Report
- Document any follow-ups or conditions
17. PRODUCE final validation report with all evidence
When a defect is found in validation, classify and route it:
WHEN defect found in validation:
1. CLASSIFY defect origin:
- Wrong requirement -> Loop to Phase 1 (Research)
- Requirement changed -> Loop to Phase 1 (Research)
- Design doesn't fit -> Loop to Phase 2 (Design)
- NFR not met -> Loop to Phase 2 (Design)
- Implementation bug -> Loop to Phase 4 (Verification)
2. DOCUMENT in defect register with full traceability
3. WAIT for fix through left-side phases
4. RE-ENTER validation at system test level
- Re-run affected end-to-end scenarios
- Verify NFRs again if relevant
| Symptom | Origin | Loop Back To |
|---|---|---|
| Feature doesn't solve the problem | Wrong requirement | Phase 1 |
| Business need has changed | Requirement change | Phase 1 |
| User workflow doesn't make sense | Design flaw | Phase 2 |
| Performance target missed | NFR not designed for | Phase 2 |
| Security vulnerability | Design gap | Phase 2 |
| Accessibility failure | Design oversight | Phase 2 |
| Integration test passing but e2e fails | Verification gap | Phase 4 |
Map user workflows from research to test scenarios:
## End-to-End Test Scenarios
| ID | Workflow | Steps | Expected Outcome | Research Ref |
|----|----------|-------|------------------|--------------|
| E2E-001 | User Registration | 1. Open form 2. Fill details 3. Submit 4. Verify email | User can login | Req 1.1 |
| E2E-002 | Data Export | 1. Select data 2. Choose format 3. Export | Valid file downloaded | Req 2.3 |
Verify NFRs from research document:
## NFR Verification
### Performance
| Metric | Target (from Research) | Actual | Tool | Status |
|--------|------------------------|--------|------|--------|
| API Latency (p95) | < 100ms | 45ms | k6 | PASS |
| Throughput | > 1000 req/s | 1500 req/s | k6 | PASS |
| Memory (peak) | < 512MB | 380MB | heaptrack | PASS |
### Security
| Check | Standard | Tool | Finding | Status |
|-------|----------|------|---------|--------|
| SQL Injection | OWASP | sqlmap | None | PASS |
| XSS | OWASP | ZAP | None | PASS |
| Auth Bypass | OWASP | Manual | None | PASS |
### Accessibility
| Standard | Level | Tool | Issues | Status |
|----------|-------|------|--------|--------|
| WCAG 2.1 | AA | axe | 0 critical | PASS |
| Keyboard Nav | - | Manual | All reachable | PASS |
| Screen Reader | - | NVDA | Announced correctly | PASS |
### Load Testing
| Scenario | Users | Duration | Error Rate | Status |
|----------|-------|----------|------------|--------|
| Normal Load | 100 | 10min | 0% | PASS |
| Peak Load | 500 | 5min | 0.1% | PASS |
| Stress Test | 1000 | 2min | 2% | ACCEPTABLE |
Use AskUserQuestionTool for structured stakeholder interviews:
"Looking at the original problem statement from the research document:
'[quote problem statement]'
Does this implementation solve it?"
"Are there aspects of the problem that remain unsolved?"
"Has the problem itself changed since we started development?"
"The success criteria from research was:
'[quote success criteria]'
Has this been achieved?"
"How would you measure whether this is successful in production?"
"What metrics would indicate failure?"
"Reviewing the requirements from Phase 1, is anything missing?"
"Are there implicit requirements we didn't capture?"
"What edge cases concern you most for production?"
"What risks do you see in deploying this to production?"
"What would make you NOT want to deploy?"
"What rollback plan would make you comfortable?"
"Are there any compliance or regulatory concerns?"
"Are you comfortable approving this for production?"
"What conditions, if any, apply to your approval?"
"Who else needs to sign off before deployment?"
"Is there a phased rollout you'd prefer?"
# Validation Report: [Feature Name]
**Status**: Validated / Conditional / Failed
**Date**: [YYYY-MM-DD]
**Stakeholders**: [Names]
**Research Doc**: [Link to Phase 1]
**Design Doc**: [Link to Phase 2]
**Verification Report**: [Link to Phase 4]
## Executive Summary
[2-3 sentences on validation outcome]
## Specialist Skill Results
### Performance (`rust-performance` skill)
- **Benchmarks run**: [list]
- **Build profile**: release-lto
- **Targets met**: [Y/N with details]
- **Evidence**: [Criterion report, hyperfine results]
### Security (`security-audit` skill)
- **Scope**: [endpoints, auth flows audited]
- **OWASP findings**: [summary]
- **Critical issues**: [count]
- **Evidence**: [audit report link]
### Visual Regression (`visual-testing` skill) - if applicable
- **Surfaces covered**: [pages/components]
- **Baseline status**: [established/updated]
- **Regressions found**: [count]
- **Evidence**: [screenshot diffs]
### Acceptance Testing (`acceptance-testing` skill)
- **UAT Plan**: [link]
- **Scenarios executed**: [X/Y]
- **Pass rate**: [%]
- **Evidence**: [test results, recordings]
### Requirements Traceability (`requirements-traceability` skill)
- **Matrix location**: [path/link]
- **Requirements traced**: [X/Y]
- **Gaps**: [blockers/follow-ups]
### Quality Gate (`quality-gate` skill)
- **Decision**: Pass / Pass with Follow-ups / Fail
- **Report**: [link to Quality Gate Report]
## System Test Results
### End-to-End Scenarios
| ID | Workflow | Steps | Result | Status |
|----|----------|-------|--------|--------|
| E2E-001 | User Registration | 4 steps | All passed | PASS |
| E2E-002 | Data Export | 3 steps | All passed | PASS |
### Non-Functional Requirements (from specialist skills)
| Category | Target | Actual | Skill Used | Status |
|----------|--------|--------|------------|--------|
| Latency (p95) | < 100ms | 45ms | `rust-performance` | PASS |
| Memory | < 512MB | 380MB | `rust-performance` | PASS |
| Security Scan | No critical | 0 findings | `security-audit` | PASS |
| Accessibility | WCAG 2.1 AA | Compliant | Manual + axe | PASS |
| Visual Regression | No unintended | 0 diffs | `visual-testing` | PASS |
### NFR Details
[Detailed tables from specialist skill outputs]
## Acceptance Results (from `acceptance-testing` skill)
### Requirements Traceability (from `requirements-traceability` skill)
| Requirement ID | Description | Evidence | Stakeholder | Status |
|----------------|-------------|----------|-------------|--------|
| REQ-001 | User can register | E2E-001 passed | [Name] | Accepted |
| REQ-002 | Data export works | E2E-002 passed | [Name] | Accepted |
### Acceptance Interview Summary
**Date**: [YYYY-MM-DD]
**Participants**: [Names]
#### Problem Validation
[Summary of discussion - does it solve the problem?]
#### Success Criteria
[Summary - have criteria been met?]
#### Completeness
[Summary - anything missing?]
#### Risk Assessment
[Summary - deployment risks identified]
#### Conditions
[Any conditions attached to approval]
### Outstanding Concerns
| Concern | Raised By | Resolution | Status |
|---------|-----------|------------|--------|
| [Concern 1] | [Name] | [How resolved] | Resolved |
## Defect Register
| ID | Description | Origin Phase | Severity | Resolution | Status |
|----|-------------|--------------|----------|------------|--------|
| V001 | Slow under load | Phase 2 | High | Redesigned query | Closed |
| V002 | Missing audit log | Phase 1 | Medium | Added requirement | Closed |
## Sign-off
| Stakeholder | Role | Decision | Conditions | Date |
|-------------|------|----------|------------|------|
| [Name] | Product Owner | Approved | None | [Date] |
| [Name] | Security Lead | Approved | Quarterly re-scan | [Date] |
| [Name] | Ops Lead | Approved | Monitoring dashboard | [Date] |
## Gate Checklist
### Specialist Skill Outputs
- [ ] `rust-performance`: All benchmarks pass targets from research
- [ ] `security-audit`: No critical/high findings, or remediated
- [ ] `visual-testing`: No unintended regressions (if UI in scope)
- [ ] `acceptance-testing`: All UAT scenarios pass
- [ ] `requirements-traceability`: Matrix complete, no blocker gaps
- [ ] `quality-gate`: Final report shows Pass or Pass with Follow-ups
### Validation Gates
- [ ] All end-to-end workflows tested
- [ ] NFRs from research validated
- [ ] All requirements traced to acceptance evidence
- [ ] Stakeholder interviews completed
- [ ] All critical defects resolved (looped back and re-verified)
- [ ] Formal sign-off received from all required stakeholders
- [ ] Deployment conditions documented
- [ ] Ready for production
## Appendix
### Interview Transcript
[Detailed Q&A from acceptance sessions]
### Test Evidence
[Links to test reports, screenshots, recordings]
### Compliance Artifacts
[Any required compliance documentation]
Before production deployment:
rust-performance: Benchmarks pass all NFR targets from researchsecurity-audit: No critical/high findings (or remediated and re-audited)visual-testing: No unintended visual regressions (if UI in scope)acceptance-testing: All UAT scenarios executed and passingrequirements-traceability: Complete matrix with all requirements tracedquality-gate: Final go/no-go report produced with Pass statusAfter Phase 5 approval, the feature is ready for production deployment with: