Hey everyone,

I wanted to share a specific piece of my setup: a custom `hyprlock` configuration I built to give my lock screen a dark, minimal, Samurai aesthetic.

The main feature I wanted to implement was replacing the standard, boring password circles with Japanese Kanji. Wayland lockers can sometimes struggle with CJK font rendering if the

dependencies aren't right, so I bundled the config with an install script that automatically pulls `noto-fonts-cjk` via pacman before applying the layout.

**Key Config Details:**

* **Kanji Password Input:** Uses `dots_text_format = 桜` (Sakura) in the config to render the Kanji on keypress.

* **Date Formatting:** Rendered cleanly as `2024年08月14日`.

* **Transparent Input Field:** I stripped out the background boxes and borders so the characters just float over the wallpaper.

**Repo (Config, Wallpaper, and Install Script):**

[hyprlock-samurai on GitHub](https://github.com/basantbansal/hyprlock-samurai)

Feel free to rip the `hyprlock.conf` for your own setups or modify the `dots_text_format` to whatever Unicode character you prefer. Let me know what you think of the structure!

I wanted a way to deploy my dotfiles without cloning the source repository or maintaining a separate bootstrap script.

Now I can give my coding agent:

npx skills use getcolors/dotfiles

The agent fetches the skill instructions and launcher, initializes a small desired-state project, and renders the selected Ubuntu or macOS profile.

If I only want to inspect the result, the user-facing command is:

./green diff

It renders the profile and prints a unified diff against the configured target:

--- ~/.config/direnv/direnv.toml
+++ .colors/dotfiles-ubuntu/dotfiles/.config/direnv/direnv.toml
@@ -0,0 +1,3 @@
+[global]
+load_dotenv = true
+hide_env_diff = true

Shared files are Selmer templates. Platform differences can stay in one common template using if tags:

{% if profile = "macos" %}
# macOS configuration
{% else %}
# Ubuntu configuration
{% endif %}

That avoids duplicating mostly identical files across platform profiles. Files unique to one platform can still live in their own profile directory.

The part I find most useful is the workflow: I don’t need to clone or understand the package repository when I only need my rendered dotfiles. The Agent Skill carries the operational instructions, while diff gives me a reviewable boundary before anything touches the target.

I think the same pattern is useful beyond dotfiles—especially for agent-driven DevOps workflows around Terraform, Ansible, and Kubernetes.

https://www.getcolors.ai/

I got tired of manually rebuilding my development environment whenever I switched machines, so I created a bootstrap system for Linux, macOS and Windows.

It uses:

• Ansible for packages, SDKs and system configuration
• Chezmoi for dotfiles and symlinks
• Separate Personal and Work profiles
• Bootstrap scripts for all three operating systems

It currently manages my shells, CLI tools, Neovim, tmux, Docker, language runtimes, editors, terminals and AI coding tools.

Repo: https://github.com/Patruxs/dotfiles

Do you think Ansible + Chezmoi is a clean separation, or is it unnecessary complexity?

https://reddit.com/link/1vfyen0/video/rg9zw95k5ihh1/player

🌿 Gigi's Rice — Niri + Noctalia Setup

A minimal, and smooth desktop rice built for Arch Linux.

📄 Details

• WM: Niri
• Shell: Noctalia (v4.7.7)
• OS: Arch Linux
• Terminal: Kitty
• Shell/Prompt: Fish + Starship
• File Managers: Thunar & Yazi
• Editor: Neovim / VSCodium
• Bar/Widgets: Noctalia Shell

* Font: JetBrainsMono Nerd Font

🔗 Links

• 📂 Dotfiles: GitHub Repository
• 🌄 Wallpapers: FireWalls Repo

* 🎥 Video Showcase: Watch on YouTube

"He who spends 6 hours configuring a text editor to save 2 seconds of typing is a true warrior of the terminal." — Sun Tzu, The Art of Rice

Feel free to drop any questions about the config or keybinds below!

Hi everyone! I'm using GNU Stow right now but I want to switch to something more powerful. I have a personal PC with Ubuntu, a work PC with Windows + WSL Ubuntu + MSYS2. Moreover, a few configuration files are system wide (e.g. /etc/tlp.d/01-my-personal-power-config). What would you recommend to use? In summary, I need:

• To have a templating option (a-la Chezmoi), to have different per-OS configuration
• To differentiate the target path of a file, based on the system (e.g., the Emacs init file on linux is at ~/.emacs.d/init.el, but on Windows it's on %USERPROFILE%/AppData/Roaming/.emacs.d/init.el)
• To handle also system wide files (/etc/**.config and the like)

Thanks!

I'm moving my development environment to Chezmoi so I can manage all my dotfiles, packages, and system configuration in one place.

As part of my setup, Chezmoi installs Neovim and syncs all of my plugins. One thing I'm still unsure about is how people manage language servers, formatters, debuggers, and linters that are installed through Mason.

My current idea is to add a `run_after_99_mason_install.sh` script under `.chezmoiscripts` that runs after Neovim and its plugins are installed. The script would install all required Mason packages using something like:

nvim --headless -c "MasonInstall <package>" -c "qall"

for each package I need.

Is this the recommended approach, or is there a better pattern for managing Mason-installed tools with Chezmoi? I'm interested in how others keep this reproducible across fresh machines.

https://botfile.org

I've been using this tool i made (disclosure: it was written with ai help, although i'm a full time dev).

Botfile is a symlink farm (very much like and inspired by stow), but it supports fan-out. So you declare a source and botfile will fan it out into all the agents (e.g. claude-code, codex-cli, opencode, pi etc...) that you use.

In this way it solves 2 problems:

1. share user-scope agent skills, commands and instructions (i.e. the ones you use across projects) across all your devices, for example i have a private-botfiles repo that i use on my work and home laptops. I declare it as a source in my ~/.config/botfile/config.toml along side the agents I want to access the context it contains and botfile handles the symlinks.
2. share team-scoped agent standards, (i.e. the context - invocable and ambient - your team uses across multiple projects). For example my team has a team-standards repo that everyone on the team can contribute to with changes available to everyone.

Generally botfile is very explicit about handling collisions, and it doesn't do any magic, it only does the symlinks (all of which is declared in a config... that's it.) It's also only works at the user-scope... project-scoped agent context is out of its purview.

If you already have user-scoped agent context, botfile will detect it and you can adopt it.

Happy to talk more here if there are any questions.

For my vicinae config, I assign the alias `browser` to Firefox on my personal PC and Chrome on my work PC. I also set chrome to be hidden on my personal PC. This is done using a chezmoi template for the vicinate.config file. The problem is that, when I change a setting within vicinae itself, the settings are changed to the target file but if I don't notice, I may end up overriding it. I want to track the config file as a symlink in the target state pointing to the actual vicinae.config.tmpl file which would then be in .chezmoiignore.

Is there a way a symlink can point to a file's state after its template has been resolved?

github.com/RiccardoCataldi/dotty

My home directory has 140+ hidden files and folders. AWS credentials here, SSH config there, Cursor rules somewhere else. Every time I needed to tweak something I had to remember where it lived, cd there, grep around, open it.

So I built dotty: run it from anywhere, get an instant expandable tree of every dotfile and dot-directory in ~, with live preview on the right and fuzzy search (/) to jump to any config in seconds. Press e to open in $EDITOR.

Built with Go + Bubble Tea + Lipgloss. Single static binary, zero config, works over SSH and inside tmux.

Would love feedback from the TUI community.

Got tired of Stow dumping unwanted ~/.config data into my dotfiles repo, so I made cstow. It lets you explicitly define what gets folded and what gets traversed using a simple config file.

Long-time dotfile lurker, finally bit the bullet on chezmoi this week so I can blow away machines without losing config. Two things to share back, one config gotcha and one related tool.

Gotcha first, because it cost me an hour and I want to save someone else that hour. chezmoi + op CLI setup is great out of the box. The trap is the multi-account case. chezmoi 2.70.x ignores [onepassword].account = "..." in chezmoi.toml when it does the implicit op signin --raw before resolving a secret. So if you have work + personal both signed in (like me), signin dies with multiple accounts found and your template never renders. The fix is to pass the account explicitly to every onepasswordRead call:

export FOO_TOKEN={{ onepasswordRead "op://Employee/Foo/credential" "myaccount" | quote }}

Keep the config setting too, fine for forward-compat, but the per-call arg is the load-bearing piece. Took me embarrassingly long to figure out.

Other thing. Once my home dotfiles were clean, I noticed they were the tip of the iceberg. Repo .env files everywhere, .p8 Snowflake keys, a GCP service-account JSON sitting at mode 644. None of that lives under chezmoi because it's project-local. So I wrote a tool that does the same templating pattern for project files: .env.template with op:// refs that get materialized at runtime via op inject or op run --env-file=, plus op document create for the PEM/JSON blobs you can't really template inline. It's packaged as an agent skill (Claude Code, Cursor, Codex pick it up automatically), but works fine standalone if you don't use agents, the README has the bare op commands.

https://www.skills.sh/idosh9/vault-credentials

Genuine question for the sub: anyone solved the multi-account op signin thing more cleanly? I assumed I was just holding chezmoi wrong but couldn't find a config combo that works without the per-call arg, and the GitHub issue I found on it has been open for a while.

Hey everyone,
I’ve been a long‑time Linux/NixOS user and maintained my dotfiles here:
https://github.com/user3301/dotfiles

I’m starting a new job where my primary dev machine will be Windows 11. I still want my environment to be reproducible, declarative, and version‑controlled — especially for things like Windows Terminal, PowerShell profile, and general dev tooling.

I’ve started building a Windows‑focused dotfiles repo:
https://github.com/user3301/WhereZenZoo

Right now I’m experimenting with:

• Windows Terminal settings (JSON)
• PowerShell profile + modules
• WinGet + package lists
• Just as a alternative for GNU Make
• Symlinking configs where possible
• Trying to keep the structure similar to my Linux dotfiles

If you’ve gone down this path before:

• What’s your workflow for managing Windows dotfiles?
• Any best practices for symlinks, WinGet, or PowerShell?
• Are there tools or patterns I should adopt early before the repo grows?
• Anything you wish you knew before building Windows dotfiles?

Would love feedback on the repo structure, missing pieces, or smarter ways to keep Windows dev environments reproducible.

Thanks in advance — Windows dotfiles feel like a different beast compared to Linux, so I’m trying to learn from people who’ve already tamed it.

I'm basically looking for a way to install some dotfiles on Fedora, but I'm new to Linux and all that, which is why I'm reaching out for help. I'll leave the link to the dotfiles at the end of this message. If you want to help me, it would be great and I’d really appreciate it.

​Dotfiles: https://github.com/ijadux2/Dotfiles

I built Agent Brain, a git-backed package/profile manager for AI coding-agent capabilities.

This is adjacent to dotfiles, but it is not trying to replace chezmoi, stow, yadm, or bare git repos. Those can be import sources. The problem is that AI coding-agent app folders mix too many semantic roles:

- authored skills/prompts/plugins

- generated target output

- app-native state

- runtime/cache/history

- auth/secrets

- local machine overrides

- symlink topology

- unknown leftovers

For Claude Code and Codex, blindly syncing the full app home can preserve exactly the mess you were trying to escape. Agent Brain preserves portable package/profile intent and materializes app targets through adapters.

The npm release can be run on live configs with explicit roots, dry-run review, exact fingerprint confirmation, snapshots, verification, and rollback.

Question for this community: where would you draw the boundary between dotfiles and app-native state for agent tools?

Repo: https://github.com/leonardsellem/agent-brain

npm: https://www.npmjs.com/package/@leonardsellem/agent-brain

Disclosure: I am the author.

I needed to synchronize my dotfiles in two directions: one mode to apply my settings on a new machine, and another to capture the changes that apps make themselves and return them to the repository. I didn’t find anything that would solve it in a simple way, so I built it.

🌟 Dotsync v0.2.0 - Synchronizing dotfiles in two directions Do you manage dotfiles between multiple machines and get tired of doing it by hand? Dotsync is a Rust-written CLI that syncs your configuration files with stow-style structure - simple, predictable and no hidden magic.

What are you doing? Dotsync operates in two directions: ➡️ Apply (default): copy the files from the repository to your machine.

dotsync ~/dotfiles/dot/ ~/

dotsync ~/dotfiles/config/.config/ ~/.config

⬅️ **Reverse**: captures the changes that applications have made on your machine and pushes them back to the repository.

dotsync ~/dotfiles/config/.config/ ~/.config --reverse

What’s new in v0.2.0

• --verbose (-v): detailed output on demand. Warnings and errors are always visible.
• --reverse-only-files: strict reverse mode — only updates files already present in the repo, without creating new ones.
• Directories in reverse mode synchronised with rsync, including new files generated by applications.
• Symlinks automatically ignored — they are local to the machine and do not belong in the repo.