agentleFS
bastosbastos/skills/mikrotik-routeros/SKILL.md

mikrotik-routeros

Skill7 starsChanged 10 months agoMITView on GitHub

Configures and automates MikroTik RouterOS routers through the terminal, command line interface, .rsc imports, /system script repository, Scheduler, Netwatch, firewall, NAT, DHCP, DNS, bridge, VLAN, routing, VPN, device-mode, backup/export, and RouterOS scripting. Use this skill whenever the user mentions MikroTik, Mikrotik, RouterOS, WinBox terminal, router CLI, router scripts, .rsc files, or configuring MikroTik services from the command line.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 9 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to generate, review, or troubleshoot RouterOS command-line configuration and scripts.

    line 12
  2. Distinctive:

    Read the smallest relevant reference before producing commands:

    line 16
  3. Very specific:

    Prefer commands that are safe to paste into a RouterOS terminal.

    line 28
  4. Very specific:

    Use stable identifiers: item names, comments, default-name values, or [find ...] filters.

    line 29
  5. Distinctive:

    Never guess credentials, public IPs, interface roles, or firewall rule order.

    line 36
  6. Very specific:

    Do not include real passwords, private keys, shared secrets, or show-sensitive output unless the user explicitly asks and understands the …

    line 37
  7. Distinctive:

    Prefer SSH or local terminal examples.

    line 38
  8. Distinctive:

    If the user asks for a destructive reset, include the exact consequence and a backup/export step first.

    line 40
  9. Very specific:

    Write commands in slash-separated form: /ip/address/print, /system/script/add, /interface/bridge/vlan/add.

    line 78
  10. Very specific:

    Keep param=value tight; RouterOS does not allow spaces around =.

    line 79
  11. Distinctive:

    Use comments as durable anchors for generated rules and scheduled jobs.

    line 81
  12. Very specific:

    Use print terse or print detail for state capture, and print where ...

    line 82
  13. Very specific:

    Use export terse for portable command output.

    line 83
  14. Distinctive:

    Use this pattern when adding an object that should exist at most once:

    line 87
  15. Distinctive:

    Before handing off commands, check:

    line 99
  16. Distinctive:

    Import files use RouterOS syntax, not Bash.

    line 105

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

MikroTik RouterOS CLI and Scripting

Use this skill to generate, review, or troubleshoot RouterOS command-line configuration and scripts. Target RouterOS v7 unless the user gives a different version.

Reference Loading

Read the smallest relevant reference before producing commands:

  • references/official-docs.md - source map for official MikroTik documentation and version notes.
  • references/routeros-cli.md - terminal syntax, paths, item targeting, quoting, and SSH execution.
  • references/routeros-scripting.md - RouterOS script structure, variables, functions, error handling, and script repository behavior.
  • references/config-change-workflows.md - backups, exports, safe mode, imports, resets, and rollback planning.
  • references/recipes.md - reusable command patterns for common configuration tasks.

Operating Model

  1. Determine whether the user wants live execution, a command plan, a reusable .rsc file, or a /system script entry.
  2. Gather only the facts needed to avoid an unsafe or wrong config: RouterOS version, model, management IP/interface, WAN/LAN interface names, bridge/VLAN design, and existing rule order.
  3. Prefer commands that are safe to paste into a RouterOS terminal. Use absolute menu paths such as /ip/firewall/filter instead of relying on the current menu.
  4. Use stable identifiers: item names, comments, default-name values, or [find ...] filters. Avoid numeric item IDs in generated scripts because CLI numbers are session-local.
  5. Make commands idempotent where practical. Check for existing objects with [find ...] before adding duplicates.
  6. Separate preflight, changes, verification, and rollback. Router configuration mistakes can cut off management access.

Safety Defaults

  • For remote network, firewall, route, bridge, VLAN, or address changes, recommend an export and either safe mode or a staged rollback path before making changes.
  • Never guess credentials, public IPs, interface roles, or firewall rule order. Use placeholders or ask for the missing value if it is a blocker.
  • Do not include real passwords, private keys, shared secrets, or show-sensitive output unless the user explicitly asks and understands the exposure.
  • Prefer SSH or local terminal examples. Do not recommend Telnet except for an explicitly isolated recovery scenario.
  • Flag commands that reboot, reset, disable management services, remove addresses/routes, or alter input firewall policy.
  • If the user asks for a destructive reset, include the exact consequence and a backup/export step first.

Answer Shape

For configuration changes, use this structure:

## Preflight
<read-only commands to inspect state and save config>

## Commands
<RouterOS commands, grouped by subsystem>

## Verify
<commands to prove the intended state and connectivity>

## Rollback
<minimal commands or restore path>

For scripts, use this structure:

## Script
<source code or /system script add/set command>

## Install
<commands to add the script and required policy>

## Test
<manual run, logs, dry-run behavior if applicable>

## Schedule or Trigger
<scheduler/netwatch/button hook only if requested>

RouterOS Command Style

  • Write commands in slash-separated form: /ip/address/print, /system/script/add, /interface/bridge/vlan/add.
  • Keep param=value tight; RouterOS does not allow spaces around =.
  • Quote strings with spaces or special characters: comment="managed by routeros-script".
  • Use comments as durable anchors for generated rules and scheduled jobs.
  • Use print terse or print detail for state capture, and print where ... for targeted checks.
  • Use export terse for portable command output; use binary /system backup only for same-device restore scenarios.

Idempotent Pattern

Use this pattern when adding an object that should exist at most once:

:if ([:len [/ip/firewall/address-list/find list="mgmt-allow" address="203.0.113.10"]] = 0) do={
    /ip/firewall/address-list/add list="mgmt-allow" address="203.0.113.10" comment="managed: admin workstation"
}

For existing objects, use set [find ...] ... only when the find expression is expected to match exactly one item. If multiple matches are possible, print and ask the user to choose or narrow the filter.

Validation Checklist

Before handing off commands, check:

  • Interface names match the user's device, or are clearly placeholders.
  • Firewall rules are placed before broad drop/reject rules.
  • Management allow rules are added before any restrictive input policy.
  • Scripts declare variables before use and use local scope unless persistence is intentional.
  • Import files use RouterOS syntax, not Bash.
  • Version-sensitive features are labelled and linked to official docs when needed.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.