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,8 @@
|
||||
# Skills
|
||||
|
||||
This directory is the canonical location for skills.
|
||||
|
||||
- Skill path: `.github/skills/<skill-name>/SKILL.md`
|
||||
- Optional resources: `.github/skills/<skill-name>/references/`, `assets/`, `scripts/`
|
||||
|
||||
Keep one source of truth per skill in this directory.
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
name: branch-review-analyze
|
||||
description: "Analyze the current branch for bugs, optimization opportunities, maintainability issues, and text problems after reading the diff and pyproject.toml. Use when: analyze branch review findings, think through improvements, classify code review issues, анализ ревью ветки, найти улучшения, подумать как улучшить код."
|
||||
argument-hint: "Review packet or target area to analyze"
|
||||
---
|
||||
|
||||
# Branch Review: Analyze Improvements
|
||||
|
||||
This skill turns raw branch context into defensible review findings.
|
||||
|
||||
## Analysis Rules
|
||||
|
||||
- Use `pyproject.toml` constraints as the default source of truth for Python version, linting, typing, formatting, and test behavior
|
||||
- Prefer correctness over style-only comments
|
||||
- Do not suggest changes that conflict with configured versions, strictness, or ignored rules
|
||||
- Review both changed lines and immediate behavioral context
|
||||
- Include spelling and wording issues when they affect docs, comments, user-facing text, tests, or developer clarity
|
||||
|
||||
## What to Look For
|
||||
|
||||
### Critical
|
||||
|
||||
- bugs, broken logic, wrong conditions, missing edge cases
|
||||
- unsafe refactors and regressions introduced by the branch
|
||||
- typing or API misuse that violates configured tooling or likely runtime behavior
|
||||
- tests that no longer validate the actual behavior
|
||||
|
||||
### Important
|
||||
|
||||
- performance issues in hot paths
|
||||
- duplicated logic introduced by the branch
|
||||
- brittle or incomplete tests
|
||||
- error handling gaps
|
||||
- config mismatches against `pyproject.toml`
|
||||
- maintainability problems that make the changed code harder to evolve
|
||||
|
||||
### Optional
|
||||
|
||||
- cleanup opportunities with low risk
|
||||
- clearer naming
|
||||
- smaller structure improvements
|
||||
- modern idioms allowed by the configured Python version
|
||||
|
||||
### Text and Spelling
|
||||
|
||||
- typos in comments, docs, tests, log messages, exceptions, CLI output, and UI strings
|
||||
- misleading wording or terminology inconsistencies
|
||||
|
||||
## Procedure
|
||||
|
||||
### Step 1 — Reconcile Diff with Config
|
||||
|
||||
For each changed Python-related file, compare the implementation against:
|
||||
- effective Python version
|
||||
- configured linter rules and ignores
|
||||
- type-checking modes
|
||||
- test config and markers
|
||||
|
||||
### Step 2 — Find Root Causes
|
||||
|
||||
Avoid surface comments. For each issue, identify:
|
||||
- what changed
|
||||
- why it is risky or suboptimal
|
||||
- what the smallest correct improvement is
|
||||
|
||||
### Step 3 — Classify Findings
|
||||
|
||||
Produce findings in four groups:
|
||||
- `Critical`
|
||||
- `Important`
|
||||
- `Optional`
|
||||
- `Text and Spelling`
|
||||
|
||||
Each finding should contain:
|
||||
- title
|
||||
- affected file or scope
|
||||
- reasoning
|
||||
- concrete recommended change
|
||||
- whether it is safe to auto-apply
|
||||
|
||||
### Step 4 — Note Validation Strategy
|
||||
|
||||
For every auto-applicable change, specify how it should be validated:
|
||||
- targeted tests
|
||||
- linter or type-check command
|
||||
- smoke import or command run
|
||||
- no validation available
|
||||
|
||||
## Output Template
|
||||
|
||||
```md
|
||||
## Review Findings
|
||||
|
||||
### Critical
|
||||
1. <title>
|
||||
- scope: ...
|
||||
- why: ...
|
||||
- change: ...
|
||||
- auto-apply: yes/no
|
||||
- validate: ...
|
||||
|
||||
### Important
|
||||
...
|
||||
|
||||
### Optional
|
||||
...
|
||||
|
||||
### Text and Spelling
|
||||
...
|
||||
```
|
||||
|
||||
Do not edit files in this skill.
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
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.
|
||||
@@ -0,0 +1,133 @@
|
||||
---
|
||||
name: branch-review-check-testlink
|
||||
description: "Open a TestLink test case via MCP and verify that the changed autotest in the branch covers all required steps and expected results. Use when: review autotest against TestLink, compare test implementation with TestLink case, verify coverage of written test, проверить автотест по TestLink, сверить тест с тест-кейсом, проверить что автотест покрывает шаги тест-кейса."
|
||||
argument-hint: "TestLink test case ID or changed test file/scope"
|
||||
---
|
||||
|
||||
# Branch Review: Check TestLink Coverage
|
||||
|
||||
This skill verifies that a written autotest actually checks everything required by the authoritative TestLink test case.
|
||||
|
||||
## When to Use
|
||||
|
||||
- The branch adds or changes autotests tied to a TestLink case
|
||||
- The user explicitly asks to compare a test file with a TestLink case
|
||||
- The diff contains a recognizable TestLink reference such as `KMD-123`, `PRJ-42`, or a comment, marker, title, docstring, or test name that maps to a test case
|
||||
|
||||
## Core Rule
|
||||
|
||||
Do not assume that a test is complete just because it exists.
|
||||
|
||||
You must fetch the TestLink case via MCP, read the written autotest, and compare:
|
||||
- preconditions
|
||||
- scenario steps
|
||||
- expected results
|
||||
- negative and branching behavior when the TestLink case requires it
|
||||
|
||||
## Procedure
|
||||
|
||||
### Step 1 — Resolve the TestLink Case ID
|
||||
|
||||
Find the most reliable case identifier in this order:
|
||||
1. explicit user-provided case ID
|
||||
2. exact TestLink ID found in changed test code, comments, docstrings, titles, markers, fixture names, or nearby docs
|
||||
3. exact TestLink ID found in commit or branch-related text already provided in context
|
||||
|
||||
Accepted formats:
|
||||
- numeric internal ID, for example `1831`
|
||||
- external ID, for example `KMD-1831`
|
||||
|
||||
If there is no reliable ID, stop this skill and report:
|
||||
- no TestLink case could be resolved from the branch
|
||||
- what evidence was checked
|
||||
|
||||
### Step 2 — Fetch the Authoritative Test Case
|
||||
|
||||
Call TestLink MCP to load the case.
|
||||
|
||||
Use:
|
||||
- `external_id` for prefixed identifiers such as `KMD-1831`
|
||||
- `test_case_id` for plain numeric identifiers
|
||||
|
||||
Extract at minimum:
|
||||
- `id` and `external_id`
|
||||
- `name`
|
||||
- `summary`
|
||||
- `preconditions`
|
||||
- `steps[].step_number`
|
||||
- `steps[].actions`
|
||||
- `steps[].expected_results`
|
||||
|
||||
If the case is not found, report it and stop this skill.
|
||||
|
||||
### Step 3 — Read the Written Test Thoroughly
|
||||
|
||||
Read the changed test file and any directly related helpers or fixtures that are necessary to understand what is actually asserted.
|
||||
|
||||
Determine:
|
||||
- what setup the test performs
|
||||
- what actions it executes
|
||||
- what it asserts explicitly
|
||||
- what it only implies but does not verify
|
||||
- what parts of the TestLink case are not covered at all
|
||||
|
||||
Be strict here:
|
||||
- execution of a step is not the same as verification of a result
|
||||
- logging or comments are not assertions
|
||||
- helper names do not count as coverage unless the underlying assertion is visible or can be traced with confidence
|
||||
|
||||
### Step 4 — Build a Coverage Matrix
|
||||
|
||||
Map the TestLink case to the written test.
|
||||
|
||||
For every TestLink step, classify coverage as one of:
|
||||
- `Covered` — the test clearly performs the step and verifies the expected result
|
||||
- `Partial` — the test performs the step but misses all or part of the required verification
|
||||
- `Missing` — the step or expected result is not covered
|
||||
- `Unclear` — likely covered indirectly, but the assertion path cannot be confirmed from the code
|
||||
|
||||
Also assess preconditions:
|
||||
- fully represented
|
||||
- partially represented
|
||||
- missing
|
||||
|
||||
### Step 5 — Produce Review Findings
|
||||
|
||||
Output findings focused on concrete gaps.
|
||||
|
||||
Template:
|
||||
|
||||
```md
|
||||
## TestLink Coverage Check
|
||||
|
||||
Case: <external_id or id> — <title>
|
||||
Source test: <file or symbol>
|
||||
|
||||
### Coverage Summary
|
||||
- Preconditions: covered/partial/missing
|
||||
- Steps covered: X/Y
|
||||
- Partial: N
|
||||
- Missing: N
|
||||
- Unclear: N
|
||||
|
||||
### Coverage Matrix
|
||||
1. Step <N>: <short action>
|
||||
- expected: <short expected result>
|
||||
- status: Covered | Partial | Missing | Unclear
|
||||
- evidence: <test function / assertion / helper>
|
||||
|
||||
### Gaps
|
||||
1. <gap title>
|
||||
- why it matters: ...
|
||||
- recommended fix: ...
|
||||
- safe to auto-apply: yes/no
|
||||
```
|
||||
|
||||
## Review Guidance
|
||||
|
||||
- Treat `Missing` and `Partial` coverage as review findings
|
||||
- Escalate to `Critical` when a missing check can hide a regression in the core scenario
|
||||
- Escalate to `Important` when the flow exists but the expected result is not asserted
|
||||
- Put naming-only or traceability-only improvements into `Optional` unless they block reliable mapping to TestLink
|
||||
|
||||
Do not edit files in this skill. It only produces coverage analysis for the proposal stage.
|
||||
@@ -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.
|
||||
@@ -0,0 +1,108 @@
|
||||
---
|
||||
name: branch-review-read-code
|
||||
description: "Read the current branch diff, surrounding code, and pyproject.toml before review. Use when: reviewing a branch, understanding current diff, preparing code review context, reading changed files with config awareness, чтение diff ветки, собрать контекст ревью, прочитать pyproject перед ревью."
|
||||
argument-hint: "Base branch or review scope (e.g. origin/main, main, src/)"
|
||||
---
|
||||
|
||||
# Branch Review: Read Code
|
||||
|
||||
This skill gathers the exact context needed for a branch review before any recommendations are made.
|
||||
|
||||
## Goals
|
||||
|
||||
- identify the review base
|
||||
- collect changed files and diff hunks
|
||||
- read surrounding code, not only modified lines
|
||||
- read `pyproject.toml` first when it exists
|
||||
- extract effective versions, modes, and tool settings that constrain the review
|
||||
|
||||
## Procedure
|
||||
|
||||
### Step 1 — Resolve Review Base
|
||||
|
||||
Determine the base branch in this order:
|
||||
1. user-provided base branch
|
||||
2. `origin/main`
|
||||
3. `origin/master`
|
||||
4. `main`
|
||||
5. `master`
|
||||
|
||||
Use git to find the merge-base and review `merge-base...HEAD`.
|
||||
|
||||
If none of these refs exist, review the staged and unstaged diff in the current branch and say that the base branch could not be resolved.
|
||||
|
||||
### Step 2 — Read pyproject.toml First
|
||||
|
||||
Before reviewing Python code, read `pyproject.toml` from the repository root when present.
|
||||
|
||||
Extract at minimum:
|
||||
- `[project]` → `requires-python`
|
||||
- `[tool.ruff]` and `[tool.ruff.lint]`
|
||||
- `[tool.mypy]`
|
||||
- `[tool.pytest.ini_options]`
|
||||
- formatter and import settings if present: `black`, `isort`, `ruff format`
|
||||
- any custom sections that affect code generation, linting, typing, tests, or packaging
|
||||
|
||||
Record the effective constraints, especially:
|
||||
- target Python version
|
||||
- strictness modes
|
||||
- enabled and ignored lint rules
|
||||
- test paths and addopts
|
||||
- line length and formatting rules
|
||||
|
||||
If `pyproject.toml` is missing, state that explicitly and continue with conservative assumptions.
|
||||
|
||||
### Step 3 — Collect the Branch Delta
|
||||
|
||||
Gather:
|
||||
- changed file list
|
||||
- diff hunks for each changed text file
|
||||
- file status: added, modified, renamed, deleted
|
||||
|
||||
Ignore generated or low-signal files unless they are central to the change:
|
||||
- lockfiles
|
||||
- build artifacts
|
||||
- minified bundles
|
||||
- vendored code
|
||||
- binary assets
|
||||
|
||||
### Step 4 — Read Surrounding Context
|
||||
|
||||
For each changed source file, read enough surrounding code to understand:
|
||||
- function and class boundaries
|
||||
- data flow into and out of the changed lines
|
||||
- nearby tests and fixtures
|
||||
- text strings or comments changed by the branch
|
||||
|
||||
If there are many files, prioritize by risk:
|
||||
1. production source code
|
||||
2. tests for changed source
|
||||
3. config files
|
||||
4. docs and text content
|
||||
|
||||
### Step 5 — Produce the Review Packet
|
||||
|
||||
Output a concise packet for the next stage:
|
||||
|
||||
```md
|
||||
## Review Packet
|
||||
|
||||
Base branch: <resolved-or-missing>
|
||||
Changed files:
|
||||
- path (status)
|
||||
|
||||
### pyproject.toml
|
||||
- found: yes/no
|
||||
- requires-python: ...
|
||||
- ruff: ...
|
||||
- mypy: ...
|
||||
- pytest: ...
|
||||
|
||||
### Priority Areas
|
||||
- file: why it is risky
|
||||
|
||||
### Notes
|
||||
- anything unusual in the diff or repo state
|
||||
```
|
||||
|
||||
Do not propose fixes yet. This skill only gathers context.
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
name: openwrt-network-discovery
|
||||
description: "Collect and validate OpenWrt network baseline before VPN changes. Use when: openwrt audit, openwrt inventory, собрать сетевой контекст openwrt, before vpn setup, interfaces and routes check, request mcp webhook details."
|
||||
argument-hint: "OpenWrt target and goals (device, version, VPN type, tunnel policy)"
|
||||
---
|
||||
|
||||
# OpenWrt Network Discovery
|
||||
|
||||
Build a reliable baseline before any routing or VPN configuration.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Any OpenWrt VPN setup or migration
|
||||
- Split tunneling and policy-based routing requests
|
||||
- GeoIP/ASN policy design
|
||||
- Cases requiring MCP or webhook integrations
|
||||
|
||||
## Procedure
|
||||
|
||||
### Step 1 - Gather Environment Facts
|
||||
|
||||
Collect from user and system:
|
||||
- router model and OpenWrt version
|
||||
- package list for VPN stack (`xray`, `sing-box`, `wireguard`, `openvpn`)
|
||||
- interface names and network zones
|
||||
- WAN uplink type and current default route
|
||||
|
||||
### Step 2 - Gather Traffic Policy Requirements
|
||||
|
||||
Ask for exact targeting:
|
||||
- destination IP list that must use VPN
|
||||
- domain-based rules if needed
|
||||
- country/GeoIP and ASN-based requirements
|
||||
- protocols/ports that must bypass or force tunnel
|
||||
|
||||
### Step 3 - Gather DNS Policy
|
||||
|
||||
Capture:
|
||||
- preferred DNS resolvers for WAN and VPN
|
||||
- encrypted DNS requirements (DoH/DoT)
|
||||
- fallback policy and leak tolerance
|
||||
|
||||
### Step 4 - Request MCP and Webhook Inputs
|
||||
|
||||
If user expects integrations, request:
|
||||
- MCP servers to use, with server IDs and intended actions
|
||||
- webhook endpoints (URL, method, auth type, headers, payload schema)
|
||||
- secret storage expectations and rotation policy
|
||||
- callback/error handling requirements
|
||||
|
||||
Do not design integration details without this data.
|
||||
|
||||
### Step 5 - Produce Discovery Summary
|
||||
|
||||
Return a structured summary:
|
||||
- validated facts
|
||||
- missing critical inputs
|
||||
- assumptions that require approval
|
||||
|
||||
## Output Format
|
||||
|
||||
```md
|
||||
## Discovery Summary
|
||||
|
||||
### Confirmed
|
||||
- ...
|
||||
|
||||
### Missing
|
||||
- ...
|
||||
|
||||
### Blocking Questions
|
||||
- ...
|
||||
|
||||
### Next Step
|
||||
- Proceed to `openwrt-vpn-routing` after confirmation.
|
||||
```
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: openwrt-network-hardening
|
||||
description: "Harden and verify OpenWrt VPN deployment with fail-closed routing, DNS leak prevention, and operational checks for split tunneling/GeoIP/ASN rules. Use when: openwrt hardening, vpn leak prevention, kill switch openwrt, verify split tunnel, validate geoip/asn policy."
|
||||
argument-hint: "Applied or planned OpenWrt VPN configuration"
|
||||
---
|
||||
|
||||
# OpenWrt Network Hardening
|
||||
|
||||
Finalize reliability, security, and day-2 operations after VPN routing setup.
|
||||
|
||||
## Procedure
|
||||
|
||||
### Step 1 - Fail-Closed and Leak Controls
|
||||
|
||||
Define controls:
|
||||
- kill-switch or fail-closed path for protected traffic
|
||||
- DNS leak prevention between WAN and tunnel
|
||||
- default-deny posture for sensitive tunnel-marked flows
|
||||
|
||||
### Step 2 - Service Robustness
|
||||
|
||||
Set:
|
||||
- service dependency ordering
|
||||
- restart policies
|
||||
- health-check commands
|
||||
- basic rollback strategy
|
||||
|
||||
### Step 3 - Monitoring and Troubleshooting
|
||||
|
||||
Provide checks for:
|
||||
- tunnel up/down state
|
||||
- route-policy correctness
|
||||
- packet counters for expected rule hits
|
||||
- endpoint reachability and latency
|
||||
|
||||
### Step 4 - Operational Runbook
|
||||
|
||||
Document:
|
||||
- what to verify after reboot
|
||||
- what to verify after package upgrades
|
||||
- how to rotate endpoints or credentials safely
|
||||
|
||||
## Output Format
|
||||
|
||||
```md
|
||||
## Hardening and Verification
|
||||
|
||||
### Controls Applied
|
||||
- ...
|
||||
|
||||
### Health Checks
|
||||
- ...
|
||||
|
||||
### Runbook
|
||||
- ...
|
||||
|
||||
### Rollback
|
||||
- ...
|
||||
```
|
||||
@@ -0,0 +1,88 @@
|
||||
---
|
||||
name: openwrt-vpn-routing
|
||||
description: "Design and implement OpenWrt VPN routing with xray/sing-box/WireGuard/OpenVPN, DNS, split tunneling, GeoIP, ASN, and selective tunnel by destination IP. Use when: openwrt vpn routing, policy based routing, split tunneling openwrt, xray routing rules, sing-box route rules, geoip asn tunnel policy."
|
||||
argument-hint: "Confirmed topology and tunnel policy from discovery stage"
|
||||
---
|
||||
|
||||
# OpenWrt VPN Routing
|
||||
|
||||
Design and produce concrete configuration for advanced OpenWrt VPN routing.
|
||||
|
||||
## Inputs Required
|
||||
|
||||
- Discovery summary from `openwrt-network-discovery`
|
||||
- Chosen VPN stack and endpoint details
|
||||
- Explicit tunnel policy (IP/domain/GeoIP/ASN)
|
||||
|
||||
## Procedure
|
||||
|
||||
### Step 1 - Select Control Plane
|
||||
|
||||
Choose one primary routing controller:
|
||||
- `pbr` package for policy-based routing
|
||||
- native `ip rule` + custom routing tables
|
||||
- service-level route control in xray/sing-box
|
||||
|
||||
Document why the selected approach fits the request.
|
||||
|
||||
### Step 2 - Build Tunnel and Interface Mapping
|
||||
|
||||
Define:
|
||||
- tunnel interface lifecycle and startup order
|
||||
- firewall zones and forwarding path
|
||||
- metric priorities and failover behavior
|
||||
|
||||
### Step 3 - Implement Selective Routing
|
||||
|
||||
Implement selective tunnel behavior for:
|
||||
- static destination IP sets
|
||||
- domain groups resolved into nft/ipset targets
|
||||
- GeoIP categories
|
||||
- ASN-based destination grouping
|
||||
|
||||
Ensure LAN bypass and management-plane safety are explicit.
|
||||
|
||||
### Step 4 - Configure DNS Path
|
||||
|
||||
Set DNS so route policy and resolver path are consistent:
|
||||
- resolver selection for tunneled and non-tunneled traffic
|
||||
- anti-leak controls
|
||||
- optional encrypted DNS
|
||||
|
||||
### Step 5 - Produce Config and Commands
|
||||
|
||||
Provide practical snippets for:
|
||||
- `/etc/config/network`
|
||||
- `/etc/config/firewall`
|
||||
- `/etc/config/pbr` (if used)
|
||||
- xray or sing-box route blocks
|
||||
- validation commands
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- `ip rule show`
|
||||
- `ip route show table <id>`
|
||||
- `nft list ruleset`
|
||||
- test destination inside and outside tunnel policy
|
||||
- DNS resolver path checks
|
||||
|
||||
## Output Format
|
||||
|
||||
```md
|
||||
## VPN Routing Plan
|
||||
|
||||
### Architecture
|
||||
- ...
|
||||
|
||||
### Config Snippets
|
||||
- file: ...
|
||||
- snippet: ...
|
||||
|
||||
### Apply Order
|
||||
1. ...
|
||||
2. ...
|
||||
3. ...
|
||||
|
||||
### Validation
|
||||
- ...
|
||||
```
|
||||
Reference in New Issue
Block a user