brought folder structure and AI prompts together creating a true knowledge vault
This commit is contained in:
parent
3466d987fb
commit
3e3232fe06
14 changed files with 243 additions and 18 deletions
52
Docs_For_AI_Unsorted/vault_prompt.md
Normal file
52
Docs_For_AI_Unsorted/vault_prompt.md
Normal file
|
|
@ -0,0 +1,52 @@
|
||||||
|
# Vault Prompt — When to capture knowledge
|
||||||
|
|
||||||
|
## For Claude: how to handle vault moments
|
||||||
|
|
||||||
|
At the end of any meaningful step or thread, ask:
|
||||||
|
|
||||||
|
> "Should this go into the vault?"
|
||||||
|
|
||||||
|
If yes — or if I say "vault time" — generate a copyable `.md` block in this format:
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## [Topic Title]
|
||||||
|
|
||||||
|
### What we did
|
||||||
|
- (concrete steps taken)
|
||||||
|
|
||||||
|
### Key distinction / Mental model
|
||||||
|
(the core insight in plain language — metaphor welcome)
|
||||||
|
|
||||||
|
### Commands / syntax (if applicable)
|
||||||
|
| Command | What it does |
|
||||||
|
|---|---|
|
||||||
|
| `example` | explanation |
|
||||||
|
|
||||||
|
### When to use this
|
||||||
|
(practical trigger: "do this when…")
|
||||||
|
|
||||||
|
### Index line
|
||||||
|
`filename.md` — one-line summary for index.md
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## When to suggest the vault unprompted
|
||||||
|
|
||||||
|
Suggest "should this go into the vault?" when:
|
||||||
|
- A confusing distinction got clarified (e.g. fetch vs pull)
|
||||||
|
- A hard-won lesson was learned (e.g. don't lock yourself out before testing SSH)
|
||||||
|
- A mental model clicked
|
||||||
|
- A recurring pattern was identified
|
||||||
|
- Something took a long time to debug and has a clean fix
|
||||||
|
|
||||||
|
## When NOT to suggest it
|
||||||
|
- Pure task execution with no new insight
|
||||||
|
- Things already in the vault
|
||||||
|
- Very session-specific decisions with no reuse value
|
||||||
|
|
||||||
|
## Vault file conventions
|
||||||
|
- One topic per file
|
||||||
|
- Structure: What we did → Key insight → Commands → When to use → Index line
|
||||||
|
- Filename: descriptive, lowercase, underscores (`git_basics.md`, `ssh_keys_and_agent.md`)
|
||||||
|
- Always update `index.md` with the index line after creating a new file
|
||||||
47
VAULT/bash_fzf_setup.md
Normal file
47
VAULT/bash_fzf_setup.md
Normal file
|
|
@ -0,0 +1,47 @@
|
||||||
|
# Bash + fzf Setup (Fish-like UX without switching shells)
|
||||||
|
|
||||||
|
## What was done
|
||||||
|
- Decided to stay on Bash instead of switching to Zsh or Fish
|
||||||
|
- Installed `fzf` and `bash-completion` via pacman (EndeavourOS) / apt (Debian VPS)
|
||||||
|
- Added activation block to `~/.bashrc`
|
||||||
|
|
||||||
|
## Key insight
|
||||||
|
You don't need to switch shells to get Fish-like autocomplete and fuzzy history. `fzf` drops straight into Bash with zero compatibility risk — and Bash stays consistent across desktop and VPS.
|
||||||
|
|
||||||
|
## The `.bashrc` block to add
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# bash-completion
|
||||||
|
[[ -r /usr/share/bash-completion/bash_completion ]] && . /usr/share/bash-completion/bash_completion
|
||||||
|
|
||||||
|
# fzf
|
||||||
|
eval "$(fzf --bash)"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Commands
|
||||||
|
|
||||||
|
| What | Command |
|
||||||
|
|------|---------|
|
||||||
|
| Install (Arch/EndeavourOS) | `sudo pacman -S fzf bash-completion` |
|
||||||
|
| Install (Debian/VPS) | `sudo apt install fzf bash-completion` |
|
||||||
|
| Reload config | `source ~/.bashrc` |
|
||||||
|
| Fuzzy history search | `Ctrl+R` |
|
||||||
|
| Fuzzy file search | `Ctrl+T` |
|
||||||
|
| Fuzzy directory jump | `Alt+C` |
|
||||||
|
| Jump to line in nano | `Ctrl+_` then line number |
|
||||||
|
| Toggle line numbers in nano | `Alt+N` |
|
||||||
|
|
||||||
|
## When to use
|
||||||
|
- Any time you set up a new Bash environment (VPS, new machine)
|
||||||
|
- Same config works on Arch and Debian — package manager is the only difference
|
||||||
|
|
||||||
|
## Fixing a corrupted `.bashrc`
|
||||||
|
If a paste goes wrong and injects garbage into `.bashrc`:
|
||||||
|
1. `cat -n ~/.bashrc` to find the broken lines
|
||||||
|
2. `nano ~/.bashrc` → `Ctrl+_` to jump to line number, `Ctrl+W` to search
|
||||||
|
3. Remove the injected string carefully, leaving the rest of the line intact
|
||||||
|
4. Watch for `esac` keywords — they're easy to corrupt and hard to spot
|
||||||
|
5. `source ~/.bashrc` to verify the fix
|
||||||
|
|
||||||
|
## Index line
|
||||||
|
`bash_fzf_setup.md` — Bash fuzzy search setup; fzf + bash-completion; fixing corrupted .bashrc
|
||||||
43
VAULT/git_basics.md
Normal file
43
VAULT/git_basics.md
Normal file
|
|
@ -0,0 +1,43 @@
|
||||||
|
# Git Basics
|
||||||
|
|
||||||
|
## git push — remote vs branch syntax
|
||||||
|
|
||||||
|
**Problem:** `git push -u main` throws:
|
||||||
|
fatal: 'main' does not appear to be a git repository
|
||||||
|
fatal: Could not read from remote repository.
|
||||||
|
|
||||||
|
**Diagnosis:** Git expected a remote name but got a branch name.
|
||||||
|
|
||||||
|
**Fix:**
|
||||||
|
git push -u origin main
|
||||||
|
|
||||||
|
**Key insight:** The syntax is always remote first, branch second.
|
||||||
|
`origin` = where to push (the remote repository)
|
||||||
|
`main` = which branch to push
|
||||||
|
`-u` = sets origin/main as the default tracking branch,
|
||||||
|
so future pushes only need `git push`
|
||||||
|
|
||||||
|
## Git Basics — Vault Sync Workflow
|
||||||
|
|
||||||
|
### What we set up
|
||||||
|
- Vault folder (`05_vault`) initialised as a Git repo on the desktop
|
||||||
|
- Remote added: `git@git.bujour.de:patsy/Vault.git` (Forgejo, port 2222)
|
||||||
|
- Pushed from desktop → Forgejo → pulled onto laptop
|
||||||
|
- Desktop clone deleted and re-cloned fresh from Forgejo (clean slate)
|
||||||
|
|
||||||
|
### Day-to-day rhythm
|
||||||
|
- **Before starting:** `git pull origin main` — get what's on the remote
|
||||||
|
- **After changes:** `git add .` → `git commit -m "message"` → `git push origin main`
|
||||||
|
|
||||||
|
### Key distinction
|
||||||
|
| Command | What it does |
|
||||||
|
|---|---|
|
||||||
|
| `git fetch` | Downloads new commits from remote — does NOT touch your files |
|
||||||
|
| `git pull` | fetch + applies changes to your working files |
|
||||||
|
|
||||||
|
### Mental model
|
||||||
|
The remote (Forgejo) is the ocean. You push water out, you pull water back in.
|
||||||
|
One branch, working alone → pull before you start, push when you're done.
|
||||||
|
|
||||||
|
### Index line
|
||||||
|
`git_basics.md` — day-to-day sync rhythm, fetch vs pull distinction
|
||||||
|
|
@ -6,3 +6,4 @@
|
||||||
- [ssh_keys_and_agent](ssh_keys_and_agent.md) - SSH keypair setup, config, agent, Forgejo auth
|
- [ssh_keys_and_agent](ssh_keys_and_agent.md) - SSH keypair setup, config, agent, Forgejo auth
|
||||||
- [VS Code Tips and Guide](VS_code_tips.md)
|
- [VS Code Tips and Guide](VS_code_tips.md)
|
||||||
- [git_basics](git_basics.md) — git push syntax, remote vs branch
|
- [git_basics](git_basics.md) — git push syntax, remote vs branch
|
||||||
|
- [Bash Basics -fsf - Fishlike use](bash_fzf_setup.md)
|
||||||
14
git_basics.html
Normal file
14
git_basics.html
Normal file
|
|
@ -0,0 +1,14 @@
|
||||||
|
<h1 id="git-basics">Git Basics</h1>
|
||||||
|
<h2 id="git-push-remote-vs-branch-syntax">git push — remote vs branch
|
||||||
|
syntax</h2>
|
||||||
|
<p><strong>Problem:</strong> <code>git push -u main</code> throws:
|
||||||
|
fatal: ‘main’ does not appear to be a git repository fatal: Could not
|
||||||
|
read from remote repository.</p>
|
||||||
|
<p><strong>Diagnosis:</strong> Git expected a remote name but got a
|
||||||
|
branch name.</p>
|
||||||
|
<p><strong>Fix:</strong> git push -u origin main</p>
|
||||||
|
<p><strong>Key insight:</strong> The syntax is always remote first,
|
||||||
|
branch second. <code>origin</code> = where to push (the remote
|
||||||
|
repository) <code>main</code> = which branch to push <code>-u</code> =
|
||||||
|
sets origin/main as the default tracking branch, so future pushes only
|
||||||
|
need <code>git push</code></p>
|
||||||
|
|
@ -1,18 +0,0 @@
|
||||||
# Git Basics
|
|
||||||
|
|
||||||
## git push — remote vs branch syntax
|
|
||||||
|
|
||||||
**Problem:** `git push -u main` throws:
|
|
||||||
fatal: 'main' does not appear to be a git repository
|
|
||||||
fatal: Could not read from remote repository.
|
|
||||||
|
|
||||||
**Diagnosis:** Git expected a remote name but got a branch name.
|
|
||||||
|
|
||||||
**Fix:**
|
|
||||||
git push -u origin main
|
|
||||||
|
|
||||||
**Key insight:** The syntax is always remote first, branch second.
|
|
||||||
`origin` = where to push (the remote repository)
|
|
||||||
`main` = which branch to push
|
|
||||||
`-u` = sets origin/main as the default tracking branch,
|
|
||||||
so future pushes only need `git push`
|
|
||||||
85
git_basics_styled.html
Normal file
85
git_basics_styled.html
Normal file
File diff suppressed because one or more lines are too long
0
styling.cs
Normal file
0
styling.cs
Normal file
1
styling.css
Normal file
1
styling.css
Normal file
File diff suppressed because one or more lines are too long
0
syling.css
Normal file
0
syling.css
Normal file
Loading…
Add table
Reference in a new issue