
# 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)
# Context7 Integration Query Context7 for up-to-date library documentation before implementing code that uses external dependencies. This ensures you use current APIs and best practices. ## When to Query Context7 - Before first use of an unfamiliar or rapidly-evolving library - When implementing patterns you haven't used recently - When errors suggest API changes or deprecations - When the spec mentions specific library features ## When NOT to Query - Standard library features (Rust `std`,
# DRY Principles Eliminate duplication to improve maintainability. Every piece of knowledge should have a single, authoritative representation in the codebase. ## Before Writing Code - Search for existing functions/utilities that solve the problem - Check if similar patterns exist elsewhere that should be unified - Consider if this logic belongs in a shared module ## Duplication Red Flags - Copy-pasting code blocks (extract to function) - Similar functions with minor variations (parameteriz
# 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
# CLI Design Follow these conventions for CLI commands and user interaction: ## Command Structure - Use clap with derive macros for argument parsing - Organize commands as subcommands where logical - Provide both short and long flags for common options - Include helpful examples in help text ## User Feedback - Print progress information during long operations - Use clear, action-oriented language ("Creating...", "Loading...") - Show success/failure status clearly - Provide next steps on compl
# 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
# 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
# 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