bashr

name	bashr
description	user's bash environment is a decades-long living system of ultra-short custom commands. Use this skill before suggesting or interpreting any shell commands in this workspace. Trigger whenever you see unfamiliar short commands (gs, gi, vv, rlf, fdj, ...), before composing shell commands for user to run, or when user asks about his shell setup.

bashr — user's Shell Vocabulary

Assume Incompleteness — Always

The most-used command in user's shell may not exist yet. His bash environment is a living system that grows continuously. Never treat any list of commands as complete. When in doubt, ask. When something looks unfamiliar, look it up rather than guessing.

Where the Files Live

We're talking about the https://github.com/jalanb/bashrc.git project Cloned locally as

• /opt/clones/github/jalanb/bashrcs/alan
• /opt/clones/github/jalanb/bashrcs/jab
• /opt/clones/github/jalanb/bashrcs/jabs
• /opt/clones/github/jalanb/bashrcs/smbc

User has the username "jab" on this machine, so this is the important one:

• /opt/clones/github/jalanb/bashrcs/jab

Most of the bash scripts are in

• /opt/clones/github/jalanb/bashrcs/jab/src/bash

But /opt/clones/github/jalanb/bashrcs/jab/**/*.sh should be considered as part of this project

Where the files are linked

Many of the important paths in the collection are linked from $HOME, because they are used daily. For example:

 $ ls -l ~ | grep '[-][>] ' | .....
jab         ->  jalanb/bashrcs/jab
bash        ->  jab/src/bash
prompt.sh   ->  bash/prompt.sh
keys        ->  bash/keyboard/
git.sh      ->  bash/git/functons.sh

Where the Vocabulary Lives

All short commands come from one of two places:

1. Keyboard files — ~/keys/ (symlink to ~/bash/keyboard/) One file per letter: g.sh, v.sh, l.sh, etc. Each file defines functions with very short (typist friendly) names: l, vv, rlf, 'cd', 'grr', ...

2. Git functions — ~/bash/git/functons.sh All g* git wrappers live here: gi, ga, gs, gl, gc, gp, gsi, etc.

Supporting architecture: ~/bash/functons.sh (1500+ general utilities), ~/bash/CLAUDE.md and ~/bash/keyboard/CLAUDE.md for orientation.

How to Learn the Current State

When you need to understand user's vocabulary for a task:

1. Check what changed recently

   gc ~/bash l
   gc ~/keys l
   

   This shows recent commits — new commands often appear without announcement.

2. Read the relevant keyboard file If the task involves files: read ~/keys/f.sh If it involves git: read ~/bash/git/functons.sh If it involves vim: read ~/keys/v.sh Read only what's relevant — don't bulk-read everything.

3. Use whyp to look up unknowns w <cmd> (user's alias for whyp) shows where a function is defined and its source. When you see an unfamiliar command in history or conversation, this is the right tool.

4. Ask user about the "why" The source code shows what a function does. The why — the workflow it fits into, the problem it solves — is often still in user's head. Ask when it matters.

How Updates Happen

User's shell vocabulary is monitored by an inotify watcher on ~/bash. When files change, the skill's knowledge should update — this is not a one-time snapshot. Treat any cached knowledge of specific commands as potentially stale.

Protocol Before Suggesting Shell Commands

1. Use the short form if you know it — gi "msg" not git commit -m "msg"
2. If unsure whether a short form exists, say so — don't invent one
3. Never run commands in user's shell without being asked — compose and show first
4. If you see a command in conversation you don't recognise, look it up with w <cmd> before assuming it's a typo or asking user to explain it

Known Vocabulary (Snapshot — May Be Stale)

A starting point only. Verify before relying on any of these.

Git (~/bash/git/functons.sh)

• gi "msg" — commit with message; gi alone opens editor
• ga <files> — git add with validation
• gaa — git add all
• gs — git status
• gl / gll / glll — git log (4 / more / most entries)
• gc <dir> <cmd> — git -C: run git command in another directory
• go <branch> — safe checkout; gob — create branch
• gp / gpf — push with auto upstream handling
• grr — git pull --rebase
• gff / gfff — fetch + pull + status
• gsi — interactive status (add/restore/edit file by file)
• gb — branch list with optional grep
• tig — git log browser

Files & Navigation (~/keys/)

• l / ll / la / lsr — ls variants
• fd <pat> / fdj <pat> — find files; fdj scopes to jalanb root
• rlf <path> — resolve symlinks to real path
• cdj — cd to jalanb root (/opt/clones/github/jalanb)
• mkcd <dir> — mkdir + cd
• rr <path> — rm -rf

Editing

• v — MacVim (remote tabs); vv — terminal vim; vvv — open ~/.vimrc
• bat <file> — cat with syntax highlighting
• r <file> — view a file

Search

• ack <pat> — search file contents; -i case-insensitive; -l files only
• w <cmd> — whyp: show where a function/alias/binary is defined

Diff

• icdiff — side-by-side diff (GNU tools — not macOS defaults)

Misc

• pbcopy — pipe to clipboard
• clone <url> — enhanced git clone (sets user config)
• .k — reload keyboard shortcuts

Important: GNU Tools

User uses GNU versions of standard tools, not macOS defaults. sed -i -e works. sed -i '' is not needed. Don't suggest macOS-specific flags.