From prism-devtools
Use to perform comprehensive test architecture review with quality gate decision. Creates both story updates and detailed gate files.
npx claudepluginhub resolve-io/.prismThis skill uses the workspace's default tool permissions.
<!-- Powered by PRISMâ„¢ System -->
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Provides patterns for autonomous Claude Code loops: sequential pipelines, agentic REPLs, PR cycles, de-sloppify cleanups, and RFC-driven multi-agent DAGs. For continuous dev workflows without intervention.
Applies NestJS patterns for modules, controllers, providers, DTO validation, guards, interceptors, config, and production TypeScript backends with project structure and bootstrap examples.
Perform a comprehensive test architecture review with quality gate decision. This adaptive, risk-aware review creates both a story update and a detailed gate file.
required:
- story_id: '{story}.{story}' # e.g., "1.3"
- story_path: '{devStoryLocation}/{story}.{story}.*.md' # Path from core-config.yaml
- story_title: '{title}' # If missing, derive from story file H1
- story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
Auto-escalate to deep review when:
A. Requirements Traceability
B. Code Quality Review
C. Test Architecture Assessment
D. Non-Functional Requirements (NFRs)
E. Testability Evaluation
F. Technical Debt Identification
docs/coding-standards.mddocs/unified-project-structure.mddocs/testing-strategy.mdCRITICAL: You are ONLY authorized to update the "QA Results" section of the story file. DO NOT modify any other sections.
QA Results Anchor Rule:
## QA Results doesn't exist, append it at end of fileAfter review and any refactoring, append your results to the story file in the QA Results section:
## QA Results
### Review Date: [Date]
### Reviewed By: Quinn (Test Architect)
### Code Quality Assessment
[Overall assessment of implementation quality]
### Refactoring Performed
[List any refactoring you performed with explanations]
- **File**: [filename]
- **Change**: [what was changed]
- **Why**: [reason for change]
- **How**: [how it improves the code]
### Compliance Check
- Coding Standards: [✓/✗] [notes if any]
- Project Structure: [✓/✗] [notes if any]
- Testing Strategy: [✓/✗] [notes if any]
- All ACs Met: [✓/✗] [notes if any]
### Improvements Checklist
[Check off items you handled yourself, leave unchecked for dev to address]
- [x] Refactored user service for better error handling (services/user.service.ts)
- [x] Added missing edge case tests (services/user.service.test.ts)
- [ ] Consider extracting validation logic to separate validator class
- [ ] Add integration test for error scenarios
- [ ] Update API documentation for new error codes
### Security Review
[Any security concerns found and whether addressed]
### Performance Considerations
[Any performance issues found and whether addressed]
### Files Modified During Review
[If you modified files, list them here - ask Dev to update File List]
### Gate Status
Gate: {STATUS} → qa.qaLocation/gates/{story}.{story}-{slug}.yml
Risk profile: qa.qaLocation/assessments/{story}.{story}-risk-{YYYYMMDD}.md
NFR assessment: qa.qaLocation/assessments/{story}.{story}-nfr-{YYYYMMDD}.md
# Note: Paths should reference core-config.yaml for custom configurations
### Recommended Status
[✓ Ready for Done] / [✗ Changes Required - See unchecked items above]
(Story owner decides final status)
Template and Directory:
../templates/qa-gate-tmpl.yamlqa.qaLocation/gates (see ../core-config.yaml) if missingqa.qaLocation/gates/{story}.{story}-{slug}.ymlGate file structure:
schema: 1
story: '{story}.{story}'
story_title: '{story title}'
gate: PASS|CONCERNS|FAIL|WAIVED
status_reason: '1-2 sentence explanation of gate decision'
reviewer: 'Quinn (Test Architect)'
updated: '{ISO-8601 timestamp}'
top_issues: [] # Empty if no issues
waiver: { active: false } # Set active: true only if WAIVED
# Extended fields (optional but recommended):
quality_score: 0-100 # 100 - (20*FAILs) - (10*CONCERNS) or use technical-preferences.md weights
expires: '{ISO-8601 timestamp}' # Typically 2 weeks from review
evidence:
tests_reviewed: { count }
risks_identified: { count }
trace:
ac_covered: [1, 2, 3] # AC numbers with test coverage
ac_gaps: [4] # AC numbers lacking coverage
nfr_validation:
security:
status: PASS|CONCERNS|FAIL
notes: 'Specific findings'
performance:
status: PASS|CONCERNS|FAIL
notes: 'Specific findings'
reliability:
status: PASS|CONCERNS|FAIL
notes: 'Specific findings'
maintainability:
status: PASS|CONCERNS|FAIL
notes: 'Specific findings'
recommendations:
immediate: # Must fix before production
- action: 'Add rate limiting'
refs: ['api/auth/login.ts']
future: # Can be addressed later
- action: 'Consider caching'
refs: ['services/data.ts']
Deterministic rule (apply in order):
If risk_summary exists, apply its thresholds first (≥9 → FAIL, ≥6 → CONCERNS), then NFR statuses, then top_issues severity.
Risk thresholds (if risk_summary present):
Test coverage gaps (if trace available):
Issue severity:
top_issues.severity == high → Gate = FAIL (unless waived)severity == medium → Gate = CONCERNSNFR statuses:
Detailed criteria:
quality_score = 100 - (20 × number of FAILs) - (10 × number of CONCERNS)
Bounded between 0 and 100
If technical-preferences.md defines custom weights, use those instead.
For each issue in top_issues, include a suggested_owner:
dev: Code changes neededsm: Requirements clarification neededpo: Business decision neededStop the review and request clarification if:
After review:
qa.qaLocation/gates