managing-chezmoi
Chezmoi Management
Operate as a chezmoi power-user: understand source/target model, CLI workflows, templating, ignore rules, and drift resolution.
Quick Reference
Commands & workflows: See commands-and-workflows.md Troubleshooting: See troubleshooting.md
Default Workflow
- Inspect state:
chezmoi statusandchezmoi diff - Edit source directly: modify files in this repo (the source state)
- Apply safely:
chezmoi apply --dry-run -v, thenchezmoi apply - Verify:
chezmoi verifyafter larger refactors
Complexity Decision Tree
| Situation | Action |
|---|---|
| Simple file change | Edit source → chezmoi apply <target> |
| New file to manage | chezmoi add <target> → chezmoi apply |
| Unexpected diffs | chezmoi diff -v → chezmoi verify → troubleshoot |
| Conditional behavior | Check templates + chezmoi data |
| Command uncertainty | Fetch docs via Context7 |
Chezmoi Expertise Checklist
When helping with a request, consider:
- Source vs target: User might be editing the wrong side
- Source file naming:
dot_prefixes,private_files,.tmplsuffix - Ignore rules:
.chezmoiignorepatterns and conditionals - Templates:
{{ ... }}logic,chezmoi data - Safe operations: Prefer dry-runs and diffs before applying
Context7 Usage
When uncertain about chezmoi commands/flags or version-specific behavior:
- Call
resolve-library-idwithlibraryName="chezmoi" - Call
query-docswith a targeted question - Prefer newest documented behavior
More from mrpointer/dotfiles
configuring-zsh
Configure and troubleshoot Zsh shell. Use when editing .zshenv, .zprofile, .zshrc, .zlogin, or .zlogout, setting up powerlevel10k prompt, configuring oh-my-zsh or sheldon plugin manager, fixing PATH or environment variables, debugging slow shell startup, setting up completions/compinit/fpath, or working with zsh-autocomplete, zsh-autosuggestions, or zsh-syntax-highlighting plugins.
20configuring-github-actions
Create and troubleshoot GitHub Actions workflows. Use when editing .github/workflows files, setting up CI/CD pipelines, configuring matrix builds for multi-platform testing, debugging failing workflows, adding caching or artifacts, running E2E tests in containers, or asking "why is my workflow failing" or "how do I test on multiple OSes".
11writing-go-tests
Write Go tests following project conventions. Use when creating test files, writing unit or integration tests, choosing mocks, or setting up test fixtures. Covers test naming, assertions, mock usage, table-driven patterns, and common pitfalls.
1writing-go-code
Apply Go coding standards when writing or modifying Go code. Use when implementing functions, using dependency injection, handling errors idiomatically, or working with interfaces. For test conventions, use the `writing-go-tests` skill instead.
1testing-go-code
Run Go unit tests, coverage reports, and benchmarks. Use when you need to run tests, check coverage, run benchmarks, or regenerate mocks after interface changes.
1linting-go-code
Lint and format Go code. Use when you need to run linters, fix lint errors, format code, or understand why a linter is complaining.
1