Vibe Coding 99-101 for non-coders

Here’s the part most “build an app with AI” tutorials skip: before the magic happens, you have to install a small pile of tools and get them talking to each other.

This post gets you ready to vibe code your blog, an app, a tool that handles a repetitive task, or whatever else you want to build. You’ll set up the accounts and tools, learn your way around the command line, and give your AI assistant reusable guidance so you don’t have to explain everything again each session.

I’ll use a blog as the worked example, not as a requirement. Part 2 follows that example through building and publishing a site. The setup and habits here apply beyond it.

Why?Not building a blog? Skip Astro.

Astro is the website-building tool used for the blog example in Part 2. You can skip installing Astro and creating its blog template if you don’t want a blog. Start with your own project idea instead, and ask Copilot which tools it needs before installing anything project-specific. The GitHub, Git, Copilot, agents, and skills guidance here still applies.

This is written for someone who has never written a line of code. If you can install an app and follow a numbered list, you can do this. I’ll define every piece of jargon the first time it shows up, and any word with a dotted underline is one you can hover over (or tap on a phone) for a plain-language definition. Try it here: codeThe written instructions that tell a computer what to do. Code lives in ordinary text files, and a project is usually made of hundreds of them..

One thing worth saying up front: there are many tools you can use to vibe code, and no single one is “correct.” Whichever tool you’re most comfortable with that gets the job done is the best one to use. This series leans on the GitHub Copilot app, because it handles the whole loop: agent, files, branches, diffs, terminal, and pull requests, without a separate editor in the mix. The GitHub Copilot CLI is worth a look too if you’d rather live in a terminal.

Why?Already have a working project?

If your tools are already installed and working, skip to “Scaffold a home for your agents and skills” near the end. That section shows you where to keep reusable guidance, whether you’re building a blog or something else.

What “vibe coding” is (and isn’t)

Vibe coding means describing what you want in plain language and steering an AI until the thing actually works, not typing a single prompt and walking away with a finished app. It’s a conversation: you set the direction, the AI proposes, you push back, and you converge on something real.

I go deep on the mindset in Coding with AI: A Neurodivergent Non-Coder’s Guide to Building Real Apps: plan mode, picking a model, knowing when the AI has wandered off. Read that for the why. This post is the how do I even get started.

Before you install anything: the plan

The walkthrough covers seven things. Start with the first four for working with GitHub Copilot; the rest depend on what you’re building:

1. A GitHub account: your home base for code, history, and hosting.
2. Git: the tool that actually tracks your changes locally.
3. The GitHub CLI (gh): the tool that introduces your local Git to your GitHub account, so pushing your work just works.
4. The GitHub Copilot app: where you’ll do the actual vibe coding.
5. Node.js Long-Term Support (“LTS”) + npm: tools used to build and preview the blog, and many other web projects. Install them if your project needs them.
6. Python (latest): a programming language used by many helper tools and small programs that automate tasks. Install it if your project or a tool needs it; the blog itself doesn’t.
7. An Azure account and the Azure CLI (az): needed for the publishing steps in Part 2. Skip these if you aren’t using Azure.

Then you’ll scaffold a home for your agents and skills so the AI works with you instead of guessing. Let’s go.

A note on operating systems: I’m writing the commands Windows-first, since that’s what most first-timers are on. Where macOS or Linux differ, I’ll call it out inline.

First, meet the terminal

Almost every step below asks you to “run a command in a terminal,” so let’s kill that mystery before it trips you up.

A terminal is a window where you type instructions to your computer as text instead of clicking buttons. That’s the whole idea. You type a line, press Enter, and the computer does the thing and prints the result back at you. It looks intimidating because it’s plain text on a plain background, not because it’s hard.

Here’s how to open one:

• Windows: press the Start button, type Terminal, and open Windows Terminal. If you’re on an older Windows build that doesn’t have it, type PowerShell instead and open that.
• macOS: press Cmd + Space, type Terminal, press Enter.
• Linux: Ctrl + Alt + T on most desktops.

Try one now. Type this and press Enter:

whoami

It prints your username back. That’s a command: you typed an instruction, the computer answered. Everything else in this post is the same move with longer words.

Three things worth knowing before you go further.

A terminal is always “sitting” in some folder. Commands act on wherever you currently are, which matters later when you’re working inside your project. To see where you are and what’s there:

pwd     # Windows PowerShell, macOS, and Linux: prints the folder you're in
ls      # lists the files and folders in it
cd somefolder   # moves into a folder
cd ..           # moves back up one level

Why?Why does the folder I'm in matter?

Because commands are relative to it. Running a build command while sitting in your Documents folder does nothing useful; running it inside your project folder builds your project. When a step says “from your project folder,” it means: use cd to move there first, then run the command. The GitHub Copilot app handles this for you most of the time, since its built-in terminal already starts inside the project you have open.

Nothing you type here is permanent unless it changes a file. Commands that just print information, like every --version check in this post, are completely safe. Run them as many times as you like.

“Close and reopen your terminal” is real advice, not filler. When you install a tool, the installer tells your system where to find it, but a terminal window that’s already open doesn’t get the memo. It only reads that information when it starts. So after every install below, close the window and open a fresh one before you test.

Why?Terminal, shell, command line, command prompt — are these all the same thing?

Close enough to treat them as one thing for now. The terminal is the window. The shell is the program inside it that actually reads what you type (PowerShell on Windows, usually zsh on macOS). “Command line” and “command prompt” are casual names for the same experience. Nobody will correct you if you use them interchangeably, and this post does.

Install the tools your project needs

Work through Steps 1–4 in order. Steps 5–7 explain the additional tools; use the plan above to decide which ones you need.

Step 1: Create a GitHub account

Head to github.com and sign up. Pick a username you won’t be embarrassed by later. It shows up in your project URLs. Verify the confirmation email before you close the tab; an unverified account can’t push code or use GitHub Copilot.

Why?Why use GitHub for my project?

Three reasons. First, it’s a backup: your writing and code live safely in the cloud, not just on one laptop. Second, it’s a time machine: every change is versioned, so you can undo anything, even a week later. Third, it’s free hosting and the front door for AI tools: GitHub Copilot and the agents you’ll use authenticate through your GitHub identity. One account unlocks all of it.

While you’re there, enable two-factor authentication in your account settings. GitHub requires it for most contributors now, and you don’t want to hit that wall mid-project. When GitHub shows you the recovery codes, save them somewhere you’ll still have access to if you lose your phone. People skip this step constantly and then get locked out of the account holding all their work.

Why?Free, Pro, Enterprise, or Education — which one do I need?

A free GitHub account is enough for the repositories and Actions work in this series. GitHub Copilot Free is more limited, though, and doesn’t include GitHub Copilot cloud agent. If you want the asynchronous branch-and-PR workflow described here, you’ll need a paid GitHub Copilot plan or an eligible Education plan.

As of July 2026, GitHub Copilot Pro is $10 USD per month. It includes unlimited completions, access to a selection of models, GitHub Copilot cloud agent, and a monthly allowance of AI credits. Check the plan table before buying because prices, model access, and usage allowances change.

And if you’re a student or teacher, don’t pay a cent yet. Apply for GitHub Education first. Verified students get the free GitHub Copilot Student plan, which has unlimited completions but more limited chat, agent, and model access than Pro. Verified teachers are eligible for GitHub Copilot Pro at no charge.

Step 2: Install Git (this is not the same as a GitHub account)

This trips people up constantly: your GitHub account lives on the web, but Git is a separate program that runs on your computer and does the actual work of tracking changes.

• Windows: download and run the installer from git-scm.com. Accept the defaults, with one exception. On the screen titled Choosing the default editor used by Git, the default is Vim, which is famously hard to get out of if you’ve never used it. Pick Notepad unless you already have a favorite.
• macOS: run git --version in Terminal; if Git isn’t installed, macOS offers to install it for you. Or use Homebrew: brew install git.
• Linux: sudo apt install git (Debian/Ubuntu) or your distro’s equivalent.

Once installed, tell Git who you are. This stamps your name on every change you save. Then set the default branch name to match GitHub’s:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Why?Why does Git need my name and email?

Every saved change (a “commit”) records who made it. Use the same email as your GitHub account so your work is properly attributed. It’s not a login, just a label on your history.

Why?What's that third line about?

Git has historically named the first branch in a new repository master, while GitHub names it main. Leave them mismatched and your first push lands in a branch GitHub doesn’t consider the default, which quietly breaks deployment workflows in Part 2 and produces a repository with two half-empty branches. Setting init.defaultBranch to main once, now, avoids the whole mess. It only affects repositories you create after running it.

Step 3: Connect Git to GitHub with the GitHub CLI

You now have an account in the cloud and Git on your machine, and the two have never met. Nothing you commit locally reaches GitHub until you can prove to GitHub that you’re you.

The old answer to that was SSH keys, or a personal access token you pasted into a prompt once and then lost. The current answer is the GitHub CLI (gh), which handles the login and then configures Git to reuse those credentials from that point on. This series leans on gh in Part 2 as well, so install it now.

• Windows: winget install --id GitHub.cli in a terminal, or grab the installer from cli.github.com.
• macOS: brew install gh.
• Linux: follow the package instructions for your distro at cli.github.com.

Close and reopen your terminal, confirm gh is on your PATH, then log in:

gh --version
gh auth login

gh auth login asks a short series of questions. The answers that matter:

1. What account do you want to log into? → GitHub.com
2. What is your preferred protocol for Git operations? → HTTPS
3. Authenticate Git with your GitHub credentials? → Yes
4. How would you like to authenticate GitHub CLI? → Login with a web browser

It prints a one-time code, opens your browser, and you paste the code and approve. Then confirm it stuck:

gh auth status

You should see your GitHub username and the scopes you’re authenticated with. If you do, your machine and your account are connected.

Why?What did answering 'Yes' to question 3 actually do?

It pointed Git’s credential helper at your GitHub CLI login. From then on, git push quietly borrows that token instead of stopping to ask you for a password. This is the single step that makes “I committed something” and “it’s safely on GitHub” feel like one action instead of two.

Skip it and your first push throws a confusing authentication prompt, and your GitHub password won’t work there, because GitHub stopped accepting passwords for Git operations years ago.

Why?HTTPS or SSH?

Both work. HTTPS is the easier first answer: no keys to generate, no agent to configure, and it gets through corporate networks that block SSH. SSH is worth learning later, especially if you juggle personal and work accounts on one machine. Start with HTTPS. You can switch any time with gh auth login again.

Step 4: Install the GitHub Copilot app

This is the one you’ll actually spend your time in. The GitHub Copilot app is GitHub’s native desktop experience for agent-driven development, and it runs on macOS, Windows, and Linux. Download it, then sign in with the GitHub account from Step 1.

The reason it’s worth making this your home base: it covers the whole loop without a second tool. Each session gets its own workspace with its own branch and files, so two experiments can’t step on each other. You inspect diffs, run terminal commands, preview the site in a built-in browser, and open or merge pull requests without leaving the session you’re in. That’s the entire cycle you’d otherwise be stitching together across an editor, a terminal, and a browser.

Why?Do I need a paid plan for the app?

No. The GitHub Copilot app is included on every GitHub Copilot plan, including Free, and you can bring your own model key instead. Where the paid plans matter is elsewhere: GitHub Copilot cloud agent and GitHub Copilot code review start at Pro. So the app itself isn’t the paywall; the asynchronous “assign it and walk away” workflow is.

There’s a second surface worth knowing about, and it needs no install: GitHub Copilot cloud agent on GitHub.com. You describe work in the browser, the agent runs it on a branch, and it comes back as a pull request for you to review. It’s the asynchronous counterpart to the GitHub Copilot app, and it’s on a Pro plan or better.

Why?App or cloud agent — which do I reach for?

I use both, for different shapes of work. The GitHub Copilot app is for anything I want to watch and steer: building a feature, debugging, poking at output as it appears. GitHub Copilot cloud agent is for “describe it, let it run, review the PR when I get back,” the tasks I can hand off and stop thinking about. Start with the app. Cloud agent makes more sense once you have a repository and a rhythm, which is Part 2.

Step 5: Install Node.js (LTS) and confirm npm works

Node.js runs code on your computer and is used to build and preview many web projects, including the blog in Part 2. Node ships with npm, the tool that installs the building blocks your project depends on. If your project doesn’t use Node.js, you can skip this step.

Install the LTS version, not “Current,” from nodejs.org.

Why?Why LTS and not the newest 'Current' version?

LTS stands for “Long-Term Support.” It’s the stable, boring, widely-compatible version that every tutorial and tool expects. “Current” is the bleeding edge: newer, but more likely to surface bugs you won’t yet know how to debug. As a beginner, boring is your friend.

After installing, close and reopen your terminal, then verify both tools are found:

node --version
npm --version

You should see version numbers (for example, v24.x.x and 11.x.x; Node 24 is the current LTS line, and it ships npm 11). If instead you see something like 'npm' is not recognized or command not found, your PATH isn’t picking up Node yet.

Why?What is PATH, and why would npm 'not be found'?

PATH is the list of folders your terminal searches when you type a command. If node and npm aren’t found, it means the terminal doesn’t know where the installer put them. The fix is almost never manual PATH surgery.

The reliable fix for a “not found” error:

1. Fully quit and reopen your terminal (and the GitHub Copilot app). The installer updates PATH, but only new terminal sessions see it.
2. Restart your computer if reopening the terminal doesn’t do it.
3. If it still fails, don’t hand-edit PATH. Instead, uninstall Node and reinstall it with a version manager, which handles PATH for you: fnm or nvm-windows on Windows; nvm on macOS/Linux.

Why?Why a version manager is the better long-term answer

A version manager installs Node in a predictable place, wires up your PATH automatically, and lets you switch Node versions per project later. It removes the entire class of “npm not found” problems instead of patching one instance.

Step 6: Install Python (latest)

Python is useful for automation and for tools that help your AI assistant work. You don’t need it for the blog itself. Follow this step if your project or a helper tool uses Python; otherwise, you can come back when you need it.

Grab the latest stable release, 3.14 as I write this, not an old 3.9 or 3.10, from python.org/downloads.

• Windows: run the installer and check the box that says “Add python.exe to PATH” on the very first screen. That one checkbox saves you an hour of troubleshooting later.
• macOS: the installer from python.org is the most predictable route. You can also use Homebrew: brew install python.
• Linux: many distros already include Python 3, but don’t assume the bundled version is current. Confirm with python3 --version; if it’s older than 3.12, install a newer one via your distro’s package manager or pyenv.

After installing, close and reopen your terminal, then verify:

# Windows
python --version
python -m pip --version

# macOS / Linux
python3 --version
python3 -m pip --version

You should see a supported Python 3 release and a matching pip version.

Why?What if a tool complains about my Python version?

Packaging occasionally lags a brand-new Python release by a few months, so a library can refuse to install on the newest minor version. If that happens, install the previous minor release alongside it rather than fighting the tool. Nothing in this series needs the bleeding edge. The point of installing Python now is simply that it’s there when something asks for it.

Why?Why `python` on Windows but `python3` on macOS/Linux?

Command naming depends on the operating system, installer, and distribution. Current macOS releases expose an Apple-managed python3 for developer tools, and most Linux packaging also uses python3; neither implies that an old Python 2 is still installed as python. The official Windows installer normally provides python. Use the command shown for your platform and avoid replacing the operating system’s managed Python.

On Windows, if python isn’t found after installing, it’s usually the PATH checkbox. Reinstall and make sure it’s ticked, or add Python to your PATH through the installer’s Modify option. On macOS or Linux, verify python3 instead. Reopen the terminal before changing PATH by hand.

Step 7: Create an Azure account and install the Azure CLI

Part 2 publishes your finished blog to Azure Static Web Apps, so that walkthrough needs an Azure account and the command-line tool that talks to it. If you’re building something else, follow this step only if you plan to use Azure. A project that runs only on your computer doesn’t need an Azure account.

First, the account. Sign up at azure.microsoft.com/free.

A few things nobody tells you before you click:

• A credit or debit card is required, purely to verify you’re a real person. Microsoft places a small temporary authorization and reverses it. You are not charged unless you deliberately upgrade to pay-as-you-go or exceed the free limits.
• Prepaid and virtual cards are usually rejected for that verification.
• New accounts get $200 USD in credit, good for 30 days. Unused credit expires; it doesn’t roll over. You will not need any of it for this blog.
• Students can use Azure for Students, which verifies with an eligible school email instead of a card.

Why?Am I going to get a surprise bill for hosting a blog?

Not for what this series builds. Azure Static Web Apps has a genuine Free plan that includes web hosting, a free SSL certificate (the thing that puts the padlock next to your address), a custom domain, and one million free executions for the small newsletter function. That’s the plan Part 2 uses.

The habit worth building anyway: after you deploy, set a budget alert on your subscription for a few dollars. It costs nothing and it means Azure emails you long before anything surprising happens.

Now the tool. The Azure CLI is the az command, and it’s how both you and your deployment script talk to Azure without clicking through the portal.

• Windows: winget install --exact --id Microsoft.AzureCLI
• macOS: brew update && brew install azure-cli (requires macOS 13 or higher)
• Linux (Debian/Ubuntu): curl -fsSL 'https://azurecliprod.blob.core.windows.net/$root/deb_install.sh' | sudo bash

Full instructions, including other Linux distributions, are on Microsoft Learn.

Close and reopen your terminal, then check it landed and sign in:

az version
az login

az login opens your browser, you pick your account, and the terminal prints the subscriptions you have access to. If no browser opens, or you’re working over a remote connection, use az login --use-device-code instead: it prints a short code you type at aka.ms/devicelogin on any device.

Why?What's a 'subscription,' and why does Azure keep saying it?

A subscription is the billing container everything you create in Azure lives inside. It’s the answer to “who pays for this?” A free account comes with one, already set up, and this series never needs a second. When a command or an error message asks which subscription to use and you only have one, the answer is always that one.

Why?Why install a command-line tool instead of just using the Azure website?

You could click all of this together in the Azure portal, and plenty of people do. The problem is that clicking is unrepeatable: you can’t hand a colleague your mouse movements, and you can’t ask an AI agent to redo them next month. A command is text. It can be reviewed before it runs, saved, repeated, corrected, and explained. That’s why Part 2 hands you a script instead of forty screenshots.

Verify everything before you build

Run this checklist in a fresh terminal, using only the commands for tools you chose to install. Each should print a version or a success message, with no errors:

git --version          # e.g. git version 2.53.x
gh --version           # e.g. gh version 2.9x.x
gh auth status         # should name your GitHub account
node --version         # if using Node.js; e.g. v24.x.x
npm --version          # if using Node.js; e.g. 11.x.x
python --version       # if using Python; try 'python3' on macOS/Linux
az version             # if using Azure; e.g. "azure-cli": "2.89.x"
az account show        # if using Azure; should name your subscription

If a tool your project needs reports an error, fix it before moving on. You don’t need to install an optional tool just to complete this checklist.

On the version numbers: these were current as of August 2026. Yours will almost certainly be higher, and that’s fine. What matters is that each command returns a version instead of “not recognized,” not that it matches mine.

Keeping your local disk tidy

Everything above installs your tools locally, on your own machine. That’s a perfectly good way to work, but it comes with a gotcha I learned the hard way.

After spinning up project after project, I ran my hard drive out of space. Here’s the thing that took me too long to realize: once your code is committed and pushed to a GitHub repo, you don’t need to keep a local copy forever. The repo is the source of truth. When you’re done working on a project for a while and you’re tight on disk, delete the local folder. You can always clone it back down the moment you want to pick it up again.

Using source control through GitHub Copilot

Git is the safety net under everything you vibe code, and the good news is you barely have to operate it by hand anymore. The GitHub Copilot app gives every session its own workspace with its own branch and files, so two pieces of work in flight can’t tangle with each other. You review diffs in the session, run terminal checks there, and open or merge the pull request from the same window.

Which means most source control now happens by asking:

Commit what we just changed with a clear message, then push it.

The agent proposes the commands, you read them, you approve. That’s the loop.

You should still understand what’s happening underneath, though, because the day something goes sideways you’ll want the vocabulary. Four ideas cover almost all of it.

A commit is a labeled snapshot. It records what changed, who changed it, and when. Commit every time something works. That’s your undo button for the whole project. Ask for it in plain language, or run it yourself:

git add .
git commit -m "Add the about page"
git push

A branch is a parallel copy of your project where you can experiment without touching your known-good version. Sessions in the app already come with their own branch, so you get this without thinking about it. If the experiment works, you merge it. If it doesn’t, you abandon the branch and main never knew.

A diff shows exactly what changed, old version against new. Read the diff before you accept the AI’s work. This is the highest-value habit in this entire post, and it’s why the app puts diff review in the same window as the agent that wrote the code.

A pull request is a diff with a conversation attached. It’s how you review a batch of work before it lands on main, and it’s where GitHub Copilot code review can weigh in if you’re on a paid plan.

Why?What's the difference between staging and committing?

Staging is choosing which changes go into the next snapshot; committing actually takes the snapshot. The two-step exists so you can commit a focused set of related changes, say, just the edits to one post, while leaving unrelated work for a separate commit. git add . stages everything, which is fine most of the time. Reach for selective staging when you’ve changed two unrelated things at once and want history that still makes sense in six months.

Why?What happens if I hit a merge conflict?

A conflict happens when two changes touch the same lines and Git can’t decide which to keep. That’s common when you work across two branches or two machines. Git marks the disputed section in the file with <<<<<<< and >>>>>>> markers and waits for you.

This is a great thing to hand straight to the agent: point it at the file and ask it to explain both sides before you choose. It sounds alarming the first time and it really isn’t.

Why?Can I see the history of one specific file?

Yes. For a blog post, git log --follow -p path/to/post.mdx walks the saved changes to that file, newest first, with the diffs inline. Replace the path with any file in your project. Or ask: “show me every change to this file and summarize what changed.”

Between the agent writing the code and Git recording every step, source control stops being a chore and becomes what it should be: a constant, low-effort safety net you’ll be glad exists the first time something breaks.

Scaffold a home for your agents and skills

You shouldn’t have to explain your project’s rules every time you start a session. Instructions give Copilot that standing guidance; agents give it a specialized role, like a code reviewer or blog editor; skills give it a repeatable task, like checking a change or drafting a post.

Where you save those files decides where they’re available. Use the project’s .github folder for guidance that belongs with the project. Use .copilot in your user home folder for personal guidance you want across projects. They are not interchangeable folder names.

Project-specific: .github inside your project folder

Put .github at the repository root, the top-level folder of your project, not inside a folder of code or content. For example, if your project lives at C:\projects\your-project, its project guidance goes in C:\projects\your-project\.github:

your-project\
└── .github\
    ├── copilot-instructions.md   # always-on context about THIS project
    ├── instructions\            # rules scoped to certain files
    ├── agents\                  # custom agents (*.agent.md)
    └── skills\                  # one folder per skill, each with SKILL.md

This is where project rules, commands for checking your work, and specialized agents belong. For a blog, that includes tone and a publishing checklist. Commit and push these files with the project so someone who clones it (downloads a working copy) gets the same guidance. A different project gets its own .github folder; this one doesn’t set rules for every repository on your machine.

.github isn’t only for Copilot. It also holds GitHub features such as .github\workflows, the automated jobs we’ll use to publish in Part 2.

Personal across projects: .copilot inside your home folder

Your home folder is separate from the project. The default personal Copilot folder is ~/.copilot, which on Windows is typically C:\Users\yourname\.copilot:

C:\Users\yourname\.copilot\
├── copilot-instructions.md      # your preferences across projects
├── agents\                     # your reusable personal agents
└── skills\
    └── my-skill\
        └── SKILL.md

Why?What does `~` mean?

~ means your user home folder, not the project you currently have open. On Windows, run $HOME in PowerShell to see the actual path; don’t guess it from your email address. On macOS it’s usually /Users/yourname, and on Linux /home/yourname. Documentation often uses forward slashes, so ~/.copilot/agents means the agents folder inside your personal .copilot folder.

Use this for preferences like “explain commands before running them” or an agent you want available for every project. Global here means your user account on this machine, not every user, every computer, or everyone who opens your repo. These files don’t travel with a Git push, and GitHub Copilot cloud agent won’t automatically receive files from your home folder.

GitHub documents these personal and project locations for instructions, agents, and skills in GitHub Copilot CLI. Other Copilot surfaces can differ in what they load. The CLI combines applicable personal and project instructions; don’t rely on one file overriding a conflicting rule in the other.

Don’t create your-project\.copilot as a substitute for the project’s .github folder, or copy your whole home .copilot folder into the repo. It can also contain local settings and session data that don’t belong in source control.

Why?Where does `~/.agents/skills` fit?

It’s another supported personal skills location in GitHub Copilot CLI, useful if you also use tools that recognize it. You can use either ~/.copilot/skills or ~/.agents/skills; you don’t need a copy in both. If you already set up ~/.agents/skills, keep it. The leading ~ matters: .agents/skills inside a repository is project-specific, not global.

You don’t need to author anything elaborate yet, and you don’t need to create the folders by hand either. Start a session in the GitHub Copilot app and ask it to scaffold (create the starting folder structure) for you:

Find my actual user home folder. Create personal agents and skills folders
at ~/.copilot/agents and ~/.copilot/skills, not inside the current project.
If I already have ~/.agents/skills, keep using that for skills instead.
Create only missing folders; don't change existing files or add any yet.
Show me the full paths and the command for my operating system, then wait
for my approval before running it.

Check that the proposed paths start with your home folder, not your project folder. Approve the command only after you’ve read it.

Why?Why did I have to ask it to show me the command first?

Because I wanted you to see the approval step at least once. Agents can be configured to run some commands without stopping to ask, which is a reasonable trade once you trust a workflow, but it’s a terrible default while you’re learning what the tool will do. Asking to see commands before they run costs you a few seconds and teaches you to read what’s about to happen to your machine.

That’s the personal library ready. Create the project-scoped .github files once you have a project to describe. Part 2 shows this for the blog; for another project, ask Copilot to read its files and draft instructions that fit what you’re building.

Why?Where do NEW skills go later?

Use ~/.copilot/skills/my-skill/SKILL.md (or your existing ~/.agents/skills/my-skill/SKILL.md) for a personal skill. Use your-project\.github\skills\my-skill\SKILL.md for one that belongs with a project. A blog-specific publishing checklist belongs in the latter. Avoid editing any tool-managed or “bundled” skill folders. Those get overwritten when the tool updates.

If you want to go deeper on plan mode, picking a model, and how skills change the way you work, that’s all in the vibe coding lessons post.

Vibe coding safely (whatever you’re building)

AI will happily run terminal commands and rewrite files for you. That’s powerful and occasionally dangerous. A few habits keep you out of trouble:

• Commit early and often. Every time something works, save it to Git. It’s your undo button for the whole project.
• Work on a branch for anything risky. Branches let you experiment without touching your known-good version.
• Read commands before you approve them. If the AI wants to delete files or run something you don’t recognize, slow down and ask it to explain first.
• Never put secrets in your code. API keys and passwords belong in environment variables or a secrets store, never committed to the repo, which may become public.

Why?Why does this matter for a small personal project?

Even a blog or a small tool can expose a password or delete a file you need. Start with something small and practice saving changes, using branches, and reviewing what the AI does. Those habits carry into your next project.

Make security the AI’s default, not an afterthought

The habits above keep you safe. The next step is making sure the code the AI writes is safe too, because an AI left to its own devices will happily reach for whatever pattern was most common in its training data, and “most common” is very often “least secure.” Hard-coded connection strings, public storage accounts, keys in config files, wide-open CORS. It’s not malicious; it just doesn’t know your bar unless you set it.

You set that bar by grounding the AI in real security guidance and making that guidance the highest priority in every instruction, skill, and agent you use. Three levers do most of the work:

• If you’re using Azure, wire up the Azure MCP and use its best-practices tool. The Azure MCP server ships a built-in Azure best-practices capability the AI can call before it writes or deploys anything that touches Azure. It returns secure, production-grade guidance: managed identities instead of connection strings, Key Vault for secrets, least-privilege role assignments, private networking, and secure defaults, grounded in current Microsoft recommendations rather than whatever the model half-remembers. Ask the AI to “check Azure best practices first” and it’ll pull that guidance in before generating code.
• Pair it with the Microsoft Learn MCP so security and identity guidance comes straight from the current official docs, including Entra ID, Defender, and Azure security baselines, instead of stale training data.
• Lead with security in your own instructions, skills, and agents. When you create your project’s .github files, put security first in copilot-instructions.md: least privilege, no secrets in code, managed identities, input validation, secure defaults. A short, explicit “security comes first” rule at the top of your instructions steers every response after it.

Why?What's a 'security-focused skill or agent'?

It’s a reusable instruction set whose whole job is to hold the AI to a security bar. You can create a security-review skill that runs a checklist before you ship: secrets scanning, dependency risk, auth and access review, and input validation. Or you can create a dedicated security-review agent you hand a diff to for a second opinion. The point is the same as any skill: promote your best “did we do this securely?” prompts into a permanent capability the AI applies every time, instead of hoping you remember to ask.

Why?Why put security at the *top* of my instructions?

Instructions are read top to bottom, and earlier rules carry more weight when the AI has to make a trade-off. If “ship it fast” sits above “do it securely,” guess which one wins under pressure. Leading with least privilege, no hard-coded secrets, and secure-by-default patterns makes security the lens everything else is filtered through, not a box you check at the end.

The vibe-coding-specific risks worth knowing

Classic web vulnerabilities still apply, but AI-generated code adds a few failure modes of its own. These are the ones I’d burn into your habits from day one:

• Never ship code you don’t understand. Keep a human in the loop. The AI optimizes for “this runs,” not “this is safe.” If you can’t explain what a block does, don’t merge it. Ask the AI to walk you through it first.
• Verify every dependency before you install it. Models hallucinate package names, and attackers register those made-up names with malware inside (“slopsquatting”). Before you npm install anything the AI suggests, confirm the package is real, actively maintained, and spelled exactly right. Then pin the version and commit your lockfile.
• Ask for security explicitly in the prompt. Don’t assume the AI will validate input, apply least privilege, or avoid hard-coded secrets on its own. Say so. “Follow secure coding practices, validate all input server-side, no secrets in code” costs you one sentence and changes what you get back.
• Let a scanner watch your back. Turn on secret scanning and dependency alerts (GitHub gives you both for free), and run them automatically, not just when you remember. A scanner catches the leaked key or vulnerable package you’ll eventually miss by eye.
• Treat tool and web output as untrusted. Content the AI pulls from a webpage, a file, or an API can carry hidden instructions (prompt injection). Never let something the AI read trigger something risky it then does without you confirming it.

Why?What's 'slopsquatting' and why should I care?

When an AI invents a package name that doesn’t exist, an attacker can register that exact name and fill it with malicious code, so the next person who trusts the AI’s suggestion installs malware. It’s a real, growing supply-chain attack. The fix is cheap: don’t install anything you haven’t confirmed is the genuine, maintained package. That applies whether you’re building a blog, an app, or a small tool for yourself.

Steal a ready-made security skill

Everything above is easier to enforce when it’s written down as a skill the AI pulls in automatically. This repo ships one you can copy: a vibesec-skill under .github/skills/ that captures secure-coding practices across access control, XSS, CSRF, secrets, SSRF, file uploads, SQL injection, JWTs, and the AI-specific risks above, and tells the AI to treat security as the highest priority and fail closed when it’s unsure.

Put the whole vibesec-skill folder, including its SKILL.md, in your project’s .github/skills/ to share it with that repo. Use ~/.copilot/skills/ or ~/.agents/skills/ to keep it personal across projects. Ask Copilot to use vibesec-skill when building a web app or reviewing its security.

Why?Do I have to write that skill myself?

No. That’s the whole point of skills being portable files: grab an existing one, drop it in, and it just works. Refine it over time as you learn your own bar. When you catch a security lesson the skill doesn’t cover yet, add a line. Future you (and the AI) inherit it automatically.

What you should have right now

Before building, check the essentials below. The Node.js and Azure items are needed for the blog walkthrough in Part 2; Python depends on your chosen tools.

• ✅ A GitHub account with a verified email and 2FA enabled, and your recovery codes saved somewhere safe.
• ✅ Git installed and configured with your name, email, and init.defaultBranch set to main.
• ✅ gh auth status reports you’re logged in, and Git is set to reuse those credentials.
• ✅ The GitHub Copilot app installed, signed in, and responding.
• ✅ The tools your project needs return versions in a fresh terminal: git and gh, plus node and npm if using Node.js, and python (Windows) or python3 (macOS/Linux) if using Python.
• ✅ If using Azure: an account created, az version returns a version, and az account show names your subscription.
• ✅ A personal agents folder at ~/.copilot/agents and a skills folder at ~/.copilot/skills (or ~/.agents/skills), outside your project.
• ✅ You know that .github belongs inside each project, while your home .copilot folder is personal across projects on this machine.
• ✅ You understand the safety basics: commit often, branch for risk, no secrets.
• ✅ Your project guidance puts security first, with Azure and Microsoft Learn documentation available to the AI if you’re using those services.
• ✅ You’ve internalized the vibe-coding risks: review what you can’t explain, verify every dependency before installing, and let a scanner watch your back.

If something your project needs isn’t ready, sort it out before building. Leave the optional tools for when you need them.

Next: actually building the thing

If you want a blog, follow Part 2 to create it with Astro, give Copilot project instructions, and publish it to Azure.

If you want to build something else, skip installing Astro and the blog template. The later publishing commands in Part 2 are specific to that blog setup, not universal instructions for every app. Open your own project in Copilot and start with a small, concrete request:

I want to build [describe your idea] for [who will use it].
Help me plan the smallest useful version. Ask about anything unclear,
explain which tools it needs and why, and put security first.
Don't install anything or change files until I've reviewed the plan.

Replace the brackets with your idea. Start with one thing you can try yourself, then review what Copilot made before asking for the next change.