feat: Add new agents and skills for Docker, TestLink, and OpenWrt
- Introduced "Docker Build & Test Engineer" agent for building and testing Docker images. - Added "TestLink Autotest Engineer" agent for generating and verifying autotests from TestLink cases. - Created "Branch Review Engineer" agent for reviewing branch diffs and proposing improvements. - Developed "OpenWrt VPN & Network Engineer" agent for designing and implementing OpenWrt networking with VPN. - Established a structured directory for agents, skills, prompts, instructions, and hooks under `.github/`. - Implemented detailed skills for branch review processes, including reading code, analyzing improvements, and applying changes. - Added skills for OpenWrt network discovery, VPN routing, and hardening. - Created README files for better documentation and navigation of the repository structure.
This commit is contained in:
@@ -0,0 +1,69 @@
|
||||
---
|
||||
name: branch-review-propose
|
||||
description: "Present branch review findings to the user in an actionable format and ask which ones to apply. Use when: propose review improvements, summarize findings for user approval, предложить улучшения по ревью, показать найденные проблемы, согласовать правки."
|
||||
argument-hint: "Analyzed findings to present"
|
||||
---
|
||||
|
||||
# Branch Review: Propose Improvements
|
||||
|
||||
This skill converts findings into a user-facing review that is easy to approve selectively.
|
||||
|
||||
## Rules
|
||||
|
||||
- Proposals must already respect `pyproject.toml` constraints collected earlier
|
||||
- Lead with the highest-impact issues
|
||||
- Keep the language concrete and implementation-oriented
|
||||
- Include optimization, bug fixes, maintainability, and spelling improvements when relevant
|
||||
- Never imply that changes were already applied
|
||||
|
||||
## Procedure
|
||||
|
||||
### Step 1 — Remove Low-Signal Noise
|
||||
|
||||
Merge duplicates and drop comments that are purely subjective unless they clearly improve the changed code.
|
||||
|
||||
### Step 2 — Build the Proposal List
|
||||
|
||||
Number all proposed items across sections so the user can approve them selectively.
|
||||
|
||||
For each item include:
|
||||
- short title
|
||||
- severity
|
||||
- affected scope
|
||||
- why it matters
|
||||
- what will change if applied
|
||||
|
||||
### Step 3 — Add Clear Approval Options
|
||||
|
||||
Always end with concrete choices:
|
||||
- `apply all`
|
||||
- `apply critical`
|
||||
- `apply critical important`
|
||||
- `apply 1 3 5`
|
||||
- `skip`
|
||||
|
||||
## Output Template
|
||||
|
||||
```md
|
||||
## Branch Review
|
||||
|
||||
Base branch: <branch>
|
||||
Changed files: <N>
|
||||
pyproject.toml: found/missing
|
||||
|
||||
### Critical
|
||||
1. <title> — <why it matters>
|
||||
|
||||
### Important
|
||||
2. <title> — <why it matters>
|
||||
|
||||
### Optional
|
||||
3. <title> — <why it matters>
|
||||
|
||||
### Text and Spelling
|
||||
4. <title> — <why it matters>
|
||||
|
||||
Reply with: apply all, apply critical, apply critical important, apply 1 3 5, or skip.
|
||||
```
|
||||
|
||||
If there are no findings, say so explicitly and mention any residual risk, such as missing tests or inability to validate runtime behavior.
|
||||
Reference in New Issue
Block a user