Before you give a command a short name, you need to know what it really does. SeedSpindle runs the lookup in your Linux shell through WSL or SSH, shows the manual text in a chat card, and then proposes the alias as a diff. You review both. The lookup comes first, so the alias is based on what the manual says and not on memory. Each step below is a card in the chat, and the working folder holds the aliases file, its backup and any notes you ask the agent to write. Nothing runs outside the environment you picked. When you finish, the aliases file, the backup and the cards of the session give you a complete record of what changed, which you can read again whenever the shell behaves oddly. Beginners often skip the lookup and paste a line from a forum, so this workflow turns the lookup into the first card of every task.
Choose the working folder and the WSL or SSH environment for your shell, so the file tools and Shell point at the same machine. Pick the folder that holds your dotfiles or a copy of them. The file tools work only in that folder, while Shell runs in the environment you chose. Open it once and the choice carries over to the next task.
Name the command you want to understand before you give it a short name, and ask the agent to run the matching help or manual command. Quote the exact name. For a built-in, ask for the help text, and for an ordinary program, ask for its manual page. Say which shell the command belongs to if you use more than one.
Read the proposed alias line and accept it only if it fits your habits and does not hide what the command really does. Reject anything that looks like a shortcut for something destructive. The diff marks added lines in green and removed lines in red, so one glance shows the size of the change.
Shell loads the file and shows the real exit code in a card, and the next alias command shows whether the new name is known. If the name is unknown, the card shows the error and you ask for a fix. Run each new name once in a fresh terminal.
man dfexit 0~/.bash_aliasesloaded~/.bash_aliases+1 linesource ~/.bash_aliasesexit 0alias dfhexit 0# Read-only shortcuts for looking around
alias ll='ls -la'
alias la='ls -A'
alias l='ls -CF'
# Disk usage in readable units
alias dfh='df -h'
alias duh='du -sh'
# Show the last commands you typed
alias hist='history 20'Every alias here only reads: ls lists files, df and du report disk space, and history prints recent commands. Comment lines start with # and explain each group, so you remember later why the lines exist. Keep one blank line between groups, and keep each line short enough to read in a diff without scrolling sideways. Add your own group below the last one, and let the agent show the diff before you save it. Short names are easier to type, but keep them different from real commands so nothing is shadowed by accident. Review every new line before you save it.
Task: learn what a bash built-in does before you alias it. A linux help command such as help cd prints the documentation of a built-in, and the agent runs it through Shell so the text appears in a chat card you can expand. You read the options, decide which ones belong in the alias, and then ask for the line. Be precise. edit_file proposes the alias as a diff, and the alias must never hide what the command really does. A wrong guess costs little, because the backup is one copy_file call away. Ask first pauses before the write, so you accept the diff, run source on the file, and confirm the exit code in the next card.
Task: find a command when you only remember what it does. Running apropos with a keyword searches the short descriptions of manual pages, and the agent shows the list in a card. Typing apropos linux would return a very long list, while a narrower word such as disk finds fewer, better matches. A shell history knowing the project of each command needs extra setup beyond aliases, and the agent can draft those bashrc lines as a diff if you ask. Pick one. Read the manual page with man, then ask for the alias, and review the diff before accepting it.
Task: change a dotfile without breaking your next login. Debugging a path issue with dotfiles starts with reading the file that sets PATH, and the agent does that with read_file and grep, which shows every matching line. It then uses copy_file to save the original and edit_file to propose the fix as a diff. Keep the copy. Many path problems come from a typo, so the diff often needs only one changed line, and a restore is a single copy_file call if the new setup fails. Plan only lets you read the whole plan before a file changes, and the final check is a new shell where you confirm that the command is found.
Task: confirm that the alias loads. After you accept the diff, the agent runs source on the file through Shell and reports the real exit code in the card, where a zero code means the file loaded without an error. Live updates in a shell prompt also depend on this step, because the current shell only sees a changed file after it is loaded again. Run the alias. The agent types the new name, shows the output, and you compare it with the command you expected. If the exit code is not zero, you read the error in the expanded card and ask for a fix, then open a second terminal and try the alias there too.
