Files and directories without fear
A file manager shows a tree. A terminal lets you describe changes to that tree. The safest rhythm is simple: inspect → change → inspect again.
Think in a tree, not in windows
A project is just a tree of directories and files. The terminal does not remove that visual model; it gives you shorter verbs for changing it.
The useful habit is to name paths explicitly. project/notes/ideas.txt tells you both what the file is and where it belongs. Clear paths make commands readable months later and make scripts portable.
Build a tiny project from an empty directory
Create a project with separate places for assets, configuration and notes. Nothing here is special to lil-terminal; this is the same organizational thinking you use in any filesystem.
After creating the structure, ask
cd lil-playgroundmd project | md project/assets | md project/config | md project/notesmf project/notes/ideas.txt | mf project/config/app.inidir 3 project -G -aInspect before you change
This is a stronger habit than memorizing a safety flag. The terminal cannot know that two similarly named directories mean different things to you; inspection is how you add that context.
stat project/notes/ideas.txtdir 2 project -G -aCopy, move and rename are three different intentions
Run each operation on the practice files and inspect the tree afterward. A command is easier to trust when you can predict the tree before pressing Enter.
copy project/notes/ideas.txt project/notes/ideas.copy.txtren project/notes/ideas.copy.txt ideas-archive.txtmd project/archivemov project/notes/ideas-archive.txt project/archiveSearch the project instead of opening folders one by one
Start with narrow searches. Search filenames in project, then text inside the same small tree. Later the same pattern scales to a much larger codebase.
find ideas -f -p projectfind app -f -e ini -p project/configfind archive -F -p projectDeletion deserves its own ritual
Deletion is the operation where speed is least important. Build a disposable project/tmp, inspect it, and only then remove it recursively. Never copy a destructive example into a real project without replacing the path consciously.
The useful rule is: the shorter the command, the more carefully you should verify its target. A terminal makes destructive actions fast, so your process has to make the target obvious.
md project/tmp | mf project/tmp/throw-away.txtdir 2 project/tmp -G -adel project/tmp -rA project skeleton is already automation
If you repeatedly start projects with the same directories, stop rebuilding the structure by hand. Save the verified sequence as a .lil file. The script becomes a portable project skeleton.
Later you can extend it with configuration, archives, uploads, checks and installation commands. The important part is that the script grows from actions you already tested rather than from a giant opaque recipe.
Keep this as a script
Save this as project-skeleton.lil. It creates a small predictable structure. When you start another project, copy the script, change the names that are genuinely project-specific, and keep the rest.
#lil
@install md mf dir stat copy ren mov find
cd lil-playground
md project
md project/assets
md project/config
md project/notes
mf project/notes/ideas.txt
dir 3 project -G -a