feat: add opencode agents and skills for development workflows
New agents: - architect: system design, module interactions, data flow - debugger: crash/memory/thread debugging with ASan, TSan, valgrind, gdb - security-auditor: TLS, input validation, buffer safety, crypto audit - refactorer: DRY, separation of concerns, API simplification - integrator: integration tests, CI/CD pipeline, end-to-end verification - code-explainer: architecture walkthrough, code explanation New skills: - debug-workflow: structured debugging workflow - refactor: code restructuring with test verification - security-audit: full security review with checklist - benchmark: performance benchmarking with multi-run medians - release: version bump, tests, tagging Improved existing: - c-reviewer: added security checklist - cmake-expert: added ASan/TSan/UBSan configs, ccache, cross-compilation - perf-analyst: added perf/valgrind/gprof commands - test-writer: added fuzzing harnesses, integration test patterns - pr-build: added sanitizer build variants - pr-review: added security review, performance impact assessment
This commit is contained in:
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: refactor
|
||||
description: Refactors FastSync code for structural improvements — DRY, separation of concerns, API simplification. Use when the user says "refactor X", "clean up code", "improve structure", or wants to reduce duplication.
|
||||
---
|
||||
|
||||
# Refactor Skill
|
||||
|
||||
Read-only analysis + code edits for structural improvements. This skill CAN edit files but MUST verify tests pass.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Identify Refactoring Target
|
||||
|
||||
Ask or determine:
|
||||
- What code needs refactoring?
|
||||
- What's the problem? (duplication, complexity, wrong abstraction, naming)
|
||||
- What's the scope? (single function, module, cross-module)
|
||||
|
||||
### Step 2: Read and Understand
|
||||
|
||||
Read the relevant source files completely. Understand:
|
||||
- What the code does
|
||||
- How it fits in the larger system
|
||||
- What depends on it
|
||||
- What it depends on
|
||||
|
||||
### Step 3: Verify Baseline
|
||||
|
||||
Before any changes, confirm tests pass:
|
||||
```bash
|
||||
cmake -B build -S . && cmake --build build -j$(nproc)
|
||||
./build/tests
|
||||
```
|
||||
|
||||
### Step 4: Plan the Refactor
|
||||
|
||||
Document the plan:
|
||||
1. What changes will be made
|
||||
2. What behavior is preserved
|
||||
3. What risks exist
|
||||
4. How to verify correctness
|
||||
|
||||
### Step 5: Implement
|
||||
|
||||
Make the changes, one logical step at a time. Follow existing code conventions:
|
||||
- Header guards: `#ifndef FILENAME_H`
|
||||
- Naming: `snake_case` with module prefix
|
||||
- `static` for file-local functions
|
||||
- Pointer style: `Type *name`
|
||||
- Error handling: return `false`/`NULL` on failure
|
||||
|
||||
### Step 6: Build and Test
|
||||
|
||||
```bash
|
||||
cmake -B build -S . && cmake --build build -j$(nproc)
|
||||
./build/tests
|
||||
```
|
||||
|
||||
ALL tests must pass. If a test fails, investigate and fix.
|
||||
|
||||
### Step 7: Report
|
||||
|
||||
Print a summary:
|
||||
```
|
||||
=== REFACTOR SUMMARY ===
|
||||
Target: <what was refactored>
|
||||
Changes:
|
||||
- <list of changes>
|
||||
Tests: <passed/total>
|
||||
Behavior preserved: yes
|
||||
```
|
||||
|
||||
## Rules
|
||||
- DO edit source files
|
||||
- DO run tests after changes
|
||||
- DO follow existing code conventions
|
||||
- DON'T change observable behavior
|
||||
- DON'T fix bugs while refactoring (separate concern)
|
||||
- DON'T add new features during refactoring
|
||||
- DON'T rewrite from scratch — incremental changes
|
||||
- ALWAYS verify tests pass before AND after
|
||||
Reference in New Issue
Block a user