jdsingh122918/.forge/skills/agent-review
.forge/skills/agent-review/SKILL.md
# Agent Review Before claiming phase completion, spawn an independent review agent to verify your implementation. This catches issues you may have missed. ## When to Trigger Review - After all implementation for the phase is complete - After all tests pass - Before emitting `<promise>DONE</promise>` ## How to Spawn Review Agent Use the Task tool with these parameters: - **subagent_type**: `"general-purpose"` - **description**: `"Review phase N implementation"` (replace N with phase number)
tools
Updated Apr 6, 2026
$ install --global
skillsauthnpx skillsauth add jdsingh122918/forge .forge/skills/agent-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 6, 2026, 2:15 AM45.8s1 file scanned
SKILL.md
Agent Review
Before claiming phase completion, spawn an independent review agent to verify your implementation. This catches issues you may have missed.
When to Trigger Review
- After all implementation for the phase is complete
- After all tests pass
- Before emitting
<promise>DONE</promise>
How to Spawn Review Agent
Use the Task tool with these parameters:
- subagent_type:
"general-purpose" - description:
"Review phase N implementation"(replace N with phase number) - prompt: Include the phase context and checklist below
Example prompt to pass to the review agent:
Review the code changes for Phase {N} - {phase name}.
Run this command to see what changed:
git diff HEAD~{iterations} --stat
git diff HEAD~{iterations}
Check for:
1. DRY violations - duplicated code that should be extracted
2. Security issues - injection risks, hardcoded secrets, missing validation
3. Test coverage - are edge cases covered, are tests meaningful
4. Code clarity - naming, structure, comments where needed
Report issues as a numbered list with file:line references.
If no issues found, respond with: REVIEW PASSED
Replace {N} with the phase number, {phase name} with the phase name, and
{iterations} with the number of iterations completed in this phase.
Handling Review Results
- REVIEW PASSED: Proceed to emit
<promise>DONE</promise> - Issues found: Address each issue, re-run tests, then request another review
- Max 2 review cycles: If issues persist after 2 reviews, emit
<blocker>review-failed</blocker>and describe the unresolved issues
Review Scope
The reviewer checks only the current phase's changes, not the entire codebase.
Use git diff HEAD~N where N is the iteration count to see phase changes.
Related Skills
jdsingh122918/.forge/skills/testing-strategy
development
VerifiedTrustedCommunity
# Testing Strategy Apply this testing strategy for all new code: ## Test Levels 1. **Unit Tests** - Test individual functions in isolation - Located in `mod tests` at the bottom of each file - Mock external dependencies - Fast, deterministic, no I/O 2. **Integration Tests** - Test modules working together - Located in `tests/` directory - Use real dependencies where practical - May involve filesystem, database, or network 3. **End-to-End Tests** - Test complete user workflo
SKILL.mdUpdated Apr 6, 2026
jdsingh122918/.forge/skills/tdd-workflow
development
VerifiedTrustedCommunity
# TDD Workflow Apply Test-Driven Development when implementing new functionality. Use your judgment to determine when TDD is appropriate — it's most valuable for business logic, algorithms, and complex state management. ## When to Use TDD - New functions with defined inputs/outputs - Bug fixes (write failing test first, then fix) - Refactoring existing code (ensure tests exist first) - API endpoints and data transformations ## When TDD May Not Apply - Configuration files, constants, types/i
SKILL.mdUpdated Apr 6, 2026
jdsingh122918/.forge/skills/secure-coding
tools
VerifiedTrustedCommunity
# Secure Coding Follow these secure coding practices for all code in this project. ## Input Validation - Validate all external input (user input, API responses, file contents) - Use allowlists over denylists when validating - Sanitize data before use in SQL, shell commands, or HTML output - Validate early, at system boundaries (CLI args, file reads, network responses) ## Rust-Specific Security - Minimize `unsafe` blocks; document safety invariants when used - Use established crypto librarie
SKILL.mdUpdated Apr 6, 2026
jdsingh122918/.forge/skills/rust-conventions
tools
VerifiedTrustedCommunity
# Rust Conventions Follow these Rust conventions for all code in this project: ## Code Style - Use `rustfmt` defaults for formatting - Run `cargo clippy` and address all warnings before committing - Prefer `?` operator for error propagation over `.unwrap()` in library code - Use `.expect("meaningful message")` only when failure indicates a bug ## Error Handling - Use `anyhow::Result` for application code and CLI - Use `thiserror` for library errors that callers need to match on - Provide cont
SKILL.mdUpdated Apr 6, 2026