ВяткинАртём
e5dc08987d
- 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.
69 lines
1.9 KiB
Markdown
69 lines
1.9 KiB
Markdown
---
|
|
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. |