omarchy
Omarchy operating guardrails for day-to-day system work: assume the host is Omarchy by default, choose Omarchy-native workflows first, map user intent to the correct omarchy-* wrapper/script family, and avoid generic Linux commands that conflict with Omarchy behavior. Use whenever handling local system tasks on this host unless the user explicitly says it is not Omarchy; prioritize safe Omarchy commands, prevent non-Omarchy shortcuts (e.g., ad-hoc process killing/relaunch patterns), troubleshoot desktop behavior, and validate the right script before execution.
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/achals-iglu/omarchyOmarchy Skill
Treat this skill as an Omarchy operating mode, not just a command catalog. When working on an Omarchy system, prefer Omarchy-native wrappers and workflows over generic Linux one-liners that may bypass expected state handling. Use local script docs and names to choose the correct path. Each script has documentation at the top describing its purpose. DO NOT RUN A SCRIPT UNTIL YOU ARE SURE OF ITS PURPOSE.
Operating rules
- Start with command name matching and in-file comments under
/home/achals/.local/share/omarchy/bin. - Prefer read-only/status commands first (
*list*,*status*,*current*,*available*,*version*). - Ask before broad or high-impact actions (
*install*,*remove*,*reinstall*,*update*,*pkg*,*setup*,*set*). - Avoid bulk discovery execution. Do static inspection first.
- Never assume
omarchy-*scripts support standard CLI flags or parameters (including--help). Treat each script as custom; inspect its file/header comments first.
Worked examples (good vs bad)
Use these patterns whenever you operate on Omarchy. The goal is not "run an omarchy command at all costs"; the goal is to avoid bypassing Omarchy’s intended state-management flows.
1) Restarting Waybar
User intent: "Waybar is broken, restart it."
- Bad (generic shortcut):
pkill waybar && waybar
- Good (Omarchy-native):
omarchy-restart-waybar
- Why: Omarchy wrappers usually handle environment/session assumptions better than raw kill-and-relaunch one-liners.
2) Applying config/UI refresh after edits
User intent: "I changed config, apply it."
- Bad:
- restarting random processes manually until things look fixed
- Good:
- use targeted refresh script first, e.g.
omarchy-refresh-waybar,omarchy-refresh-hyprland,omarchy-refresh-config(pick by component)
- use targeted refresh script first, e.g.
- Why: refresh scripts are explicit and reversible; manual shotgun restarts are noisy and risky.
3) Package management task
User intent: "Install/remove package X."
- Bad:
- using raw
pacman/yayfirst without checking Omarchy wrappers
- using raw
- Good:
- inspect and prefer
omarchy-pkg-*flow (...-present,...-missing, then...-install/...-remove)
- inspect and prefer
- Why: wrapper flow keeps behavior consistent with Omarchy expectations.
4) Theme change request
User intent: "Switch theme / sync theme to apps."
- Bad:
- editing dotfiles manually first and restarting random apps
- Good:
omarchy-theme-list->omarchy-theme-set-> app-specific follow-ups if needed (omarchy-theme-set-vscode,...-browser,...-obsidian)
- Why: Omarchy theme pipeline may include extra integration steps beyond plain config edits.
5) Audio/Bluetooth/Wi‑Fi issue
User intent: "Audio/Bluetooth/Wi‑Fi stopped behaving."
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-achals-iglu-omarchy": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
dokploy
Use for Dokploy-specific API operations (apps, deployments, databases, domains, backups, settings) when tasks explicitly involve Dokploy. Route requests to domain modules, enforce inspect-first troubleshooting and controlled mutations via x-api-key authentication, and avoid use for generic Docker/Kubernetes work outside Dokploy.
Remember Me
Skill by achals-iglu