skills/tmuxinator/SKILL.md
Use when setting up tmuxinator for a project, creating a new tmuxinator config, or when a project needs a terminal workspace layout.
npx skillsauth add LandonSchropp/agent-toolkit skills/tmuxinatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Create a tmuxinator config file at ~/.config/tmuxinator/<name>.yml.
Detect project name. Infer the name from the current conversation context (project directory, repo name, etc.). Present it to the user for confirmation before proceeding. The name usually matches the directory name but not always.
Check for existing config. If ~/.config/tmuxinator/<name>.yml already exists, show the user its contents and ask whether to overwrite or pick a different name. Do NOT silently overwrite.
Determine windows. Start with the default windows from ~/.config/tmuxinator/default.yml. If the project would clearly benefit from additional windows (e.g., a dev server), suggest them to the user. Do not add extra windows without asking.
Write the config. Read ~/.config/tmuxinator/default.yml as the base template. Add a root field with the project path (using ~ for home) and set the name field. Add any extra windows the user confirmed. Write the file to ~/.config/tmuxinator/<name>.yml.
| Thought | Reality | | ------------------------------------------------ | ---------------------------------------------------------------------- | | "I'll just write it without confirming the name" | The name matters. Always confirm with the user first. | | "I'll skip checking for existing configs" | Overwriting a config silently destroys the user's setup. Always check. | | "I'll add extra windows since they seem useful" | Ask first. The user's defaults exist for a reason. |
tools
Use when a finished, reviewed branch is committed and needs to be merged into the default branch in a repo that integrates directly to `main` (not via pull request).
tools
Use when working with a stack of GitHub pull requests — creating branches, keeping the stack in sync, or merging in order. Covers Git Town setup, PR targeting, rebasing, and landing the stack.
tools
Use when writing or modifying tests in a Bun project
tools
Use when publishing or releasing a new version of an npm/pnpm/yarn/bun package to the registry. Covers package-manager detection, semver bump selection, tagging, pushing, scoped-package access, authentication, and one-time passwords (OTP).