ВяткинАртём
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.
85 lines
2.4 KiB
Markdown
85 lines
2.4 KiB
Markdown
---
|
|
name: branch-review-apply
|
|
description: "Apply user-approved branch review improvements and validate them with the effective project configuration. Use when: user approved review fixes, apply selected code review changes, implement proposed improvements, применить улучшения из ревью, внести согласованные правки."
|
|
argument-hint: "Approved items to apply (e.g. all, critical, 1 3 5)"
|
|
---
|
|
|
|
# Branch Review: Apply Improvements
|
|
|
|
This skill applies only the improvements accepted by the user and validates them against the project's effective configuration.
|
|
|
|
## Rules
|
|
|
|
- Re-read `pyproject.toml` before validation if it exists
|
|
- Touch only files needed for approved items
|
|
- Preserve unrelated user changes
|
|
- Prefer the smallest safe diff
|
|
- Do not introduce changes that contradict configured versions or modes
|
|
- Include text and spelling fixes only when they were approved or bundled with an approved item
|
|
|
|
## Procedure
|
|
|
|
### Step 1 — Resolve Accepted Scope
|
|
|
|
Interpret the user approval exactly:
|
|
- `apply all`
|
|
- `apply critical`
|
|
- `apply critical important`
|
|
- specific item numbers
|
|
|
|
If the request is ambiguous, ask for clarification before editing.
|
|
|
|
### Step 2 — Refresh Context
|
|
|
|
Before editing:
|
|
- re-read the affected files
|
|
- re-read `pyproject.toml` if present
|
|
- confirm there are no conflicting local changes in the same lines
|
|
|
|
### Step 3 — Apply Minimal Fixes
|
|
|
|
Implement only approved items.
|
|
|
|
Typical allowed changes:
|
|
- bug fixes
|
|
- test fixes or additions tied to the reviewed diff
|
|
- type and lint compliance fixes aligned with project config
|
|
- performance improvements with low behavioral risk
|
|
- spelling and wording corrections
|
|
|
|
Avoid broad refactors unless the approved item explicitly requires them.
|
|
|
|
### Step 4 — Validate
|
|
|
|
Use the most relevant checks for the changed scope, guided by `pyproject.toml`.
|
|
|
|
Prefer targeted commands such as:
|
|
|
|
```bash
|
|
ruff check <target>
|
|
mypy <target>
|
|
pytest <target> -q
|
|
```
|
|
|
|
If tool settings are configured in `pyproject.toml`, rely on them instead of inventing flags.
|
|
|
|
If the repo has no `pyproject.toml`, run only conservative validation that clearly matches the affected code.
|
|
|
|
### Step 5 — Report
|
|
|
|
Return:
|
|
|
|
```md
|
|
## Applied Improvements
|
|
|
|
Applied:
|
|
- item N: summary
|
|
|
|
Validation:
|
|
- command: result
|
|
|
|
Remaining:
|
|
- unapplied or blocked items
|
|
```
|
|
|
|
If validation cannot run, explain exactly what is missing: tool, environment, dependency, or test setup. |