Skip to content

Commit 10de48f

Browse files
Copilot0xrinegade
Copilot
and
0xrinegade
committed
Add Copilot coding agent configuration files
Co-authored-by: 0xrinegade <[email protected]>
1 parent e2cdad0 commit 10de48f

File tree

2 files changed

+298
-0
lines changed

2 files changed

+298
-0
lines changed

‎.github/workflows/copilot-setup-steps.yml‎

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
1+
name: Copilot Setup Steps
2+
3+
# This workflow defines custom setup steps for GitHub Copilot coding agent
4+
# It ensures the agent has the necessary environment to build, test, and lint code
5+
6+
on:
7+
workflow_dispatch:
8+
9+
jobs:
10+
setup:
11+
runs-on: ubuntu-latest
12+
13+
steps:
14+
- name: Checkout repository
15+
uses: actions/checkout@v5
16+
17+
- name: Install system dependencies
18+
run: |
19+
sudo apt-get update
20+
sudo apt-get install -y libssl-dev pkg-config build-essential
21+
22+
- name: Setup Rust toolchain
23+
uses: actions-rs/toolchain@v1
24+
with:
25+
toolchain: stable
26+
override: true
27+
components: rustfmt, clippy
28+
29+
- name: Cache cargo registry
30+
uses: actions/cache@v4
31+
with:
32+
path: ~/.cargo/registry
33+
key: ${{ runner.os }}-cargo-registry-${{ hashFiles('**/Cargo.lock') }}
34+
restore-keys: |
35+
${{ runner.os }}-cargo-registry-
36+
37+
- name: Cache cargo index
38+
uses: actions/cache@v4
39+
with:
40+
path: ~/.cargo/git
41+
key: ${{ runner.os }}-cargo-git-${{ hashFiles('**/Cargo.lock') }}
42+
restore-keys: |
43+
${{ runner.os }}-cargo-git-
44+
45+
- name: Cache cargo build
46+
uses: actions/cache@v4
47+
with:
48+
path: target
49+
key: ${{ runner.os }}-cargo-build-${{ hashFiles('**/Cargo.lock') }}
50+
restore-keys: |
51+
${{ runner.os }}-cargo-build-
52+
53+
- name: Build the project
54+
run: cargo build --verbose
55+
56+
- name: Run tests
57+
run: cargo test --verbose
58+
59+
- name: Check code formatting
60+
run: cargo fmt -- --check
61+
62+
- name: Run clippy
63+
run: cargo clippy -- -D warnings
64+
65+
- name: Verify project structure
66+
run: |
67+
echo "✓ Project setup complete"
68+
echo "✓ Dependencies installed"
69+
echo "✓ Build successful"
70+
echo "✓ Tests passed"
71+
echo "✓ Code formatting verified"
72+
echo "✓ Clippy checks passed"

‎copilot-instructions.md‎

Lines changed: 226 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,226 @@
1+
# GitHub Copilot Coding Agent Instructions for svmai-cli
2+
3+
## Project Overview
4+
5+
`svmai` is a Rust-based command-line interface (CLI) tool for managing Solana wallets. It provides secure wallet management, multi-threaded wallet search, balance tracking, and batch operations with a text-based user interface (TUI).
6+
7+
## Language and Framework
8+
9+
- **Primary Language**: Rust (Edition 2021)
10+
- **Build System**: Cargo
11+
- **Key Frameworks**:
12+
- `ratatui` with `crossterm` for TUI
13+
- `solana-sdk` for Solana blockchain integration
14+
- `keyring` for secure credential storage
15+
16+
## Coding Standards
17+
18+
### Code Style
19+
- Follow Rust's official style guide and idiomatic Rust patterns
20+
- Use `cargo fmt` to automatically format code before committing
21+
- Run `cargo clippy -- -D warnings` to catch common mistakes and warnings
22+
- All clippy warnings must be addressed before PR approval
23+
- Write clear, descriptive comments for complex logic
24+
- Use rustdoc comments (`///`) for all public API functions and structs
25+
26+
### Naming Conventions
27+
- Use `snake_case` for functions, variables, and module names
28+
- Use `PascalCase` for types, traits, and enum variants
29+
- Use `SCREAMING_SNAKE_CASE` for constants
30+
- Choose descriptive names that clearly indicate purpose
31+
32+
### Error Handling
33+
- Use `Result<T, E>` for operations that can fail
34+
- Define custom error types using `thiserror` when appropriate
35+
- Provide meaningful error messages that help users understand what went wrong
36+
- Handle errors gracefully in TUI components to prevent crashes
37+
38+
### Security
39+
- Never log or display private keys in plain text
40+
- Use secure storage mechanisms (system keychain) for sensitive data
41+
- Validate all user inputs before processing
42+
- Follow cryptographic best practices when handling encryption
43+
- Use `zeroize` or similar for sensitive data in memory when appropriate
44+
45+
## Architecture
46+
47+
The project follows a modular architecture with clear separation of concerns:
48+
49+
- **`main.rs`**: CLI entry point and argument parsing
50+
- **`file_searcher.rs`**: Multi-threaded wallet file discovery
51+
- **`key_validator.rs`**: Solana private key validation
52+
- **`secure_storage.rs`**: Encrypted storage using system keychain
53+
- **`wallet_manager.rs`**: High-level wallet management operations
54+
- **`transaction_handler.rs`**: Transaction creation and batch operations
55+
- **`vanity_wallet.rs`**: Vanity address generation
56+
- **`tui.rs`**: Text-based user interface using ratatui
57+
- **`config.rs`**: Configuration management
58+
- **`logging.rs`**: Logging utilities
59+
60+
### Module Guidelines
61+
- Keep modules focused on a single responsibility
62+
- Use public interfaces (`pub`) only for necessary exports
63+
- Document module-level behavior with module comments
64+
- Maintain clear boundaries between modules
65+
66+
## Dependencies
67+
68+
### Adding New Dependencies
69+
- Only add dependencies that are actively maintained and widely used
70+
- Prefer pure Rust implementations when available
71+
- Check for security advisories before adding new crates
72+
- Document why a dependency is needed in commit messages
73+
- Update `Cargo.toml` with appropriate version constraints
74+
75+
### Version Management
76+
- Use semantic versioning for dependencies
77+
- Prefer exact versions for cryptographic libraries
78+
- Use `~` or `^` operators for other dependencies as appropriate
79+
80+
## Testing
81+
82+
### Test Requirements
83+
- Write unit tests for all new functionality
84+
- Place tests in a `tests` module within each source file
85+
- Use `#[cfg(test)]` to conditionally compile tests
86+
- Aim for high code coverage, especially for critical paths
87+
- Test edge cases and error conditions
88+
89+
### Test Organization
90+
```rust
91+
#[cfg(test)]
92+
mod tests {
93+
use super::*;
94+
95+
#[test]
96+
fn test_descriptive_name() {
97+
// Test implementation
98+
}
99+
}
100+
```
101+
102+
### Running Tests
103+
- Run `cargo test` before submitting PRs
104+
- Run `cargo test --verbose` for detailed output
105+
- Ensure all tests pass; do not disable or remove existing tests
106+
- Use `tempfile` crate for temporary file operations in tests
107+
108+
### Integration Testing
109+
- For TUI changes, include manual testing steps in PR description
110+
- Test on multiple platforms when possible (Linux, macOS, Windows)
111+
- Verify keychain integration works correctly on target platforms
112+
113+
## Building and Linting
114+
115+
### Build Commands
116+
```bash
117+
# Development build
118+
cargo build
119+
120+
# Release build
121+
cargo build --release
122+
123+
# Clean build artifacts
124+
cargo clean
125+
```
126+
127+
### Pre-commit Checks
128+
Always run these commands before committing:
129+
```bash
130+
# Format code
131+
cargo fmt
132+
133+
# Check for common issues
134+
cargo clippy -- -D warnings
135+
136+
# Run tests
137+
cargo test
138+
```
139+
140+
## Documentation
141+
142+
### Code Documentation
143+
- Use rustdoc comments (`///`) for public APIs
144+
- Include examples in documentation when helpful
145+
- Document panics, errors, and safety requirements
146+
- Keep documentation up-to-date with code changes
147+
148+
### External Documentation
149+
- Update README.md for user-facing changes
150+
- Update architecture.md for architectural changes
151+
- Update CONTRIBUTING.md for process changes
152+
- Maintain CHANGELOG.md for version history
153+
154+
## Performance Considerations
155+
156+
- Use `rayon` for parallel processing where appropriate
157+
- Avoid unnecessary allocations in hot paths
158+
- Profile code before optimizing (don't prematurely optimize)
159+
- Consider memory usage for operations on large wallet collections
160+
161+
## Platform Compatibility
162+
163+
- Support Linux, macOS, and Windows
164+
- Test keychain integration on all target platforms
165+
- Handle platform-specific paths using the `dirs` crate
166+
- Document any platform-specific limitations
167+
168+
## Git Workflow
169+
170+
### Commit Messages
171+
- Use clear, descriptive commit messages
172+
- Start with a verb in present tense (e.g., "Add", "Fix", "Update")
173+
- Reference issue numbers when applicable
174+
- Keep commits focused and atomic
175+
176+
### Pull Requests
177+
- Include a clear description of changes
178+
- Link to related issues
179+
- Include test results and manual testing steps
180+
- Ensure CI passes before requesting review
181+
- Address review feedback promptly
182+
183+
## Common Patterns
184+
185+
### Wallet Operations
186+
- Always validate wallet data before operations
187+
- Use secure storage for private keys
188+
- Provide progress feedback for long-running operations
189+
- Allow cancellation of long-running operations
190+
191+
### TUI Development
192+
- Use the `App` struct to manage application state
193+
- Handle keyboard events in the main event loop
194+
- Update UI state before rendering
195+
- Provide visual feedback for all user actions
196+
- Handle terminal resize events gracefully
197+
198+
### Async Operations
199+
- Use threads for CPU-bound operations (e.g., vanity generation)
200+
- Provide progress updates for user feedback
201+
- Implement cancellation for long-running tasks
202+
- Clean up resources properly on completion or cancellation
203+
204+
## Solana Integration
205+
206+
- Use `solana-sdk` version 3.x API patterns
207+
- Validate keypairs before use
208+
- Handle network errors gracefully
209+
- Cache RPC responses when appropriate
210+
- Respect rate limits for RPC endpoints
211+
212+
## Prohibited Actions
213+
214+
- Do not commit private keys or sensitive data
215+
- Do not disable security features
216+
- Do not remove or skip existing tests without justification
217+
- Do not introduce dependencies with known vulnerabilities
218+
- Do not bypass error handling
219+
- Do not use `unwrap()` or `expect()` in production code paths (prefer `?` operator and proper error handling)
220+
221+
## Questions or Issues
222+
223+
- Review existing issues in the GitHub repository
224+
- Check documentation in the `docs/` directory and markdown files
225+
- Refer to the architecture.md file for design decisions
226+
- Consult CONTRIBUTING.md for contribution guidelines

0 commit comments

Comments
 (0)