If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/skwp/dotfiles shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 4mo ago
• 28+ active contributors
• Distributed ownership (top contributor 40% of recent commits)
• BSD-2-Clause licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 4mo ago

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live skwp/dotfiles repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/skwp/dotfiles.

What it runs against: a local clone of skwp/dotfiles — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in skwp/dotfiles | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-2-Clause | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 142 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of skwp/dotfiles. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/skwp/dotfiles.git
#   cd dotfiles
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of skwp/dotfiles and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "skwp/dotfiles(\\.git)?\\b" \\
  && ok "origin remote is skwp/dotfiles" \\
  || miss "origin remote is not skwp/dotfiles (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-2-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-2-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-2-Clause" \\
  || miss "license drift — was BSD-2-Clause at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "install.sh" \\
  && ok "install.sh" \\
  || miss "missing critical file: install.sh"
test -f "Rakefile" \\
  && ok "Rakefile" \\
  || miss "missing critical file: Rakefile"
test -f "bin/yadr/yadr" \\
  && ok "bin/yadr/yadr" \\
  || miss "missing critical file: bin/yadr/yadr"
test -f ".gitmodules" \\
  && ok ".gitmodules" \\
  || miss "missing critical file: .gitmodules"
test -f "vim/after/plugin/vimrc_after.vim" \\
  && ok "vim/after/plugin/vimrc_after.vim" \\
  || miss "missing critical file: vim/after/plugin/vimrc_after.vim"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 142 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~112d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/skwp/dotfiles"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

YADR (Yet Another Dotfile Repo) is a curated, opinionated dotfiles distribution that bundles 90+ vim plugins, prezto-based zsh configuration, and shell scripts into one cohesive setup. It solves the problem of individually collecting and configuring best-in-class terminal, vim, and git tools by providing them pre-integrated and battle-tested, installable via a single curl command. Monolithic dotfiles structure: bin/yadr/ contains the Ruby-based installer/command framework (using git-style-binaries pattern); .yadr directory holds configuration modules; Rakefile orchestrates plugin updates and installation; vim/zsh configs live in dotfiles directories (inferred from project description); Dockerfile present for containerized testing.

macOS/BSD developers and power users who spend significant time in vim and the terminal, want a production-ready editor and shell setup out-of-the-box without spending weeks curating plugins and resolving conflicts, and appreciate strong opinionated defaults over minimal configs.

Actively maintained but showing signs of stability plateau. The repo has substantial history (v1.1+ indicated in README) and includes CI via GitHub Actions (.github/workflows/stale.yml). However, no recent commit date visible in provided data; the embedded git-style-binaries library is from 2011-era, and the project emphasizes macOS support with explicit Linux/Ubuntu non-support. Verdict: production-ready for macOS vim/zsh users, but not under rapid active development.

Single-maintainer risk (skwp as apparent sole owner). Embedded dependencies are outdated (git-style-binaries-0.1.11, trollop-1.16.2 from early 2010s). The installation method (curl | sh) is high-trust and requires careful review. Heavy vim plugin coupling means updates could cause breakage across the entire stack. Platform risk: macOS-first design with explicit non-support for Linux creates maintenance burden if broader OS support is needed.

Repository appears to be in maintenance mode. The .github/workflows/stale.yml suggests automated issue/PR management. No specific PR or active feature branch data visible, but Rakefile indicates ongoing rake update cycle for plugin management. Last substantive work likely around plugin/dependency updates.

# Clone and install via official script (recommended)
sh -c "$(curl -fsSL https://raw.githubusercontent.com/skwp/dotfiles/master/install.sh)"

# Or clone directly and run Rake tasks
git clone https://github.com/skwp/dotfiles.git ~/.yadr
cd ~/.yadr
rake install
rake update  # Always run after pulling

Daily commands: YADR is not a service—it's an environment installer. After installation, you get a configured shell (zsh), vim editor, and git integration. To start: zsh enters the configured shell; vim launches the configured editor with all plugins loaded; rake update refreshes plugins. Docker option: docker build -f Dockerfile . for isolated testing environment.

• install.sh — Main entry point for dotfile installation—every contributor must understand the installation flow and how files are symlinked.
• Rakefile — Core build and maintenance automation—defines rake tasks for plugin updates and system setup that all contributors rely on.
• bin/yadr/yadr — Primary CLI command dispatcher—the interface through which users and developers interact with the entire YADR system.
• .gitmodules — Git submodule configuration for all vim and zsh plugins—critical dependency manifest that must be kept in sync.
• vim/after/plugin/vimrc_after.vim — Post-initialization vim configuration—where final plugin tweaks and keybindings are applied, loaded after all plugins.
• bin/yadr/default_libs.rb — Ruby library defaults and shared utilities—foundational code used across all YADR CLI commands and tools.
• README.md — Project philosophy and usage overview—defines YADR's purpose, supported platforms, and quick-start instructions for new users.

Add a New Vim Plugin

1. Run the YADR CLI command to add plugin submodule (bin/yadr/yadr-vim-add-plugin)
2. Plugin is automatically initialized as git submodule and added to .gitmodules (.gitmodules)
3. Add custom keybindings or configuration in post-init hooks (vim/after/plugin/vimrc_after.vim)
4. Run rake update to ensure all plugins are properly installed (Rakefile)

Customize Shell Environment

1. Add shell aliases and functions to zsh config (.yadr)
2. Override or extend tmux keybindings for multiplexing (tmux/tmux.conf)
3. Set iTerm2 color scheme by choosing light or dark variant (iTerm2/Solarized Dark.itermcolors)
4. Run install.sh to symlink updated configuration files (install.sh)

Extend Vim Keybindings and Features

1. Review existing keybindings documented in guide (doc/vim/keymaps.md)
2. Add new custom keymaps after all plugins are loaded (vim/after/plugin/vimrc_after.vim)
3. For filetype-specific rules, create or edit ftplugin file (vim/ftplugin/gitcommit.vim)
4. Test configuration by reloading vim and verifying bindings work (README.md)

Update All Plugins to Latest Versions

1. Run update command via CLI dispatcher (bin/yadr/yadr)
2. Calls the dedicated plugin update subcommand (bin/yadr/yadr-update-plugins)
3. Alternatively, use Rake task for comprehensive updates (Rakefile)
4. Commit updated .gitmodules and submodule refs to lock versions (.gitmodules)

• Git Submodules — Manages 90+ vim and zsh plugins as external dependencies with version pinning and easy updates via git pull.
• Rake — Ruby-based task automation provides cross-platform build system for symlink creation, plugin initialization, and system updates.
• Bash Installation Script — Minimal bootstrap entry point (one-liner curl) ensures maximum portability and ease of adoption for new users.
• Git-style Binaries — Provides familiar git-like command dispatch pattern (yadr <command>) for intuitive CLI interface to YADR management tools.
• Vim/Zsh Plugins (Prezto base) — Curated ecosystem of popular plugins, each researched and pre-configured for optimal out-of-box experience.

• Symlink-based configuration instead of package manager

  • Why: Allows direct git version control of all dotfiles and plugins in one repository, enabling easy branching and customization.
  • Consequence: Users must manually run install.sh to symlink files; conflicts may arise if system already has dotfiles in standard locations.

• Git submodules for plugin management instead of plugin managers

  • Why: Provides explicit version control of each plugin's exact commit, preventing unexpected breaking changes from auto-updates.
  • Consequence: Requires explicit rake update command and understanding of git submodule workflow; steeper learning curve than plugin managers.

• All-in-one monolithic repository

  • Why: Single coherent installation point with all plugins pre-tested together; no dependency on external plugin repos staying alive.
  • Consequence: Repository size grows with plugins; users must maintain entire collection even if they only want a subset of features.

• macOS-first, Linux unsupported

  • Why: Optimizes for macOS ecosystem tools (iTerm2, Homebrew) and leverages macOS-specific performance optimizations.
  • Consequence: Linux/Windows users cannot use YADR; fork or alternative setup required.

• Does not support Linux or Windows operating systems
• Does not provide automatic plugin updates—requires explicit rake update command
• Does not handle system-level dependency management beyond vim and zsh
• Does not provide IDE integration or graphical configuration UI
• Does not support plugin architecture for user-authored extensions

1. Rake versioning: Rakefile requires specific Ruby + Rake versions; no Gemfile visible—may need manual gem management. 2. macOS-only: Installation assumes macOS/BSD; Linux users will hit blockers (no Linux support, scripts use macOS-specific tools). 3. Git submodules: Requires git submodule update --init --recursive after clone; easy to forget. 4. Vim plugin conflicts: 90+ plugins bundled; custom mappings may collide—test thoroughly before merging changes. 5. No dependency lockfile: trollop and git-style-binaries embedded as vendored copies, no update mechanism visible—risk of bit-rot. 6. Shell detection: Installation likely assumes zsh availability or install path—may fail on minimal systems.

• Git Submodules — YADR uses git submodules (.gitmodules) to version-pin all vim plugins and prezto; understanding submodule workflows is critical for dependency updates and installation.
• Dotfiles pattern / Bootstrap — YADR exemplifies the dotfiles-as-code pattern where shell configuration, vim plugins, and git hooks are versioned and deployed via a single repo; install.sh is a bootstrap mechanism.
• Vim Plugin Management (Vundle) — YADR bundles 90+ plugins managed by Vundle; understanding how vimrc loads, order of plugin initialization, and mapping conflicts is essential to extending YADR's vim config.
• Zsh Prezto Framework — YADR's zsh setup is built on Prezto modules; understanding module loading, theme selection, and plugin composition helps customize shell behavior without breaking integration.
• Git-style Binaries Pattern — YADR uses git-style-binaries library (bin/yadr/lib/git-style-binaries-0.1.11) to create git-like subcommand CLIs; understanding command dispatch and helpers is key to extending the yadr command.
• Solarized Color Scheme — YADR recommends Solarized colors for iTerm and vim; this is a deliberate design choice affecting terminal appearance and vim color plugin configuration.
• Rake Task Automation — Rakefile is the primary automation interface (install, update, validate); understanding Rake syntax and task dependencies is essential for modifying YADR's orchestration logic.

• holman/dotfiles — Pioneering opinionated dotfiles repo for macOS devs; YADR often cited as evolution/alternative with more vim plugins and prezto integration
• thoughtbot/dotfiles — Thoughtbot's curated dotfiles emphasizing Rails, vim, and git workflows; shares same target audience and philosophy as YADR
• sorin-ionescu/prezto — Base zsh framework that YADR builds on; understanding prezto structure is essential to extending YADR's zsh config
• vim-airline/vim-airline — Popular vim statusline plugin likely bundled in YADR's 90+ plugins; understanding airline config patterns helps customize YADR's vim setup
• junegunn/vim-plug — Modern vim plugin manager (alternative to Vundle which YADR uses); reference for understanding YADR's plugin loading architecture

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions workflow to test bin/yadr commands and plugin installation

The repo has a stale.yml workflow but no CI testing for the core yadr functionality. The bin/yadr directory contains critical installation scripts (yadr-init-plugins, yadr-update-plugins, yadr-vim-add-plugin, yadr-vim-delete-plugin) that lack automated testing. A workflow should validate that these commands execute without errors on fresh environments.

• [ ] Create .github/workflows/test-yadr-install.yml to test bin/yadr/yadr-init-plugins in a clean Docker container
• [ ] Add tests for bin/yadr/yadr-update-plugins to ensure git submodules update correctly
• [ ] Validate bin/yadr/yadr-vim-add-plugin and bin/yadr/yadr-vim-delete-plugin execute without syntax errors using Ruby linting

Create comprehensive installation guide in doc/installation.md with troubleshooting section

The README shows the install command but doc/ only contains credits.md and macos_tools.md. New contributors struggle with setup issues. A detailed installation guide referencing the specific Rakefile tasks, bin/yadr commands, and .yadr directory structure would reduce friction.

• [ ] Document step-by-step installation process referencing Rakefile rake tasks
• [ ] Create troubleshooting section addressing common errors from bin/yadr/yadr-init-plugins and bin/yadr/yadr-update-plugins
• [ ] Add section explaining .yadr directory configuration structure and how it relates to bin/yadr/default_libs.rb

Migrate vendored dependencies (git-style-binaries-0.1.11, trollop-1.16.2) to gems in Gemfile

The bin/yadr/lib/ directory contains complete vendored copies of git-style-binaries and trollop libraries with their own test suites. This creates maintenance burden and makes updates difficult. Moving these to a Gemfile.lock would simplify dependency management and enable automated security updates.

• [ ] Create Gemfile listing git-style-binaries and trollop as dependencies with appropriate versions
• [ ] Update bin/yadr/default_libs.rb to require gems from vendor/bundle instead of bin/yadr/lib/
• [ ] Remove bin/yadr/lib/git-style-binaries-0.1.11 and bin/yadr/lib/trollop-1.16.2 directories and add bundle install step to Rakefile

• Add test coverage for Rakefile targets. Currently no test/ directory visible for Ruby rake tasks. Start: create spec/ directory with rspec tests for rake install, rake update, and rake validate tasks.: medium
• Document plugin list with descriptions. README mentions '90+ vim plugins' but doesn't list them. Start: parse vimrc or submodule file to generate plugins.md with plugin names, versions, and shortcut keys.: small
• Add Gemfile and lock Ruby dependencies. trollop and git-style-binaries are embedded; modernize by extracting to Gemfile with explicit versions. Start: create Gemfile listing trollop, git-style-binaries as gems; update bin/yadr/default_libs.rb to require from gems instead of vendored copies.: medium

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.