TapTap/FastSync

Fork 0

Files

T

TapTap 8141158a3d

CI / build-and-test (push) Successful in 27s

Details

CI / build-and-test (pull_request) Successful in 26s

Details

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

2026-07-19 14:50:02 +02:00

2.0 KiB

Raw Permalink Blame History

name, description

name	description
refactor	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:

cmake -B build -S . && cmake --build build -j$(nproc)
./build/tests

Step 4: Plan the Refactor

Document the plan:

What changes will be made
What behavior is preserved
What risks exist
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

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

2.0 KiB Raw Permalink Blame History