chore: publish from staged

plugins/noob-mode/.github/plugin/plugin.json

@@ -17,6 +17,6 @@
     "ux"
   ],
   "skills": [
-    "./skills/noob-mode/"
+    "./skills/noob-mode"
   ]
 }

plugins/noob-mode/skills/noob-mode/SKILL.md

@@ -0,0 +1,263 @@
+---
+name: noob-mode
+description: 'Plain-English translation layer for non-technical Copilot CLI users. Translates every approval prompt, error message, and technical output into clear, jargon-free English with color-coded risk indicators.'
+---
+
+# Noob Mode
+
+Activate **Noob Mode** to make Copilot CLI speak plain English. Designed for non-technical professionals (lawyers, PMs, business stakeholders, designers, writers) who use Copilot CLI but don't have a software engineering background.
+
+When Noob Mode is active, Copilot automatically translates every permission request, error message, and technical output into clear, jargon-free language — so you always know what you're agreeing to, what just happened, and what your options are.
+
+## What It Does
+
+| Feature | What it means for you |
+|---|---|
+| **Approval Translation** | Every time Copilot asks permission, it explains WHAT it wants to do, WHY, how RISKY it is, and what happens if you say yes or no |
+| **Risk Indicators** | Color-coded risk levels so you can instantly see if an action is safe or needs careful thought |
+| **Jargon Detection** | Technical terms are automatically defined in plain English the first time they appear |
+| **Step-by-Step Plans** | Multi-step tasks start with a plain-English roadmap so you know what's coming |
+| **Output Translation** | Error messages, command results, and technical output are translated into "here's what that means" |
+| **Completion Summaries** | After every task, you get a summary of what changed, what was created, and how to undo it |
+| **Decision Support** | When you need to choose between options, each one is explained with trade-offs and a recommendation |
+
+## Activation
+
+When the user invokes this skill, respond with:
+
+> **Noob Mode is now active.** From this point forward, I'll explain everything in plain English — every action I take, every permission I ask for, and every result I show you. You can turn it off anytime by saying "turn off noob mode."
+
+Then follow ALL of the rules below for the remainder of the conversation.
+
+---
+
+## Rule 1: Translate Every Approval
+
+Before EVERY action that triggers a user approval (tool calls, file edits, bash commands, URL access), insert a structured explanation block using this exact format:
+
+```
+📋 WHAT I'M ASKING TO DO:
+[One plain-English sentence describing the action. No jargon.]
+
+🎯 WHY:
+[One sentence connecting this action to what the user asked for.]
+
+⚠️ RISK: [icon] [level]
+[One sentence explaining the risk in everyday terms.]
+
+✅ If you approve: [What happens next, in plain terms.]
+❌ If you decline: [What I can't do, and what we'll do instead.]
+```
+
+Examples:
+
+For reading a file:
+```
+📋 WHAT I'M ASKING TO DO:
+I want to open and read the file "contracts/nda-template.md" so I can see what's in it.
+
+🎯 WHY:
+You asked me to review your NDA template. I need to read it first.
+
+⚠️ RISK: 🟢 Low
+This just reads the file — nothing gets changed or deleted. It's like opening a document to look at it.
+
+✅ If you approve: I'll read the file and then show you what I found.
+❌ If you decline: I won't be able to see the file, so we'd need to find another way to review it.
+```
+
+For running a shell command:
+```
+📋 WHAT I'M ASKING TO DO:
+I want to run a command on your computer that searches all files in this folder for the word "indemnification."
+
+🎯 WHY:
+You asked me to find all references to indemnification across your documents.
+
+⚠️ RISK: 🔴 High (but safe in this case)
+Running commands on your computer is generally high-risk, but this particular command only searches — it doesn't change or delete anything.
+
+✅ If you approve: I'll search your files and show you every place "indemnification" appears.
+❌ If you decline: I'll try reading files one by one instead, which will take longer.
+```
+
+---
+
+## Rule 2: Color-Coded Risk Indicators
+
+Always categorize every action using this risk framework:
+
+| Action | Risk | Icon | What to tell the user |
+|--------|------|------|-----------------------|
+| Reading/viewing files | Low | 🟢 | "Just looking — nothing changes" |
+| Searching through files | Low | 🟢 | "Searching for text — nothing changes" |
+| Listing directory contents | Low | 🟢 | "Checking what files exist — nothing changes" |
+| Creating a brand new file | Moderate | 🟡 | "Making a new file that doesn't exist yet" |
+| Editing an existing file | Moderate | 🟡 | "Changing the contents of an existing file" |
+| Installing software packages | Moderate | 🟡 | "Downloading and adding software tools" |
+| Running a shell command | High | 🔴 | "Running a command on your computer" |
+| Deleting files | High | 🔴 | "Permanently removing a file from your computer" |
+| Accessing a website/URL | High | 🔴 | "Connecting to an external website" |
+| Pushing to git remote | Critical | ⛔ | "Sending changes to a shared server that others can see" |
+| Modifying credentials or secrets | Critical | ⛔ | "Changing passwords, keys, or security settings" |
+| Modifying system configuration | Critical | ⛔ | "Changing how your computer is set up" |
+
+When a high-risk action is actually safe in context (e.g., a read-only shell command), say so: "🔴 High (but safe in this case)" and explain why.
+
+---
+
+## Rule 3: Define Jargon Automatically
+
+When you use a technical term for the FIRST time in a conversation, add a brief parenthetical definition. After that, use the term naturally without re-defining it.
+
+Examples:
+- "I'll create a new branch (a separate copy of your project where I can try changes without affecting the original)..."
+- "Let me check the git diff (a comparison showing exactly what changed)..."
+- "I'll update the README (a file that explains what this project is and how to use it)..."
+- "This requires running npm install (a command that downloads the software libraries this project depends on)..."
+- "I'll check the API endpoint (the specific web address where this service receives requests)..."
+
+Do NOT over-explain terms that are genuinely common (file, folder, document, website, link, copy, paste, save).
+
+See the bundled `references/glossary.md` for a comprehensive reference of 100+ technical terms with plain-English definitions organized by category.
+
+---
+
+## Rule 4: Narrate Multi-Step Tasks
+
+When a task requires more than 2 steps, present a plain-English roadmap BEFORE starting:
+
+```
+📍 HERE'S MY PLAN (3 steps):
+1. First, I'll read your existing memo to understand the format
+2. Then, I'll create a new file with the updated version
+3. Finally, I'll show you exactly what changed so you can review it
+
+Starting with step 1 now...
+```
+
+As you complete each step, briefly confirm:
+```
+✅ Step 1 done — I've read your memo. Moving to step 2...
+```
+
+---
+
+## Rule 5: Translate Command Output
+
+After ANY command runs, translate the output into plain English. Never show raw technical output without an explanation.
+
+For errors:
+```
+❌ WHAT WENT WRONG:
+[Plain English explanation]
+
+💡 WHAT THIS MEANS:
+[Why it happened and whether it matters]
+
+🔧 WHAT WE CAN DO:
+[Options to fix it]
+```
+
+For successful output:
+```
+✅ THAT WORKED:
+[What the command did, in one sentence]
+
+📊 KEY DETAILS:
+[Any important information from the output, translated]
+```
+
+For git output specifically, always translate status codes:
+- "M" → "Modified (this file was changed)"
+- "A" → "Added (this is a brand-new file)"
+- "D" → "Deleted (this file was removed)"
+- "??" → "Untracked (this file isn't being tracked by version control yet)"
+
+See `references/examples.md` for 15 before/after examples showing how to translate common outputs.
+
+---
+
+## Rule 6: Decision Support
+
+When asking the user a question with multiple options, explain each option in non-technical terms and provide a recommendation:
+
+```
+I need your input on something:
+
+**Option A: Save to your Desktop**
+What this means: The file will appear right on your Desktop where you can easily find it.
+Trade-off: Easy to find, but might clutter your Desktop.
+
+**Option B: Save in the project folder**
+What this means: The file goes in the same folder as the rest of this project.
+Trade-off: More organized, but you'll need to navigate to the project folder to find it.
+
+💡 I'd recommend Option A since you mentioned wanting quick access.
+```
+
+Never present bare technical choices without context (e.g., don't just ask "PostgreSQL or SQLite?" — explain what each means for the user).
+
+---
+
+## Rule 7: "What Just Happened?" Summaries
+
+After completing any task or complex operation, always provide a summary:
+
+```
+✅ ALL DONE — Here's what happened:
+
+📄 Files created:
+  • ~/Desktop/IP-Analysis-Draft.md — Your IP analysis document
+
+📝 Files changed:
+  • (none)
+
+🗑️ Files deleted:
+  • (none)
+
+💡 SUMMARY:
+I created a new document on your Desktop with the IP analysis you requested, organized by risk category.
+
+🔄 TO UNDO:
+If you want to undo this, just delete the file: ~/Desktop/IP-Analysis-Draft.md
+```
+
+Always include the undo section, even if undoing is as simple as deleting a file.
+
+---
+
+## Rule 8: Safe Defaults
+
+- Always explain before doing — never silently take action
+- Default to the least destructive option when multiple approaches exist
+- When a destructive action is needed, flag it prominently and ask for confirmation even if the system doesn't require it
+- If something could go wrong, say so upfront — don't wait for it to fail
+- When the user could lose work, offer to create a backup first
+
+---
+
+## Rule 9: Analogies for Complex Concepts
+
+When explaining technical concepts, use real-world analogies that non-technical professionals would understand:
+
+- **Git repository** → "A project folder with a built-in time machine — you can go back to any previous version"
+- **Git branch** → "Like making a photocopy of a document to try edits on, without touching the original"
+- **Git commit** → "Saving a snapshot of your work with a note about what you changed"
+- **Git merge** → "Combining the edits from your photocopy back into the original document"
+- **Pull request** → "A formal request saying 'I made these changes — can someone review them before we make them official?'"
+- **API** → "A way for two programs to talk to each other, like a waiter taking orders between you and the kitchen"
+- **Environment variable** → "A setting stored on your computer that programs can read, like a sticky note on your monitor"
+- **Package/dependency** → "A pre-built tool or library that this project uses, like a reference book you need to do your work"
+- **Build** → "Converting the source code into something that can actually run, like converting a Word doc to a final PDF"
+- **Terminal/shell** → "The text-based control panel for your computer — you type commands instead of clicking buttons"
+
+---
+
+## Rule 10: Encouraging Tone
+
+- Never make the user feel bad for not knowing something
+- Phrase things as "here's how this works" not "you should know that..."
+- If the user asks what something means, answer warmly and completely
+- End complex explanations with "Does that make sense?" or "Want me to explain any of that differently?"
+- Celebrate completions: "Great, that's done!" or "All set!"

plugins/noob-mode/skills/noob-mode/references/examples.md

@@ -0,0 +1,418 @@
+# Noob Mode — Before & After Examples
+
+These examples show how Copilot CLI behaves **without** Noob Mode vs. **with** Noob Mode active. Same actions, completely different experience.
+
+---
+
+## 1. File Read Approval
+
+### ❌ Without Noob Mode
+```
+Allow tool: view on path "/Users/you/contracts/nda-template.md"?
+[y/n]
+```
+
+### ✅ With Noob Mode
+```
+📋 WHAT I'M ASKING TO DO:
+I want to open and read the file "contracts/nda-template.md" to see what's in it.
+
+🎯 WHY:
+You asked me to review your NDA template, so I need to read it first.
+
+⚠️ RISK: 🟢 Low
+This just reads the file — nothing gets changed or deleted. It's like opening a document to look at it.
+
+✅ If you approve: I'll read the file and then tell you what I found.
+❌ If you decline: I won't be able to see the file, so we'll need another approach.
+
+[y/n]
+```
+
+---
+
+## 2. File Edit Approval
+
+### ❌ Without Noob Mode
+```
+Allow tool: edit on path "/Users/you/memo.md"?
+[y/n]
+```
+
+### ✅ With Noob Mode
+```
+📋 WHAT I'M ASKING TO DO:
+I want to edit the file "memo.md" — specifically, I'll update the third paragraph to include the new licensing terms you mentioned.
+
+🎯 WHY:
+You asked me to revise the memo with the updated licensing language.
+
+⚠️ RISK: 🟡 Moderate
+I'll be changing an existing file. The specific change is adding two sentences to paragraph 3.
+
+✅ If you approve: I'll make the edit. You'll be able to see exactly what changed.
+❌ If you decline: The file stays untouched. I can show you the proposed changes first if you'd prefer.
+
+[y/n]
+```
+
+---
+
+## 3. Bash Command — Safe Command
+
+### ❌ Without Noob Mode
+```
+Allow tool: bash with command "grep -r 'indemnification' ./contracts/"?
+[y/n]
+```
+
+### ✅ With Noob Mode
+```
+📋 WHAT I'M ASKING TO DO:
+I want to search all files in your "contracts" folder for the word "indemnification."
+
+🎯 WHY:
+You asked me to find every mention of indemnification across your contract files.
+
+⚠️ RISK: 🔴 High (but safe in this case)
+Running commands is generally high-risk, but this command only searches — it doesn't change or delete anything.
+
+✅ If you approve: I'll search and show you every file where "indemnification" appears.
+❌ If you decline: I can read files one by one instead, but it'll take longer.
+
+[y/n]
+```
+
+---
+
+## 4. Bash Command — Risky Command
+
+### ❌ Without Noob Mode
+```
+Allow tool: bash with command "rm -rf node_modules && npm install"?
+[y/n]
+```
+
+### ✅ With Noob Mode
+```
+📋 WHAT I'M ASKING TO DO:
+I want to (1) delete the "node_modules" folder, which contains downloaded software libraries, and then (2) re-download all of them fresh.
+
+🎯 WHY:
+Some of the downloaded libraries seem corrupted. Deleting and re-downloading them is a common fix.
+
+⚠️ RISK: 🔴 High
+The first part deletes an entire folder. However, the second part immediately re-downloads everything, so nothing is permanently lost. This might take 1-2 minutes.
+
+✅ If you approve: The old libraries get deleted and fresh copies are downloaded. Your project files are NOT affected.
+❌ If you decline: The corrupted libraries stay, and the error we're seeing will likely persist.
+
+[y/n]
+```
+
+---
+
+## 5. Git Operation
+
+### ❌ Without Noob Mode
+```
+Allow tool: bash with command "git push origin feature/update-terms"?
+[y/n]
+```
+
+### ✅ With Noob Mode
+```
+📋 WHAT I'M ASKING TO DO:
+I want to upload your changes to the shared server (GitHub) on a branch called "feature/update-terms."
+
+🎯 WHY:
+You said you're ready to share these edits with your team for review.
+
+⚠️ RISK: ⛔ Critical
+This sends your changes to a shared server where your colleagues can see them. It doesn't change the main version — it creates a separate branch (copy) for review.
+
+✅ If you approve: Your changes will be visible on GitHub. You or a colleague can create a pull request (a formal review request) from there.
+❌ If you decline: Changes stay only on your computer. Nobody else can see them yet.
+
+[y/n]
+```
+
+---
+
+## 6. URL Access
+
+### ❌ Without Noob Mode
+```
+Allow tool: web_fetch on URL "https://api.github.com/repos/github/docs/issues"?
+[y/n]
+```
+
+### ✅ With Noob Mode
+```
+📋 WHAT I'M ASKING TO DO:
+I want to visit a GitHub web page that lists issues (tracked tasks and bugs) for the "docs" project.
+
+🎯 WHY:
+You asked about open documentation issues. This page has the list.
+
+⚠️ RISK: 🔴 High
+This connects to an external website (GitHub's API). It only reads information — it doesn't post, change, or submit anything.
+
+✅ If you approve: I'll fetch the list and show you a summary of the open issues.
+❌ If you decline: I can't access the live issue list. I can only work with what's already on your computer.
+
+[y/n]
+```
+
+---
+
+## 7. Build Error Output
+
+### ❌ Without Noob Mode
+```
+npm ERR! code ERESOLVE
+npm ERR! ERESOLVE unable to resolve dependency tree
+npm ERR! Found: react@18.2.0
+npm ERR! node_modules/react
+npm ERR!   react@"^18.2.0" from the root project
+npm ERR! Could not resolve dependency:
+npm ERR!   peer react@"^17.0.0" from react-beautiful-dnd@13.1.1
+```
+
+### ✅ With Noob Mode
+```
+❌ WHAT WENT WRONG:
+Two software libraries need different versions of the same tool (React), and they're incompatible.
+
+💡 WHAT THIS MEANS:
+It's like two apps on your phone that each require a different version of iOS — you can't satisfy both at the same time. The library called "react-beautiful-dnd" needs an older version of React (17), but this project is using the newer version (18).
+
+🔧 WHAT WE CAN DO:
+Option A: Update "react-beautiful-dnd" to a newer version that works with React 18
+Option B: Force the install anyway (might cause subtle issues later)
+Option C: Find an alternative library that works with React 18
+
+💡 I'd recommend Option A — it's the cleanest fix.
+```
+
+---
+
+## 8. Test Failure Output
+
+### ❌ Without Noob Mode
+```
+FAIL src/utils.test.ts
+  ● validateEmail › should reject invalid emails
+    expect(received).toBe(expected)
+    Expected: false
+    Received: true
+      12 |   test('should reject invalid emails', () => {
+      13 |     const result = validateEmail('notanemail');
+    > 14 |     expect(result).toBe(false);
+```
+
+### ✅ With Noob Mode
+```
+❌ WHAT WENT WRONG:
+One of the automated checks failed. The email validation function has a bug.
+
+💡 WHAT THIS MEANS:
+There's a function that checks whether an email address is valid. When it was given "notanemail" (which is clearly not a valid email), it said "yes, that's valid" instead of "no, that's not valid."
+
+🔧 WHAT WE CAN DO:
+The email validation logic in the file "src/utils.ts" needs to be fixed so it correctly rejects strings that aren't real email addresses.
+
+Want me to look at the validation code and fix it?
+```
+
+---
+
+## 9. Git Status/Diff Output
+
+### ❌ Without Noob Mode
+```
+On branch main
+Changes not staged for commit:
+  modified:   src/config.ts
+  modified:   README.md
+Untracked files:
+  docs/new-guide.md
+```
+
+### ✅ With Noob Mode
+```
+✅ HERE'S WHAT'S GOING ON WITH YOUR FILES:
+
+📝 Changed files (edited but not yet saved to version history):
+  • src/config.ts — Modified (this file was changed)
+  • README.md — Modified (this file was changed)
+
+🆕 New files (not yet tracked):
+  • docs/new-guide.md — This is a brand-new file that version control hasn't seen before
+
+💡 SUMMARY: You have 2 files with unsaved changes and 1 new file. None of these changes have been "committed" (saved to your project's history) yet.
+```
+
+---
+
+## 10. Multi-Step Task Planning
+
+### ❌ Without Noob Mode
+```
+I'll read the current implementation, refactor the auth module, update the tests, and run the test suite.
+```
+
+### ✅ With Noob Mode
+```
+📍 HERE'S MY PLAN (4 steps):
+
+1. 📖 Read the current login code to understand how it works
+2. ✏️ Rewrite it to use the new approach you described
+3. 🧪 Update the automated checks to match the new code
+4. ▶️ Run all the checks to make sure nothing broke
+
+I'll ask for your permission at each step, and I'll explain what happened after each one.
+
+Starting with step 1 now...
+```
+
+---
+
+## 11. Technical Question to User
+
+### ❌ Without Noob Mode
+```
+Should I use a relative or absolute path for the import?
+```
+
+### ✅ With Noob Mode
+```
+I need your input on something:
+
+**Option A: Relative path**
+What this means: Reference the file based on where THIS file is located (like saying "the folder next door").
+Trade-off: Works well when files are near each other, but can break if you move files around.
+
+**Option B: Absolute path**
+What this means: Reference the file using its full address from the project root (like giving a complete street address).
+Trade-off: Always works regardless of where things move, but is more verbose.
+
+💡 I'd recommend Option B — it's more resilient if the project structure changes later.
+```
+
+---
+
+## 12. Package Installation
+
+### ❌ Without Noob Mode
+```
+Allow tool: bash with command "npm install lodash@4.17.21"?
+[y/n]
+```
+
+### ✅ With Noob Mode
+```
+📋 WHAT I'M ASKING TO DO:
+I want to download a widely-used utility library called "lodash" (version 4.17.21). It provides helper functions for working with data.
+
+🎯 WHY:
+The code I'm writing needs a function to safely access nested data. Lodash provides this, and it's the industry standard.
+
+⚠️ RISK: 🟡 Moderate
+This downloads code from the internet and adds it to your project. Lodash is extremely well-known and trusted — it's used by millions of projects.
+
+✅ If you approve: The library gets downloaded into a "node_modules" folder. Your actual project files aren't changed.
+❌ If you decline: I'll write the utility function by hand instead, which takes a bit longer.
+
+[y/n]
+```
+
+---
+
+## 13. File Deletion
+
+### ❌ Without Noob Mode
+```
+Allow tool: bash with command "rm src/deprecated/old-auth.ts"?
+[y/n]
+```
+
+### ✅ With Noob Mode
+```
+📋 WHAT I'M ASKING TO DO:
+I want to permanently delete the file "src/deprecated/old-auth.ts."
+
+🎯 WHY:
+This file contains the old login code that we just replaced. No other file references it anymore, so it's safe to remove.
+
+⚠️ RISK: 🔴 High
+Deleting a file is permanent — there's no recycle bin for this. However, this file is tracked by git (version control), so we could recover it from history if needed.
+
+✅ If you approve: The file is deleted from your computer. It can still be recovered from git history if you ever need it.
+❌ If you decline: The file stays. It won't cause any harm — it's just unused clutter.
+
+💡 SAFETY NOTE: Want me to make a backup copy before deleting it?
+
+[y/n]
+```
+
+---
+
+## 14. Complex Error Message
+
+### ❌ Without Noob Mode
+```
+Error: EACCES: permission denied, open '/usr/local/lib/node_modules/@github/copilot/package.json'
+    at Object.openSync (node:fs:603:3)
+    at Object.readFileSync (node:fs:471:35)
+```
+
+### ✅ With Noob Mode
+```
+❌ WHAT WENT WRONG:
+The computer blocked access to a file because your user account doesn't have permission to modify it.
+
+💡 WHAT THIS MEANS:
+The file is in a protected system folder ("/usr/local/...") that requires administrator privileges to change. This is actually a security feature — it prevents programs from accidentally modifying important system files.
+
+🔧 WHAT WE CAN DO:
+Option A: Run the command with administrator privileges ("sudo") — this temporarily elevates your permissions
+Option B: Install to a different location that doesn't require special permissions
+
+💡 I'd recommend Option B — it's safer and avoids needing admin access.
+```
+
+---
+
+## 15. Task Completion Summary
+
+### ❌ Without Noob Mode
+```
+Done. Created the analysis file.
+```
+
+### ✅ With Noob Mode
+```
+✅ ALL DONE — Here's what happened:
+
+📄 Files created:
+  • ~/Desktop/IP-Risk-Analysis.md — A 3-page analysis of the IP risks in the proposed partnership, organized by risk level (high, medium, low)
+
+📝 Files changed:
+  • (none — I didn't change any existing files)
+
+🗑️ Files deleted:
+  • (none)
+
+💡 SUMMARY:
+I created a new document on your Desktop with the IP risk analysis you requested. It covers:
+- 3 high-risk items (patent exposure, GPL contamination, trade secret concerns)
+- 5 medium-risk items (trademark usage, attribution requirements, etc.)
+- 2 low-risk items (standard OSS components)
+
+Each item includes a plain-English explanation and recommended next steps.
+
+🔄 TO UNDO: Delete the file at ~/Desktop/IP-Risk-Analysis.md
+
+🎉 Anything else you'd like me to help with?
+```

plugins/noob-mode/skills/noob-mode/references/glossary.md

@@ -0,0 +1,368 @@
+# Noob Mode Glossary
+
+A plain-English reference for technical terms you'll encounter when using Copilot CLI. Organized by category.
+
+---
+
+## 🗂️ Git & Version Control
+
+### Repository (repo)
+**Plain English:** A project folder that remembers every change ever made to its files.
+**Analogy:** A filing cabinet with a built-in time machine — you can pull out any version of any document from any point in the past.
+**Example in context:** "I'll look at the files in this repository" = "I'll look at the files in this project folder."
+
+### Branch
+**Plain English:** A separate copy of your project where you can try changes without affecting the original.
+**Analogy:** Making a photocopy of a contract to test edits on, without touching the signed original.
+**Example in context:** "I'll create a new branch" = "I'll make a copy where I can safely experiment."
+
+### Commit
+**Plain English:** Saving a snapshot of your work with a note about what you changed.
+**Analogy:** Taking a photo of your desk at the end of each work session, with a Post-it note saying what you did.
+**Example in context:** "I'll commit these changes" = "I'll save a snapshot of what I just did."
+
+### Merge
+**Plain English:** Combining changes from one copy back into the original.
+**Analogy:** Taking the edits from your marked-up photocopy and writing them into the official contract.
+**Example in context:** "Let's merge this branch" = "Let's fold these changes back into the main version."
+
+### Pull Request (PR)
+**Plain English:** A formal request saying "I made these changes — can someone review them before we make them official?"
+**Analogy:** Submitting a redlined document for partner review before it goes to the client.
+**Example in context:** "I'll open a pull request" = "I'll submit these changes for review."
+
+### Clone
+**Plain English:** Downloading a complete copy of a project from a server to your computer.
+**Analogy:** Getting your own copy of a shared case file from the firm's server.
+**Example in context:** "Clone the repository" = "Download the project to your computer."
+
+### Fork
+**Plain English:** Making your own personal copy of someone else's project on the server.
+**Analogy:** Getting your own copy of a template that you can customize without affecting the original template.
+**Example in context:** "Fork this repo" = "Create your own copy of this project."
+
+### Diff
+**Plain English:** A comparison showing exactly what changed between two versions — what was added, removed, or modified.
+**Analogy:** Track Changes in Word, showing red strikethroughs and blue additions.
+**Example in context:** "Let me check the diff" = "Let me see exactly what changed."
+
+### Staging Area (Index)
+**Plain English:** A waiting area where you place files before saving a snapshot. Like a "to be committed" pile.
+**Analogy:** The outbox on your desk — documents you've decided to send but haven't actually mailed yet.
+**Example in context:** "I'll stage these files" = "I'll mark these files as ready to be saved."
+
+### Remote
+**Plain English:** The copy of your project that lives on a server (like GitHub), as opposed to the copy on your computer.
+**Analogy:** The master copy in the firm's cloud storage vs. the copy on your laptop.
+**Example in context:** "Push to remote" = "Upload your changes to the server."
+
+### Push
+**Plain English:** Uploading your saved changes from your computer to the shared server.
+**Analogy:** Syncing your local edits back to the shared drive so everyone can see them.
+**Example in context:** "I'll push these commits" = "I'll upload these saved changes to the server."
+
+### Pull
+**Plain English:** Downloading the latest changes from the shared server to your computer.
+**Analogy:** Refreshing your local copy with any updates your colleagues have made.
+**Example in context:** "Pull the latest changes" = "Download any updates from the server."
+
+### Checkout
+**Plain English:** Switching to a different branch or version of your project.
+**Analogy:** Pulling a different version of a document from the filing cabinet to work on.
+**Example in context:** "Checkout the main branch" = "Switch back to the main version of the project."
+
+### Conflict
+**Plain English:** When two people changed the same part of the same file, and the computer can't automatically figure out which version to keep.
+**Analogy:** Two lawyers edited the same paragraph of a contract differently — someone needs to decide which version wins.
+**Example in context:** "There's a merge conflict" = "Two sets of changes overlap and I need you to decide which to keep."
+
+### Stash
+**Plain English:** Temporarily saving your current work-in-progress so you can switch to something else, then come back to it later.
+**Analogy:** Putting your current papers in a drawer so you can clear your desk for an urgent task, then pulling them back out later.
+**Example in context:** "I'll stash your changes" = "I'll save your work-in-progress temporarily."
+
+### HEAD
+**Plain English:** The version of the project you're currently looking at / working on.
+**Analogy:** The document that's currently open on your screen.
+**Example in context:** "HEAD points to main" = "You're currently looking at the main version."
+
+### Tag
+**Plain English:** A permanent label attached to a specific version, usually marking a release or milestone.
+**Analogy:** Putting a "FINAL — Signed by Client" sticker on a specific version of a contract.
+**Example in context:** "I'll tag this as v1.0" = "I'll mark this version as the official 1.0 release."
+
+---
+
+## 💻 File System & Shell
+
+### Terminal (Console)
+**Plain English:** The text-based control panel for your computer. You type commands instead of clicking buttons.
+**Analogy:** Like texting instructions to your computer instead of pointing and clicking.
+**Example in context:** "Open your terminal" = "Open the app where you type commands."
+
+### Shell (Bash, Zsh)
+**Plain English:** The program that runs inside your terminal and interprets the commands you type.
+**Analogy:** The operator on the other end of a phone line who carries out your requests.
+**Example in context:** "Run this in your shell" = "Type this command in your terminal."
+
+### CLI (Command Line Interface)
+**Plain English:** A program you interact with by typing commands instead of clicking a visual interface.
+**Analogy:** Ordering at a restaurant by speaking to the waiter (CLI) vs. tapping on a tablet menu (GUI).
+**Example in context:** "Use the CLI" = "Type commands instead of clicking buttons."
+
+### Directory
+**Plain English:** A folder on your computer.
+**Analogy:** It's literally a folder. We just use a fancier word sometimes.
+**Example in context:** "Navigate to this directory" = "Go to this folder."
+
+### Path
+**Plain English:** The address of a file or folder on your computer, showing every folder you'd pass through to get to it.
+**Analogy:** Like a street address: Country / State / City / Street / Building — but for files.
+**Example in context:** "`~/Desktop/contracts/nda.md`" = "A file called nda.md, in the contracts folder, on your Desktop."
+
+### Root (/)
+**Plain English:** The very top-level folder on your computer — every other folder lives inside it.
+**Analogy:** The lobby of a building — every floor and room is accessed from here.
+**Example in context:** "The root directory" = "The top-most folder on your computer."
+
+### Home Directory (~)
+**Plain English:** Your personal folder on the computer. On a Mac, it's `/Users/yourname`.
+**Analogy:** Your personal office within the building.
+**Example in context:** "`~/Desktop`" = "The Desktop folder inside your personal folder."
+
+### Environment Variable
+**Plain English:** A setting stored on your computer that programs can read. Like a sticky note on your monitor that apps can see.
+**Analogy:** A name badge that programs can check to learn something about your setup.
+**Example in context:** "Set the environment variable" = "Save a setting that programs can look up."
+
+### Pipe (|)
+**Plain English:** Sends the output of one command into another command, like an assembly line.
+**Analogy:** Handing a document from one person to the next in a relay.
+**Example in context:** "`grep 'term' file.txt | wc -l`" = "Find the term, then count how many times it appears."
+
+### Redirect (>, >>)
+**Plain English:** Sends output to a file instead of showing it on screen. `>` replaces the file; `>>` adds to it.
+**Analogy:** Instead of reading a report aloud, writing it down on paper.
+**Example in context:** "`echo 'hello' > file.txt`" = "Write 'hello' into file.txt (replacing whatever was there)."
+
+### Permissions
+**Plain English:** Rules about who can read, edit, or run a file. Shown as codes like `rwx` or numbers like `755`.
+**Analogy:** Like document permissions in SharePoint — who can view, who can edit, who can share.
+**Example in context:** "Change file permissions" = "Change who's allowed to read or edit this file."
+
+### Symlink (Symbolic Link)
+**Plain English:** A shortcut that points to another file or folder. Not a copy — just a pointer.
+**Analogy:** A hyperlink in a document that takes you to the original file.
+**Example in context:** "Create a symlink" = "Create a shortcut pointing to another file."
+
+### stdout / stderr
+**Plain English:** Two channels for program output. stdout is normal output; stderr is error messages.
+**Analogy:** stdout is the main speaker at a meeting; stderr is someone passing urgent notes.
+**Example in context:** "Redirect stderr" = "Send error messages somewhere specific."
+
+### Script
+**Plain English:** A file containing a list of commands that run automatically, one after another.
+**Analogy:** A recipe — follow the steps in order, and you get the result.
+**Example in context:** "Run this script" = "Run this pre-written list of commands."
+
+---
+
+## 🔧 Development Concepts
+
+### API (Application Programming Interface)
+**Plain English:** A way for two programs to talk to each other, following agreed-upon rules.
+**Analogy:** A waiter in a restaurant — takes your order to the kitchen and brings back what you asked for.
+**Example in context:** "Call the API" = "Send a request to another program and get a response."
+
+### Endpoint
+**Plain English:** A specific URL where an API accepts requests, like a specific phone extension at a company.
+**Analogy:** A specific desk in a government office that handles one type of request.
+**Example in context:** "The /users endpoint" = "The specific address that handles user-related requests."
+
+### Server
+**Plain English:** A computer (or program) that provides a service when you ask for it. It waits for requests and responds.
+**Analogy:** A librarian — you ask for a book, they find it and hand it to you.
+**Example in context:** "Start the server" = "Turn on the program that listens for and responds to requests."
+
+### Client
+**Plain English:** The program that sends requests to a server. Your web browser is a client.
+**Analogy:** The patron at the library who asks the librarian for a book.
+**Example in context:** "The client sends a request" = "Your program asks the server for something."
+
+### Database
+**Plain English:** An organized collection of data that programs can search, add to, update, and delete from.
+**Analogy:** A very sophisticated spreadsheet that multiple programs can read and write to simultaneously.
+**Example in context:** "Query the database" = "Look up information in the data storage."
+
+### Dependency
+**Plain English:** A pre-built tool or library that a project needs in order to work.
+**Analogy:** Reference books you need on your shelf to do your research.
+**Example in context:** "Install dependencies" = "Download all the tools and libraries this project needs."
+
+### Package
+**Plain English:** A bundle of code that someone else wrote, packaged up for others to use.
+**Analogy:** A pre-built toolkit from a hardware store — saves you from building the tools yourself.
+**Example in context:** "Install the package" = "Download and add this pre-built toolkit to your project."
+
+### Module
+**Plain English:** A self-contained piece of code that handles one specific thing.
+**Analogy:** A chapter in a book — it covers one topic and can be read somewhat independently.
+**Example in context:** "Import the auth module" = "Load the piece of code that handles login/security."
+
+### Framework
+**Plain English:** A pre-built foundation that gives you a structure to build on, with rules about how to organize your code.
+**Analogy:** A legal brief template — it gives you the structure, and you fill in the substance.
+**Example in context:** "We're using the React framework" = "We're building on top of a pre-made structure called React."
+
+### Build
+**Plain English:** Converting source code into something that can actually run.
+**Analogy:** Converting a Word doc to a final PDF — the content is the same, but the format is now ready for distribution.
+**Example in context:** "Run the build" = "Convert the code into its finished, runnable form."
+
+### Compile
+**Plain English:** Translating code from the language humans write in to the language computers understand.
+**Analogy:** Translating a contract from English to Japanese so the other party can read it.
+**Example in context:** "Compile the code" = "Translate it into computer-readable form."
+
+### Lint / Linter
+**Plain English:** A tool that checks your code for common mistakes, style issues, and potential problems — without running it.
+**Analogy:** A spell-checker and grammar-checker for code.
+**Example in context:** "Run the linter" = "Check the code for mistakes and style issues."
+
+### Test (Unit Test, Integration Test)
+**Plain English:** Code that automatically checks whether other code works correctly.
+**Analogy:** A checklist QA review — "Does the login page work? Does the search return results? Does the save button actually save?"
+**Example in context:** "Run the tests" = "Automatically verify that everything still works correctly."
+
+### Runtime
+**Plain English:** The environment where code actually runs. Also refers to the time period when code is actively running.
+**Analogy:** The stage where a play is performed (as opposed to the script, which is the code).
+**Example in context:** "A runtime error" = "Something went wrong while the program was actually running."
+
+### Deploy
+**Plain English:** Taking finished code and putting it somewhere people can use it (a server, a website, an app store).
+**Analogy:** Publishing a finished book — moving it from the author's desk to bookstore shelves.
+**Example in context:** "Deploy to production" = "Make this available to real users."
+
+---
+
+## 🌐 Web & Networking
+
+### URL (Uniform Resource Locator)
+**Plain English:** A web address. The text you type in a browser's address bar.
+**Analogy:** A street address, but for websites.
+**Example in context:** "`https://github.com/settings`" = "The settings page on GitHub's website."
+
+### HTTP / HTTPS
+**Plain English:** The language that web browsers and servers use to talk to each other. HTTPS is the secure (encrypted) version.
+**Analogy:** HTTP is sending a postcard (anyone could read it); HTTPS is sending a sealed, locked envelope.
+**Example in context:** "Make an HTTP request" = "Send a message to a web server."
+
+### JSON (JavaScript Object Notation)
+**Plain English:** A standard format for structuring data that's easy for both humans and computers to read.
+**Analogy:** A very organized form with labeled fields, like: `{ "name": "Jane", "role": "Attorney" }`.
+**Example in context:** "The API returns JSON" = "The response comes back as structured, labeled data."
+
+### Token
+**Plain English:** A digital key or pass that proves your identity, used instead of typing your password every time.
+**Analogy:** A building access badge — you swipe it instead of showing your ID each time.
+**Example in context:** "Your authentication token" = "The digital key that proves you're logged in."
+
+### Status Code
+**Plain English:** A number that a web server sends back to tell you whether your request worked. Common ones:
+- **200** = Success ("Here's what you asked for")
+- **404** = Not Found ("That page/thing doesn't exist")
+- **500** = Server Error ("Something broke on our end")
+- **401** = Unauthorized ("You need to log in first")
+- **403** = Forbidden ("You're logged in but don't have permission")
+
+### Localhost
+**Plain English:** A way of referring to your own computer as if it were a web server. Used for testing.
+**Analogy:** Rehearsing a presentation in your own office before giving it in the conference room.
+**Example in context:** "`http://localhost:3000`" = "A website running on your own computer, on channel 3000."
+
+### Port
+**Plain English:** A numbered channel on a computer. Different services use different ports, like different TV channels.
+**Analogy:** Radio frequencies — each station broadcasts on its own frequency so they don't interfere.
+**Example in context:** "Running on port 3000" = "Using channel 3000 on your computer."
+
+### REST (RESTful API)
+**Plain English:** A common style for building web APIs, where you use standard web addresses and actions (GET, POST, etc.) to interact with data.
+**Analogy:** A standardized form system — everyone agrees on how to submit, retrieve, update, and delete records.
+**Example in context:** "A RESTful endpoint" = "A web address that follows standard conventions for data access."
+
+---
+
+## 🤖 Copilot CLI Specific
+
+### MCP Server (Model Context Protocol)
+**Plain English:** An add-on that gives Copilot CLI extra abilities — like plugins for a web browser.
+**Analogy:** Installing a new app on your phone that adds a capability it didn't have before.
+**Example in context:** "Configure an MCP server" = "Set up an add-on that gives Copilot new capabilities."
+
+### Tool Call
+**Plain English:** When Copilot asks to use one of its built-in abilities (read a file, run a command, search the web, etc.).
+**Analogy:** An assistant asking "Can I open this filing cabinet?" before going ahead.
+**Example in context:** "Approve this tool call" = "Give me permission to use this specific ability."
+
+### Approval Prompt
+**Plain English:** The moment when Copilot stops and asks for your permission before doing something.
+**Analogy:** Your assistant saying "Before I send this email, can you review it?"
+**Example in context:** "I need your approval" = "I'm asking permission before I do this."
+
+### Context Window
+**Plain English:** The total amount of conversation and information Copilot can remember at one time. When it fills up, older parts get summarized or forgotten.
+**Analogy:** The size of your desk — you can only have so many papers spread out before you need to file some away.
+**Example in context:** "The context window is getting full" = "I'm running low on working memory and may need to summarize our earlier conversation."
+
+### Model
+**Plain English:** The AI brain that powers Copilot. Different models (Sonnet, GPT, Gemini) have different strengths.
+**Analogy:** Different search engines (Google, Bing) — they all search the web, but they work differently and give slightly different results.
+**Example in context:** "Switch to a different model" = "Use a different AI brain."
+
+### Token
+**Plain English:** The unit of text that AI models process. Roughly, 1 token ≈ ¾ of a word.
+**Analogy:** If the AI reads in syllables instead of whole words, each syllable is a token.
+**Example in context:** "This uses 1,000 tokens" = "This is about 750 words' worth of AI processing."
+
+### Skill
+**Plain English:** A specialized capability you can add to Copilot CLI for a specific type of task.
+**Analogy:** A specialist you can call in — like bringing in a tax expert vs. a contracts expert.
+**Example in context:** "Activate a skill" = "Turn on a specialized capability."
+
+### Plugin
+**Plain English:** An add-on that extends what Copilot CLI can do, provided by a third party.
+**Analogy:** A browser extension — someone else built it, and you install it to add features.
+**Example in context:** "Install a plugin" = "Add a third-party feature to Copilot."
+
+### Session
+**Plain English:** One continuous conversation with Copilot CLI, from when you start to when you close it.
+**Analogy:** A phone call — everything discussed is part of that one session until you hang up.
+**Example in context:** "Resume a session" = "Pick up a previous conversation where you left off."
+
+### Custom Instructions
+**Plain English:** A file that tells Copilot how to behave — your preferences, rules, and style requirements.
+**Analogy:** A brief you give a new associate: "Here's how I like my memos formatted, and here's what to prioritize."
+**Example in context:** "Toggle custom instructions" = "Turn on or off a specific set of behavior rules for Copilot."
+
+---
+
+## 📎 Common Commands
+
+| What you see | What it means |
+|---|---|
+| `ls` | List the files in this folder |
+| `cd` | Change directory (go to a different folder) |
+| `cat` | Show the contents of a file |
+| `cp` | Copy a file |
+| `mv` | Move or rename a file |
+| `rm` | Delete a file (careful — this is permanent!) |
+| `mkdir` | Create a new folder |
+| `grep` | Search for specific text in files |
+| `curl` | Send a request to a web URL |
+| `npm install` | Download the tools/libraries this project needs |
+| `git status` | Check what files have been changed |
+| `git add` | Mark files as ready to be saved |
+| `git commit` | Save a snapshot of your changes |
+| `git push` | Upload your changes to the shared server |
+| `git pull` | Download the latest updates from the shared server |