dotfiles-strategy

Apply STRATEGY.md rules before recommending dotfiles setup changes.

Updated Mar 22, 2018
One-click install
npx skills add https://github.com/tnunamak/dotfiles --skill dotfiles-strategy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dotfiles-strategy
Source: https://github.com/tnunamak/dotfiles/tree/main/.agents/skills/dotfiles-strategy
Command: npx skills add https://github.com/tnunamak/dotfiles --skill dotfiles-strategy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents inconsistent or risky changes by ensuring any proposed modification to the dotfiles setup process is grounded in the repo’s established strategy and decision rationale.

Core Features & Use Cases

  • Source-of-truth alignment: Forces reviewers and agents to consult STRATEGY.md before touching setup flow, installation logic, or package/stow decisions.
  • One-mechanism-per-concern governance: Helps keep responsibilities separated (e.g., when symlinking vs when using external tools) so future changes don’t create conflicting behaviors.
  • Multi-agent parity for AI tooling: Guides safe updates around MCP/skill management and installer choices so different agents propose compatible changes.

Quick Start

Ask an AI to propose a change to setup.sh or sync-mcps.sh while first summarizing the relevant rules from STRATEGY.md and explaining how the proposal follows them.

Frequently Asked Questions about dotfiles-strategy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I keep dotfiles setup changes consistent across multiple agents?

To keep dotfiles changes consistent across multiple agents, load the repository's strategy rules from STRATEGY.md first. This ensures all modifications to setup scripts and MCP management follow the same source-of-truth and separation of concerns.

What is the best way to govern stow packaging updates in a dotfiles repository?

The best way to govern stow packaging updates is to apply one-mechanism-per-concern rules from the repository's strategy document. This prevents conflicting behaviors by keeping symlinking and external tool responsibilities strictly separated.

How do I safely modify setup.sh without breaking the bootstrap flow?

To safely modify setup.sh without breaking the bootstrap flow, review the repository's strategy rules first. Grounding your proposed changes in the established decision rationale prevents risky or inconsistent updates to the installation logic.

When do I need to check STRATEGY.md before editing sync-mcps.sh?

You need to check STRATEGY.md before editing sync-mcps.sh whenever you propose changes to MCP management. Consulting this source-of-truth document ensures your updates maintain multi-agent parity and align with the core installation strategy.

Why does updating ai/mcp-servers.json require reading the repository strategy first?

Updating ai/mcp-servers.json requires reading the repository strategy first because it enforces multi-agent parity. This ensures any changes to MCP or skill management remain compatible with the established installer choices and tradeoff consistency.

Can I use this strategy governance for modifying ai/skills/ configurations?

Yes, you can use this strategy governance for modifying ai/skills/ configurations. It guides safe updates around skill management by ensuring proposals remain compatible with the repository's established source-of-truth and separation of concerns.