mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-04-26 01:01:40 +00:00
f172f7d4aa
- Introduced new skills tools: `skills_categories`, `skills_list`, and `skill_view` in `model_tools.py`, allowing for better organization and access to skill-related functionalities. - Updated `toolsets.py` to include a new `skills` toolset, providing a dedicated space for skill tools. - Enhanced `batch_runner.py` to recognize and validate skills tools during batch processing. - Added comprehensive tool definitions for skills tools, ensuring compatibility with OpenAI's expected format. - Created new shell script `test_skills_kimi.sh` for testing skills tool functionality with Kimi K2.5. - Added example skill files demonstrating the structure and usage of skills within the Hermes-Agent framework, including `SKILL.md` for example and audiocraft skills. - Improved documentation for skills tools and their integration into the existing tool framework, ensuring clarity for future development and usage.
81 lines
2.2 KiB
Markdown
81 lines
2.2 KiB
Markdown
---
|
|
name: code-review
|
|
description: Guidelines for performing thorough code reviews with security and quality focus
|
|
---
|
|
|
|
# Code Review Skill
|
|
|
|
Use this skill when reviewing code changes, pull requests, or auditing existing code.
|
|
|
|
## Review Checklist
|
|
|
|
### 1. Security First
|
|
- [ ] No hardcoded secrets, API keys, or credentials
|
|
- [ ] Input validation on all user-provided data
|
|
- [ ] SQL queries use parameterized statements (no string concatenation)
|
|
- [ ] File operations validate paths (no path traversal)
|
|
- [ ] Authentication/authorization checks present where needed
|
|
|
|
### 2. Error Handling
|
|
- [ ] All external calls (API, DB, file) have try/catch
|
|
- [ ] Errors are logged with context (but no sensitive data)
|
|
- [ ] User-facing errors are helpful but don't leak internals
|
|
- [ ] Resources are cleaned up in finally blocks or context managers
|
|
|
|
### 3. Code Quality
|
|
- [ ] Functions do one thing and are reasonably sized (<50 lines ideal)
|
|
- [ ] Variable names are descriptive (no single letters except loops)
|
|
- [ ] No commented-out code left behind
|
|
- [ ] Complex logic has explanatory comments
|
|
- [ ] No duplicate code (DRY principle)
|
|
|
|
### 4. Testing Considerations
|
|
- [ ] Edge cases handled (empty inputs, nulls, boundaries)
|
|
- [ ] Happy path and error paths both work
|
|
- [ ] New code has corresponding tests (if test suite exists)
|
|
|
|
## Review Response Format
|
|
|
|
When providing review feedback, structure it as:
|
|
|
|
```
|
|
## Summary
|
|
[1-2 sentence overall assessment]
|
|
|
|
## Critical Issues (Must Fix)
|
|
- Issue 1: [description + suggested fix]
|
|
- Issue 2: ...
|
|
|
|
## Suggestions (Nice to Have)
|
|
- Suggestion 1: [description]
|
|
|
|
## Questions
|
|
- [Any clarifying questions about intent]
|
|
```
|
|
|
|
## Common Patterns to Flag
|
|
|
|
### Python
|
|
```python
|
|
# Bad: SQL injection risk
|
|
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
|
|
|
|
# Good: Parameterized query
|
|
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
|
|
```
|
|
|
|
### JavaScript
|
|
```javascript
|
|
// Bad: XSS risk
|
|
element.innerHTML = userInput;
|
|
|
|
// Good: Safe text content
|
|
element.textContent = userInput;
|
|
```
|
|
|
|
## Tone Guidelines
|
|
|
|
- Be constructive, not critical
|
|
- Explain *why* something is an issue, not just *what*
|
|
- Offer solutions, not just problems
|
|
- Acknowledge good patterns you see
|