Portable preferences and configuration for the tools I use across machines, designed to be read and maintained by an LLM.
This repository is a systematic description of my preferred setup, not a machine image, bootstrap framework, universal symlink target, or set of named-machine profiles. The normal operator has shell access and authenticated GitHub CLI access and adapts requested preferences to the current machine.
Each tracked top-level directory is a requestable capsule. Its README identifies tracked material as complete canonical configuration, a fragment for an application-owned file, a durable local-setup note, or guidance for a target project's configuration or instruction files.
Applying a preference changes the target machine; recording one changes this repository; comparing changes neither unless the user then asks. Do only the requested direction or directions.
Read the requested capsule before acting, inspect existing destinations before writing, and preserve unrelated configuration and local state. Apply material according to the ownership method its capsule declares. Never replace an aggregate application configuration with a fragment.
Adapt the implementation to the current operating system, installed versions, and available tools while preserving the preference instead of selecting a named machine profile. An apply request authorizes ordinary in-scope local changes; privilege escalation or broader system changes require separate authorization.
Inspect the relevant live setting and promote only its deliberately public, portable, preference-bearing part. Never import a complete live configuration file or directory merely to capture one setting. Update the owning application or cross-application capsule, creating a new capsule only when none fits.
Use concise prose when the preference matters but an LLM can reliably derive the implementation from it. Track exact configuration or a fragment when syntax or values materially encode the preference, and identify it as complete or mergeable. When an application-owned file may contain local state, track only a safe fragment or durable note. Record non-obvious ownership and application boundaries. Record reusable project-level preferences as guidance in the relevant capsule. When applying that guidance, update the target project's existing configuration or instruction files rather than treating capsule text as ambient policy.
Preserve existing exact preferences and unrelated capsules. A scoped request does not authorize repository-wide normalization, reorganization, pruning, or changes to this README, AGENTS.md, or the operating model. Change repository policy only when the user explicitly requests it.
Treat everything tracked as public. Keep credentials, private or employer data, non-public account details, private paths, machine-specific values or inventories, and runtime or generated state outside the checkout. Public, portable destination paths, links, and preference-bearing values may be tracked.
LLM administration is the interface to this repository, not its subject matter. Do not add generic personas, skills, cross-client agent rules, instruction templates, or additional repository-wide instruction files. Capsule-specific guidance must remain scoped to its preferences.
Do not add machinery whose purpose is managing this repository, such as installers, bootstrap or capture systems, generators, hooks, scanners, checkers, CI, archives, or repository-management manifests and schemas. Use the LLM and available machine tools directly. Helpers consumed by an application remain valid capsule content.
Authenticated GitHub access is a capability, not standing authorization for unrelated external changes. When the user asks to record, add, or sync a preference in the remote repository, a reviewed commit and ordinary push are normal completion. Other remote administration or published-history changes require explicit authorization. If sensitive material appears in candidate repository content, keep it out and report it; if it is already tracked, stop before committing, pushing, or changing history and report it.
Before committing, inspect the complete status, intended diff and files, and effective author identity. Stage only the intended changes and preserve unrelated worktree changes. Before pushing, confirm the intended remote and branch. Validate changed configuration with the tool that consumes it when practical.
Keep documentation short and operational. Markdown is soft-wrapped: one source line per paragraph or list item, without hard wrapping to a column width.