Getting Help with Omarchy

A practical guide to asking for help in the Discord #omarchy-help forum and to filing a good GitHub issue against Omarchy.

The difference between a question that gets solved in ten minutes and one that sits unanswered is almost never luck. It is preparation: reproducing the problem, collecting the right details, and presenting them so a volunteer can understand the issue without asking five follow-up questions.

Table of contents

• 0. Where should I ask?
• 1. The universal rules (read these once)
• 2. Asking for help in Discord #omarchy-help
  • 2.1 Before you post
  • 2.2 Writing the title
  • 2.3 The body: the eight essentials
  • 2.4 Gathering system and hardware details
  • 2.5 The one-command report: omarchy debug
  • 2.6 Copying logs and error output
  • 2.7 Screenshots and screen recordings
  • 2.8 Formatting your post in Discord
  • 2.9 Etiquette and follow-through
  • 2.10 Copy-paste template for #omarchy-help
  • 2.11 Good vs. bad examples
• 3. Filing a GitHub issue
  • 3.1 When to file an issue (and when not to)
  • 3.2 What Omarchy's bug template asks for
  • 3.3 Anatomy of a great issue
  • 3.4 Gathering diagnostics for an issue
  • 3.5 Building a minimal reproduction for Omarchy
  • 3.6 Attaching logs, images, and videos
  • 3.7 Titles and labels
  • 3.8 Filing with the gh CLI
  • 3.9 Conduct and follow-through
  • 3.10 Copy-paste template for a GitHub issue
  • 3.11 Good vs. bad examples
• Appendix A: Command quick reference
• Appendix B: Where to find logs
• Appendix C: Sources and further reading

0. Where should I ask?

Omarchy keeps its channels deliberately separate. Using the wrong one gets your request closed or ignored, not because people are unkind but because the maintainers use these queues for different jobs.

The rules of thumb:

• Discord is the front door. Most "bugs" are configuration mistakes, hardware quirks, or misunderstandings. Discord is where those get sorted out and where a real bug gets confirmed.
• GitHub issues are for verified bugs only. Omarchy's own bug template says it plainly: "Report a validated bug — NOT FOR SUPPORT REQUESTS." GitHub Discussions is for suggestions; the Discord is for support.
• When in doubt, start in Discord. If it turns out to be a genuine bug, someone will tell you to file it, and you'll already have collected everything you need.

Official links:

• Discord: https://omarchy.org/discord
• Repository: https://github.com/omacom/omarchy (the older github.com/basecamp/omarchy link redirects here)
• Discussions: https://github.com/omacom/omarchy/discussions

1. The universal rules (read these once)

These apply to a Discord post, a GitHub issue, and almost any technical help request anywhere.

1. Reproduce it. A bug that cannot be reproduced can rarely be fixed. If you can reproduce it reliably, say so and give the steps. If it is intermittent, say how often and what seems to influence it.
2. Minimize it. Strip away everything that is not needed to trigger the problem. The smaller the example, the faster someone finds the cause.
3. Search first. Search the Discord and the existing GitHub issues before posting. If it has been asked and answered, you save everyone time. If it has been reported but is unsolved, add your details to the existing thread instead of opening a duplicate.
4. Be precise, not verbose. Volume is not precision. "It doesn't work" and a 40-line dump of unrelated logs are equally unhelpful. Give the exact error text, the exact command, and the exact result.
5. Report symptoms, not guesses. Describe what you observed. If you have a theory, label it clearly as a theory ("I suspect the NVIDIA driver, but I haven't confirmed it").
6. One problem per post or issue. Do not bundle three unrelated bugs into one report. It makes them impossible to track and close.
7. Show your homework. List what you already tried and what happened. This proves you are not wasting a volunteer's time and often reveals the answer on its own.
8. Follow up. Reply when you get more information, say thank you, and — most importantly — post the solution when it is found, so the next person finds it.

The single best question to ask yourself before submitting: "Could a stranger with the same hardware and software reproduce this using only what I've written?" If not, add what is missing.

2. Asking for help in Discord #omarchy-help

#omarchy-help is a forum channel. That means each request becomes its own post with a title and a body, rather than scrolling away in a busy chat. This is a gift: your post stays findable, and you can be replied to in a thread. Use it well.

A complete first post typically gets a useful answer without any back-and-forth. An incomplete one triggers a slow game of "what GPU do you have?" — so put the details in up front.

2.1 Before you post

Spend five minutes here. It is the highest-leverage five minutes in the whole process.

• Search the channel. Discord's search (and Ctrl/Cmd+F) can find previous posts. Read the pinned messages — they exist for a reason.
• Check the docs and the CLI. Omarchy is self-documenting:

  omarchy commands          # list every documented command and summary
  omarchy <group> --help    # e.g. omarchy theme --help
  omarchy <cmd> --help      # e.g. omarchy debug --help
  

• Try the obvious fixes, and note which ones you tried:
  • Reboot (rules out transient state).
  • omarchy update — is the problem already fixed in the latest version?
  • omarchy restart shell — restarts the status bar / notification shell.
  • hyprctl reload then hyprctl configerrors — reload and check Hyprland config for errors.
  • If you recently changed a config, theme, hook, or plugin, revert it and see whether the problem disappears. That alone often identifies the culprit.
• Note what changed. An update, a new theme, a new monitor, a new package, a config edit — recent changes are the most common cause.
• Get the version. omarchy version. Never say "the latest" — it means nothing and will be the first thing you're asked.

2.2 Writing the title

The title is your one chance to attract the person who knows the answer. A good title names the object and the deviation from expected behavior, in about 60 characters or fewer.

2.3 The body: the eight essentials

A strong body answers these eight questions. You do not need eight headings, but every answer should be somewhere in the post.

1. Goal / what you were doing. The task you were trying to accomplish and the steps you took. Describe the goal, not just the step you are stuck on.
2. What actually happened. The observed result. Include exact error text verbatim.
3. What you expected to happen. Concrete and specific.
4. Steps to reproduce. Numbered, from a known starting state. State whether it happens every time, sometimes, or once. Include any special setup.
5. System and hardware details. See 2.4.
6. Logs and error output. See 2.6.
7. What you already tried. And the result of each attempt.
8. When it started / what changed. Did it work before? After which update, change, or event did it break?

Optional but valuable: a screenshot or short recording for anything visual (2.7), and any workaround you found.

2.4 Gathering system and hardware details

Always include the Omarchy version. Add hardware details that are plausibly related to the problem — for graphics, audio, monitors, suspend, Wi-Fi, and input issues, hardware is usually the whole story.

omarchy version          # exact Omarchy version, e.g. 4.0.4-1
uname -r                 # kernel version (matters for hardware/driver issues)
inxi -Farz               # full system summary: CPU, GPU, RAM, disks, network
fastfetch                # pretty one-screen overview (alias: omarchy launch about)

When relevant, also collect:

# GPU and its kernel driver
lspci -nnk | grep -A3 -iE 'vga|3d|display'

# USB devices (input, audio, webcams, dongles)
lsusb

# Hyprland / compositor
hyprctl version
hyprctl monitors         # resolution, refresh rate, scale per output

A compact hardware line that belongs in almost every post:

Omarchy 4.0.4-1, kernel 6.12.5, AMD Ryzen 9 9950X, NVIDIA RTX 5090 (proprietary driver 570), two 27" 4K monitors @ 144Hz, Hyprland 0.56

If you cannot run inxi or fastfetch, the omarchy debug report below includes inxi -Farz for you.

2.5 The one-command report: omarchy debug

This is the single most useful thing you can attach. It gathers the information people ask for most often into one file.

# Print the report to the terminal and save it to /tmp/omarchy-debug.log.
# ALWAYS use --no-sudo --print in a scripted/non-interactive context so it
# never hangs waiting for a sudo password prompt.
omarchy debug --no-sudo --print

The report contains:

• Date, hostname, and the installed Omarchy package version
• inxi -Farz — full system, CPU, GPU, memory, and disk information
• dmesg (skipped when --no-sudo is used)
• journalctl -b -p 4..1 — all warnings and errors from the current boot
• The full installed package list, including AUR packages

Sharing it:

• Run omarchy debug without --no-sudo --print and it offers to upload the log to logs.omarchy.org (the link expires after 24 hours) and prints a shareable URL. That URL is perfect for a Discord post or GitHub issue.
• Or choose "Save in current directory" to get ./omarchy-debug.log and attach the file.

Privacy note: this report includes your hostname, package list, and hardware serial-ish details. Skim it before posting publicly. It does not include your files.

2.6 Copying logs and error output

Start with omarchy debug (2.5). For anything it does not cover, use the sources below.

Journal (systemd) — the general-purpose log:

journalctl -b -p 3                 # errors from the current boot
journalctl -b -p 4..1              # warnings + errors from the current boot
journalctl --since "10 min ago"    # a time window around the problem
journalctl -u <unit>               # a specific system service
journalctl --user -u <unit>        # a specific user service
journalctl -f                      # follow live, then reproduce the issue
journalctl -k -b                   # kernel messages this boot (dmesg equivalent)

For a bug that happens now, reproduce it while journalctl -f is running, then copy the lines around the failure.

Hyprland (the compositor):

hyprctl configerrors               # config parse errors — check this first
hyprctl monitors                   # output configuration
hyprctl clients                    # open windows and their properties

Hyprland's runtime log lives at:

$XDG_RUNTIME_DIR/hypr/$HYPRLAND_INSTANCE_SIGNATURE/hyprland.log

Omarchy shell / bar (Quickshell): the shell logs to the journal, so filter the user journal around the time of the problem:

journalctl --user -b -p 4..1 | grep -iE 'qs|quickshell|omarchy'
omarchy restart shell              # restart it, then re-check the journal

Screen recording failures: rerun with debug enabled and attach the log:

OMARCHY_SCREENRECORD_DEBUG=true omarchy screenrecord --fullscreen
# ... reproduce ...
omarchy screenrecord --stop-recording
# then attach /tmp/omarchy-screenrecord.log

Crashes / process disappeared:

coredumpctl list                   # recently crashed processes
coredumpctl info <pid|name>        # details for one crash
coredumpctl gdb <pid|name>         # load it in gdb for a backtrace

Omarchy can also help: omarchy crash watch watches for crashes, and clicking a crash notification (or running omarchy agent crash <pid>) offers an AI diagnosis. omarchy toggle crash capture toggles the notifications.

Update failures:

omarchy update analyze logs        # check the update log for known failures

Copying text out of a terminal:

• Select with the mouse and copy. Most Omarchy terminals copy on selection; Ctrl+Shift+C is the usual explicit shortcut.
• Redirect any command to a file: some-command > /tmp/out.log 2>&1
• If the text is only visible as pixels (a graphical error dialog, a game overlay), use OCR to grab it: omarchy capture text — select the region and the text lands on your clipboard.
• Save a screenshot to disk: omarchy capture screenshot region save.

2.7 Screenshots and screen recordings

For visual bugs — rendering glitches, a bar that overlaps, a window that won't tile, a flicker — a capture is worth a thousand words.

omarchy screenshot                              # smart interactive flow
omarchy capture screenshot region               # select a region
omarchy capture screenshot windows              # pick a window
omarchy capture screenshot fullscreen save      # straight to disk, prints path

omarchy screenrecord --fullscreen               # start recording
# ...reproduce the problem on camera...
omarchy screenrecord --stop-recording           # stop, prints the saved path

Keep recordings short and focused on the misbehavior — a 10-second clip beats a 5-minute one. Shrink large files before sharing with omarchy transcode <input>. See 2.8 for how to attach them.

2.8 Formatting your post in Discord

How you present information determines whether people read it.

• Use code blocks for logs and commands. Triple backticks, with a language tag for highlighting:

  ```bash
  omarchy version
  ```
  

  Use bash, log, or text. Without a code block, Discord mangles indentation and turns # into headings.

• Do not screenshot text. Screenshots of error messages cannot be searched, copied, or quoted. Paste the text. Reserve screenshots for genuinely visual problems.

• Keep it short; attach the long parts. Paste the few relevant lines inline and attach the full log as a file, or use the logs.omarchy.org URL from omarchy debug. Nobody reads a 500-line wall.

• Paste only the relevant config. If you edited a config file, paste the relevant lines (or a diff), not the entire file.

• Redact secrets. Remove tokens, API keys, email addresses, MAC addresses, IPs, serial numbers, and file paths that reveal personal information. Keep the technical structure visible so the log is still useful.

• Write in clear English. Short sentences, correct spelling, no walls of unbroken text. Non-native English is completely fine; just be precise.

2.9 Etiquette and follow-through

• Don't ask to ask. "Can anyone help?" accomplishes nothing. Post your complete question in the first message.
• Don't ping. No @here, @everyone, or DMing helpers. It is rude and counterproductive.
• Don't mark it urgent. Everyone's problem feels urgent to them; volunteers are not an on-demand service.
• Be patient with time zones. The person who knows the answer may be asleep. Post, then check back later. Don't bump repeatedly.
• Stay on topic and in one place. Don't hijack someone else's post, and don't cross-post the same question in several channels.
• Respond when asked for more info. The sooner you provide it, the sooner you're helped.
• Mark the solution. When your post is solved, reply with the fix and use the forum's Mark Solution action on the helpful reply. This makes the answer findable for everyone who comes later.
• Close the loop. A short "thanks, that fixed it" costs nothing. If you solved it yourself, post how.

2.10 Copy-paste template for #omarchy-help

Copy this into your post and fill in the blanks. Delete anything that does not apply.

**Title:** <object> — <deviation>  (e.g. "External monitor goes black after suspend on NVIDIA")

**What I was trying to do**
...

**What happened**
...

**What I expected**
...

**Steps to reproduce**
1.
2.
3.
Frequency: always / sometimes / once

**System / hardware**
- Omarchy: <output of `omarchy version`>
- Kernel: <output of `uname -r`>
- CPU / GPU: ...
- Monitors / other relevant hardware: ...

**Logs / errors**
```log
<paste the relevant lines here>
```
Full `omarchy debug` report: <logs.omarchy.org URL or attached file>

**What I already tried**
- ...

**When it started / what changed**
...

**Extra**
Screenshot/recording: <attach>

2.11 Good vs. bad examples

Bad post

Title: help

Hi, my omarchy is broken, the screen keeps messing up after I close my laptop. I tried stuff but nothing works. Can someone help me? I really need this fixed today. Also sometimes the bar disappears.

Problems: no version, no hardware, no steps, no logs, vague symptom ("messing up"), multiple issues in one post, urgency, no evidence of any troubleshooting.

Good post

Title: External monitor goes black after suspend on NVIDIA, requires replug

What I was trying to do: Use an external 4K monitor with my laptop and suspend/resume it.

What happened: After resuming from suspend, the external monitor is black but the laptop panel works. hyprctl monitors still lists it at the right resolution. Unplugging and replugging the cable fixes it until the next suspend. Happens every time.

Expected: Both monitors come back after resume.

Steps to reproduce:

1. Connect the monitor over DisplayPort.
2. systemctl suspend, then wake the machine.
3. External monitor is black.

System / hardware:

• Omarchy: 4.0.4-1
• Kernel: 6.12.5-arch1-1
• CPU/GPU: Ryzen 9 9950X / NVIDIA RTX 5090, driver 570.86.16 (proprietary)
• Monitor: Dell U2723QE @ 4K/60Hz over DP

Logs:

<relevant `journalctl -b` lines around resume>

Full report: <logs.omarchy.org/...>

What I already tried: hyprctl reload (no change); switching to a TTY and back (no change); omarchy update (already current); reverting my only custom Hyprland keybinding (no change).

When it started: After the 4.0.4 update; worked on 4.0.3.

Extra: 8-second recording attached showing the black screen and the replug fix.

This post can be triaged immediately.

3. Filing a GitHub issue

GitHub issues are the permanent, searchable record of a confirmed bug. They are the right tool only once a problem has been reproduced and confirmed to be a bug in Omarchy itself.

3.1 When to file an issue (and when not to)

File an issue when:

• You can reproduce the problem on the latest version.
• It is a bug in Omarchy (its scripts, configs, themes, shell, installer, or migrations), not a misconfiguration or a third-party app.
• You searched the existing issues and did not find it.

Do not file an issue for:

• Support questions, "how do I…", or "is this a bug?" → Discord #omarchy-help.
• Feature ideas and suggestions → GitHub Discussions → Suggestions.
• A bug in an upstream project Omarchy merely ships (a browser, a text editor, a library). Report it upstream first; only file with Omarchy if Omarchy's packaging/config is at fault.
• The same bug that already has an open issue — add your details to the existing issue instead. Duplicates get closed and split the discussion.

The repository disables blank issues and routes Suggestions and Support through its template chooser, so you will be pointed to the right place automatically.

3.2 What Omarchy's bug template asks for

Omarchy's bug template is intentionally short. It asks for two things:

1. System details — required. For example: AMD 9950X, NVIDIA 5090, Omarchy 2.1.0
2. What's wrong? — required. Describe the issue, include steps to recreate it if possible, and attach the output of omarchy debug if possible.

The template header reminds you that "Omarchy is an open source gift, not a product you bought from a vendor." Keep that in mind throughout.

Because the template is minimal, the quality of your issue is entirely up to how much of the structure below you include. A great issue goes well beyond the two required fields.

3.3 Anatomy of a great issue

Write the issue so a maintainer can reproduce it without asking you a single follow-up question.

3.4 Gathering diagnostics for an issue

The tools are the same as for Discord; the difference is that a GitHub issue should be self-contained and permanent.

# 1. Exact versions
omarchy version
uname -r

# 2. The full diagnostic report (also written to /tmp/omarchy-debug.log)
omarchy debug --no-sudo --print

# 3. For a shareable, permanent-ish link: run the interactive form and choose
#    "Upload log". It uploads to logs.omarchy.org (link expires after 24h) and
#    prints a URL you can paste into the issue.
omarchy debug

Then add the specific evidence for your bug:

• Logs: the relevant journalctl window, the Hyprland log, the shell journal — see 2.6.
• Crashes: coredumpctl info <pid|name>, or the output of omarchy agent crash <pid>.
• Update problems: omarchy update analyze logs.
• Screen-recording failures: OMARCHY_SCREENRECORD_DEBUG=true and attach /tmp/omarchy-screenrecord.log.

Because logs.omarchy.org links expire in 24 hours, also paste the key lines inline or attach the log file to the issue so the evidence survives.

3.5 Building a minimal reproduction for Omarchy

A minimal reproduction is the most valuable thing in any bug report. For Omarchy, it usually takes one of these forms:

• Config bug: paste the exact change you made (a diff or the relevant lines from ~/.config/...), and say whether the bug still happens after omarchy refresh <app> (which restores defaults). If stock config is fine and only your edit breaks it, say so — that narrows it enormously.
• Theme / hook / plugin bug: include the custom theme directory, hook script, or plugin file. Note whether the stock theme/behavior works, and whether the bug appears only with yours.
• Command bug: give the exact command and its full output:

  omarchy some-command --flag
  # full output below
  

• Keybinding bug: give the binding you added and the exact keys, and note whether a conflicting stock binding exists.
• Hardware bug: state the hardware precisely (model, driver, connection type). Hardware bugs are often not reproducible on the maintainer's machine, so detail is everything.

Minimize by removing everything unrelated. If you can trigger the bug with one line of config and one command, you have a reproduction that will get fixed.

3.6 Attaching logs, images, and videos

• Web form: drag and drop files directly into the issue body. This works for images and videos. Prefer a short recording for visual bugs.
• gh CLI: gh issue create cannot upload images or other files. If you file from the terminal, either (a) paste text logs inline and use the logs.omarchy.org URL, or (b) create the issue with gh, then open it in the browser and drag-and-drop the captures into a follow-up comment.
• Large text logs: attach a .log file, or use the logs.omarchy.org upload. Do not paste thousands of lines inline.
• Redact secrets before attaching. Logs can contain usernames, tokens, paths, emails, and machine identifiers. Remove the sensitive values but keep enough structure that the log is still readable.

3.7 Titles and labels

• Use the object — deviation convention from 2.2. A title like Export fails when filename contains an emoji is triaged fast; It's broken is not.
• Do not editorialize ("terrible bug") or prescribe a fix in the title. Describe the problem.
• Labels such as bug are applied by maintainers — you generally do not need to set them. The template applies bug automatically.

3.8 Filing with the gh CLI

The GitHub CLI is the fastest way to search, file, and follow up.

# Search existing issues first — avoid duplicates
gh search issues --repo omacom/omarchy "external monitor suspend"
gh issue list --repo omacom/omarchy --state open --search "monitor black"

# File a new issue from a prepared body file (write it once, reuse it)
gh issue create --repo omacom/omarchy \
  --title "External monitor goes black after suspend on NVIDIA" \
  --body-file /tmp/issue.md

# Follow up
gh issue view <number> --repo omacom/omarchy
gh issue comment <number> --repo omacom/omarchy --body "Additional info: ..."

Prepare the body with the template in 3.10. Remember that media must be attached through the web UI afterwards.

3.9 Conduct and follow-through

• Write in English. Issues are read by maintainers and users worldwide.
• Be civil and patient. Maintainers are volunteers; Omarchy is a gift, not a product. Demanding a fix, an ETA, or immediate attention will not help.
• Don't spam "any update?". If you have new information, add it. If not, wait.
• Respond to requests for information. An issue that goes quiet without the requested logs may be closed as unreproducible.
• Stay on one issue. If you discover a second, unrelated bug, file a second issue.
• Report the outcome. If a workaround or a fix solves it, comment with the details, then close the issue (or let a maintainer close it).
• Contribute a fix if you can. Fork the repo and open a PR rather than editing /usr/share/omarchy/ on your machine — the packaged files are overwritten on update. Follow the repository's AGENTS.md and run ./test/all before pushing. A PR that fixes a visual bug should include before/after captures.

3.10 Copy-paste template for a GitHub issue

### System details

- Omarchy: <`omarchy version`>
- Kernel: <`uname -r`>
- CPU / GPU: ...
- Relevant hardware (monitors, audio, Wi-Fi, input, laptop model): ...

### What's wrong?

<One-paragraph summary.>

### Steps to reproduce

1.
2.
3.

Frequency: always / sometimes / once

### Expected result

...

### Actual result

...
```log
<verbatim error output / relevant log lines>
```

### Diagnostics

- Full `omarchy debug`: <logs.omarchy.org URL> and/or attached `omarchy-debug.log`
- Relevant `journalctl` / Hyprland log lines: (above)

### Minimal reproduction

<Exact config diff, command, or file needed to trigger the bug. State whether
stock config/theme works.>

### Regression

- Last known good version: ...
- First known bad version: ...
- `git bisect` result (if available): ...

### Workaround

...

### Captures

<Attach a short recording or screenshot for visual bugs.>

3.11 Good vs. bad examples

Bad issue

Title: Doesn't work

Omarchy broke my audio. Fix it. I'm on a Dell. I need this working for a meeting tomorrow. Please help ASAP.

Problems: no version, no hardware detail, no logs, no reproduction, demands and urgency, filed as a bug when it is a support question.

Good issue

Title: HDMI audio device disappears after plugging in USB-C dock

System details: Dell XPS 13 9340, Intel Core Ultra 7 155H, Intel Arc integrated graphics, Omarchy 4.0.4-1, kernel 6.12.5-arch1-1, PipeWire 1.2.7.

What's wrong?: When I connect an Anker 555 USB-C dock, the built-in HDMI audio sink disappears from wpctl status and does not come back until I reboot. Reproducible every time.

Steps to reproduce: 1) Boot with no dock. 2) Confirm HDMI sink present in wpctl status. 3) Plug in the dock. 4) HDMI sink is gone.

Expected: Both the dock's audio and the HDMI audio remain available.

Actual: HDMI sink vanishes; only the dock and internal speakers remain.

Diagnostics: Full omarchy debug at <logs.omarchy.org/...>; attached journalctl -b excerpt around the plug event.

Regression: Worked on 4.0.3; first bad on 4.0.4.

Workaround: Rebooting with the dock attached keeps the sink available.

Captures: 15-second recording attached.

This issue can be confirmed and fixed.

Appendix A: Command quick reference

Appendix B: Where to find logs

Appendix C: Sources and further reading

This guide distills established bug-reporting practice and Omarchy's own documentation:

• Omarchy Discord (support): https://omarchy.org/discord
• Omarchy repository and issue templates: https://github.com/omacom/omarchy
• Arch Wiki, Bug reporting guidelines: https://wiki.archlinux.org/title/Bug_reporting_guidelines
• Mozilla, Bug Writing Guidelines: https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html
• Stack Overflow, How to create a Minimal, Reproducible Example: https://stackoverflow.com/help/minimal-reproducible-example
• Eric S. Raymond, How To Ask Questions The Smart Way: http://www.catb.org/esr/faqs/smart-questions.html
• Discord, Forum Channels FAQ: https://support.discord.com/hc/en-us/articles/6208479917079-Forum-Channels-FAQ
• Omarchy skill guides: capture.md and contributing.md (bundled with the Omarchy skill).

When in doubt: reproduce it, minimize it, gather omarchy debug, and post the whole story in one message. That is 90% of getting help.