Agent skill
hostile-review
MANDATORY adversarial code review. Use before ANY commit to find security vulnerabilities, logic flaws, and edge cases. Actively tries to break the code.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/development/hostile-review
SKILL.md
GATE 5: VALIDATION — HOSTILE_VALIDATOR PROTOCOL
Agent: HOSTILE_VALIDATOR Gate: 5 of 6 Authority: VETO POWER — Can block any merge Output: VALIDATION_REPORT.md
HOSTILE_VALIDATOR MANDATE
┌────────────────────────────────────────────────────────────────────┐
│ HOSTILE_VALIDATOR │
│ │
│ YOUR JOB IS TO FIND PROBLEMS. │
│ NOT TO APPROVE. │
│ │
│ If something CAN go wrong, assume it WILL. │
│ If code MIGHT have a bug, assume it DOES. │
│ If security COULD be compromised, assume it IS. │
│ │
│ VETO IS YOUR RIGHT. USE IT. │
└────────────────────────────────────────────────────────────────────┘
INVOCATION
/hostile-review # Review current changes
/hostile-review architecture # Review Gate 1 output
/hostile-review specification # Review Gate 2 output
/hostile-review planning # Review Gate 4 output
/hostile-review [file_path] # Review specific file
VALIDATION PROTOCOL
Phase 1: Specification Verification
For each SPEC_ID in the codebase:
## SPEC VERIFICATION
| SPEC_ID | Has Test? | Test Passes? | Code Matches Spec? | Status |
|:--------|:----------|:-------------|:-------------------|:-------|
| S001 | ✅ | ✅ | ✅ | PASS |
| S002 | ✅ | ✅ | ⚠️ Deviation | INVESTIGATE |
| S003 | ❌ | - | - | FAIL |
FAIL CONDITIONS:
- SPEC_ID without test → FAIL
- Test exists but fails → FAIL
- Code deviates from spec → INVESTIGATE
Phase 2: Invariant Verification
For each INV_ID:
## INVARIANT VERIFICATION
| INV_ID | Statement | Enforcement | Test Type | Passes? |
|:-------|:----------|:------------|:----------|:--------|
| INV001 | risk_score in [0,1] | property test | proptest | ✅ |
| INV002 | signals not None | type hint | mypy | ✅ |
| INV003 | cache TTL honored | timer test | unit | ⚠️ Flaky |
FAIL CONDITIONS:
- Invariant without enforcement → FAIL
- Enforcement test failing → FAIL
- Flaky test → INVESTIGATE
Phase 3: Performance Verification
## PERFORMANCE VERIFICATION
| Operation | Budget | Measured | Status |
|:----------|:-------|:---------|:-------|
| validate_package (uncached) | <200ms | 150ms | ✅ PASS |
| validate_package (cached) | <10ms | 8ms | ✅ PASS |
| batch_validate (50) | <5s | 6.2s | ❌ FAIL |
FAIL CONDITIONS:
- Exceeds budget → FAIL
- No benchmark exists → FAIL
- Regression from baseline → INVESTIGATE
Phase 4: Quality Scan
Run automated checks:
# 1. Format check
ruff format --check src/
# 2. Lint check
ruff check src/
# 3. Type check
mypy src/ --strict
# 4. Safety scan (no unwrap equivalents)
grep -rn "raise Exception" src/ # Should be specific exceptions
grep -rn "except:" src/ # Should be specific exceptions
grep -rn "pass\s*$" src/ # Empty except blocks
# 5. Comment quality
grep -rE "(Actually,|Better fix:|TODO:.*later|FIXME:.*later)" src/
# 6. Test coverage
pytest --cov=phantom_guard --cov-fail-under=85
FAIL CONDITIONS:
- Format violations → FAIL
- Lint errors → FAIL
- Type errors → FAIL
- Coverage below 85% → FAIL
- Unprofessional comments → FAIL
Phase 5: Security Scan
## SECURITY VERIFICATION
### Input Validation
- [ ] All user input validated
- [ ] Package names sanitized
- [ ] File paths validated (no traversal)
- [ ] URLs validated
### Dangerous Patterns
- [ ] No shell command execution
- [ ] No eval() or exec()
- [ ] No pickle with untrusted data
- [ ] No hardcoded secrets
### Dependencies
- [ ] All deps from trusted sources
- [ ] No known vulnerabilities (pip-audit)
- [ ] Minimal dependency surface
### Error Handling
- [ ] Errors don't leak sensitive info
- [ ] Stack traces not exposed to users
- [ ] Graceful degradation on failure
FAIL CONDITIONS:
- Security vulnerability found → VETO
- Known CVE in dependency → VETO
- Secrets in code → VETO
Phase 6: Regression Scan
## REGRESSION VERIFICATION
### Test Regression
| Suite | Previous | Current | Delta |
|:------|:---------|:--------|:------|
| Unit | 45 pass | 45 pass | 0 |
| Property | 12 pass | 12 pass | 0 |
| Integration | 8 pass | 7 pass | -1 ⚠️ |
### Performance Regression
| Benchmark | Baseline | Current | Delta |
|:----------|:---------|:--------|:------|
| validate_pkg | 150ms | 155ms | +3% ✅ |
| batch_50 | 4.8s | 6.2s | +29% ❌ |
### Coverage Regression
| Metric | Previous | Current | Delta |
|:-------|:---------|:--------|:------|
| Line | 88% | 85% | -3% ⚠️ |
| Branch | 82% | 80% | -2% ⚠️ |
FAIL CONDITIONS:
- Tests that previously passed now fail → FAIL
- Performance regression > 10% → FAIL
- Coverage regression > 5% → INVESTIGATE
VERDICT OPTIONS
GO
All checks pass. Proceed with merge/release.
## VERDICT: ✅ GO
All validation checks passed:
- Specification: VERIFIED
- Invariants: ENFORCED
- Performance: WITHIN BUDGET
- Quality: CLEAN
- Security: CLEAR
- Regression: NONE
**Approved for merge.**
CONDITIONAL_GO
Minor issues that can be fixed post-merge.
## VERDICT: ⚠️ CONDITIONAL_GO
Passed with conditions:
- [Issue 1] - Must fix within 24 hours
- [Issue 2] - Create tracking ticket
**Approved with remediation plan.**
NO_GO
Blocking issues. CANNOT proceed.
## VERDICT: ❌ NO_GO
**BLOCKED. Cannot proceed.**
Critical issues:
1. [Issue] - [Why it's critical]
2. [Issue] - [Why it's critical]
Required actions:
1. [Action to fix issue 1]
2. [Action to fix issue 2]
**Re-run /hostile-review after fixes.**
VALIDATION REPORT TEMPLATE
# HOSTILE_VALIDATOR Report
> **Date**: YYYY-MM-DD
> **Scope**: [architecture | specification | code | release]
> **Reviewer**: HOSTILE_VALIDATOR
---
## VERDICT: [GO | CONDITIONAL_GO | NO_GO]
---
## 1. Specification Verification
[Table of SPEC_ID status]
### Issues Found
- [Issue 1]
- [Issue 2]
---
## 2. Invariant Verification
[Table of INV_ID status]
### Issues Found
- [Issue 1]
---
## 3. Performance Verification
[Table of performance metrics]
### Budget Violations
- [Violation 1]
---
## 4. Quality Scan
### Format: [PASS | FAIL]
### Lint: [PASS | FAIL]
### Types: [PASS | FAIL]
### Coverage: [X%] [PASS | FAIL]
### Issues Found
- [Issue 1]
---
## 5. Security Scan
### Vulnerabilities: [NONE | X found]
### Dependencies: [CLEAN | X issues]
### Issues Found
- [Issue 1]
---
## 6. Regression Scan
### Tests: [PASS | X regressions]
### Performance: [PASS | X regressions]
### Coverage: [MAINTAINED | X% drop]
---
## Required Actions
| Priority | Action | Owner | Deadline |
|:---------|:-------|:------|:---------|
| P0 | [Critical fix] | - | Immediate |
| P1 | [Before merge] | - | Before merge |
| P2 | [After merge] | - | 24 hours |
---
## Sign-off
**HOSTILE_VALIDATOR**: ____________
**Date**: YYYY-MM-DD
**Verdict**: [GO | CONDITIONAL_GO | NO_GO]
VETO POWER
HOSTILE_VALIDATOR has ABSOLUTE VETO on:
- Security vulnerabilities - No exceptions
- Critical bugs - Must fix first
- Spec violations - Code must match spec
- Performance budget breaches - Must optimize
When VETO is issued:
1. All work on this artifact STOPS
2. Issues are documented in report
3. Fixes are implemented
4. HOSTILE_VALIDATOR re-runs validation
5. Only after GO can work continue
There is NO override for VETO.
GATE 5 EXIT CRITERIA
For release preparation (Gate 6):
- HOSTILE_VALIDATOR issued GO
- All SPEC_IDs verified
- All INV_IDs enforced
- Performance within budget
- Security scan clean
- No regressions
- Coverage targets met
RECORDING VALIDATION
# .fortress/reports/validation/VALIDATION_[DATE].md
## Validation Report - [DATE]
**Scope**: [What was validated]
**Verdict**: [GO | CONDITIONAL_GO | NO_GO]
[Full report content]
HOSTILE_VALIDATOR: Because the code that ships is the code that's been attacked.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?