Build a Personal Work Wiki — with Copilot on Windows 11

Why this matters

The facts your job actually runs on are written down nowhere a program can read. They are in your head, in Teams threads, in a OneNote you last opened in March, and in two colleagues' memories.

Treat this as a work skill you are required to learn, not a productivity hobby. AI agents are standard equipment now, and the gap between the people who get real value from them and the people who get plausible nonsense is not prompting technique. It is whether the agent has anything true to read — whether somebody has maintained its state, because it forgets everything between sessions and you are the only one who can write it down. A personal work wiki is the cheapest and most durable way to give it that — plain files, no vendor, no subscription, portable across every tool you will use for the rest of your career.

01Set it up

Half an hour, once. Everything here is plain text and standard tooling — nothing proprietary, nothing that needs a plugin to render.

1. Install the tools. From an admin Windows Terminal:

   winget install Microsoft.PowerShell   # pwsh 7 — Copilot CLI needs 6+, Win 11 ships 5.1
   winget install Git.Git
   winget install GitHub.Copilot         # the CLI
   winget install Obsidian.Obsidian      # optional, a pleasant reader for the files

   Run everything below from pwsh, not the built-in powershell.
2. Pick a location outside OneDrive. %USERPROFILE%\work-wiki. A syncing folder will lock a file mid-write and corrupt exactly the one you are editing. If your Documents folder is redirected to OneDrive — the Windows 11 default — do not put it there.
3. Create the skeleton.

   cd $env:USERPROFILE
   mkdir work-wiki\raw, work-wiki\wiki
   cd work-wiki

   Path	Holds
   index.md	The catalogue — every page, one line each, grouped
   log.md	Append-only. What you did and learned, newest at the top, always dated
   raw/	Source material pasted in verbatim and never edited — emails, chat threads, error dumps
   wiki/	Your distilled understanding. One concept per page, named for the concept

4. Put it in git. Local-only is fine; a private remote is better.

   git init
   "*.tmp`n.obsidian/workspace*" | Out-File -Encoding utf8 .gitignore
   git add -A; git commit -m "wiki: skeleton"

5. Write index.md. Group by kind, one line per page, and link by filename:

   # Work wiki index
   
   ## Systems
   - [[Build Pipeline]] — how it runs, where it runs, who owns it
   - [[Test Rig 3]] — the harness, its quirks, the calibration procedure
   
   ## Decisions
   - [[Why We Dropped Framework X]] — 2026-03, and what we chose instead
   
   ## Runbooks
   - [[Quarterly Certificate Renewal]] — the one you do four times a year and never remember

6. Write log.md with a single entry. One heading per day, newest first:

   # Log
   
   ## 2026-08-22
   - Chased the nightly failure to a clock skew on the build box. See [[Build Pipeline]].
   - Asked Priya who owns the signing cert — it's Platform, renewed each March.

7. Write your first three pages. Do not start with a blank plan. Write the three you have already explained to someone twice this year — those are the ones with real value. The test for what belongs: would a competent new colleague have to ask someone?

   Write down	Because
   Every machine, host and service you touch, and how you reach each one	"Which box runs the nightly job?" should never cost ten minutes again
   Decisions, and the reasoning behind them	Git records what changed; nothing records why you rejected the alternative
   Runbooks for anything you do less than monthly	You will not remember. You never do
   Where tickets, dashboards, docs and secrets live	An agent can then be pointed at them
   People, teams, and who owns what	Half of "how do I ship this?" is knowing who to ask
   Traps, and the incident that proves them	The build flag nobody may change, and why

   Never credentials. Record where a secret lives and how it is obtained — Credential Manager, the vault, the environment variable — never the value. This is a file an agent will read, quote back, and possibly paste into a pull request.
8. Tell Copilot the wiki exists. Create work-wiki\AGENTS.md:

   # Work wiki
   
   Plain markdown. `index.md` is the catalogue — read it first.
   `wiki/` is distilled understanding; `raw/` is unedited source material, treat as evidence.
   `log.md` is dated history, newest first.
   
   Cite the page you used. If a page is wrong, say so rather than working around it.

   Then add one line to the AGENTS.md of every repository you work in:

   Work wiki: %USERPROFILE%\work-wiki — hosts, decisions and why, runbooks,
   who owns what. Read it before asking me about infrastructure.

9. Verify it can actually read it. Start Copilot inside the wiki, or bring the wiki into a session in a code repository:

   copilot                              # from inside work-wiki
   copilot --add-dir $env:USERPROFILE\work-wiki   # from anywhere else
   

   Read index.md, then tell me in one sentence what this wiki is about
   and list any page referenced in the index that does not exist.
   If it answers accurately, you are done. If it cannot find the files, the path in AGENTS.md is wrong — fix that before writing another page.

02Four rules

These are the difference between a wiki and a junk drawer. All four have the same cause: trust. The moment you stop believing the wiki, you stop reading it, and it is dead.

1. One concept per page, named for the concept. Links resolve by filename, so Build Pipeline.md is reachable from anywhere as [[Build Pipeline]]. Never "notes 3.md".
2. The index never lies. Add a page, index it in the same sitting. An index that is 80% accurate is worse than none.
3. Raw is immutable. Pasted source goes in raw/ and is never edited — it is evidence. Your interpretation goes in wiki/ and can be corrected freely.
4. Distil, do not hoard. If a page is a transcript, it is not finished. A wiki is understanding; raw/ is for the clippings.

03Use it every day

Three habits, about seven minutes a day in total. Two of them are prompts you paste; the third is the one that actually matters.

Morning — two minutes

1. Open the wiki session: copilot --add-dir $env:USERPROFILE\work-wiki.
2. Ask for your own context back:
   Read log.md. Summarise what I was doing in the last three entries,
   and list anything I said I would follow up on but have not logged since.

During the day — as it happens

1. Every time you work something out, write it down before you move on. That is the entire discipline. Not later, not at the end of the sprint — before you move on, while you still know why.
2. Paste raw evidence straight into raw/ with a dated filename: raw/2026-08-22-build-failure.txt. Do not clean it up.
3. Let the agent do the writing. You supply the facts, it supplies the prose and the links:
   I just found that the nightly build fails when the build box clock
   drifts more than 30s from the signing server. Draft a wiki page for
   this, cite raw/2026-08-22-build-failure.txt, and give me the one line
   to add to index.md.

End of day — five minutes

1. Append today's entry to log.md — three bullets is plenty. Dated, always.
2. Have the agent check your work:
   Compare today's log entry against index.md. Is anything I learned
   today missing a wiki page? List candidates, do not write them yet.
3. git add -A; git commit -m "wiki: $(Get-Date -f yyyy-MM-dd)". The commit history becomes a second, automatic log.

04What it knows when it starts — global and per-folder memory

Type copilot in a folder and, before you say a word, the agent has already read three things: what it remembers about you, what this folder says about itself, and the wiki, if either of those points at it. Knowing which layer holds what is most of the skill.

What happens at startup

1. It loads your personal layer from %USERPROFILE%\.copilot — your custom agents, your MCP servers, and the memory it has accumulated about you. This is the same in every folder.
2. It reads the folder's instruction files. AGENTS.md in the current directory and its parents, and .github\copilot-instructions.md if this is a repository. This is what makes the same agent behave differently in two folders.
3. It trusts the current directory and nothing else. Anything outside — the wiki, a sibling repo — is invisible until you add it with --add-dir or name it in AGENTS.md.
4. Check what it found before assuming. Ask in the first turn: "what instructions and memory are you working from right now?" If the wiki is not in the answer, step 2 or 3 is missing.

Layer 1 — global memory: you and your setup

1. What goes here: facts that are true in every folder. Your OS, shell, editor, where the wiki is, how you like answers. Copilot's memory is shared across the CLI, the cloud agent and code review, so one statement follows you everywhere.
2. Add something — say it plainly, as a standing fact, not a request:
   Remember this about me, permanently: I am on Windows 11 and use pwsh 7 in
   Windows Terminal, never cmd. My work wiki is at %USERPROFILE%\work-wiki —
   read index.md before answering questions about infrastructure. Give me
   the command first and the explanation after.
3. Remove something the same way — name the fact and say it is gone:
   Forget that I use Visual Studio 2022. I have moved to Visual Studio 2026;
   remember that instead.
4. Verify in a fresh session, in a different folder. "What do you remember about how I like to work?" If the fact is missing, it did not take — repeat it, or put it in a file (step 5). Never assume memory worked.
5. Back the important ones with a file you own. Memory is opaque; you cannot open it in an editor. So the wiki pointer and anything you would be upset to lose also go in your personal %USERPROFILE%\.copilot config and in the wiki's own AGENTS.md. Then it is found whether memory is working or not.

Layer 2 — per-folder memory: this project

1. Every folder can have its own AGENTS.md. It is read only when you start the agent in that folder or below it. Nothing in it leaks into other projects. This is the per-folder memory, and unlike global memory it is a plain file you control completely.
2. What goes here: how to build and test this code, its traps, its owners, which wiki pages are about it — and the one-line wiki pointer from section 1.
3. Add something: edit the file, or have the agent do it — "add to this folder's AGENTS.md that the integration tests need the VPN up". Commit it; the whole team then inherits the memory.
4. Remove something: delete the line. That is the entire procedure, and it is why files beat memory for anything that matters.
5. Nested folders stack. An AGENTS.md in C:\src applies to every project under it; one in C:\src\billing adds to it. Use the parent for team-wide rules and the child for the project's own.

05Set up your laptop to win

An agent is only as capable as the machine it runs on. Ten minutes of installs turns "I can only read what you paste" into "I can convert, search, OCR and query it for you".

Work in the terminal, not the chat box

A chat window can only see what you paste. A terminal agent can run things — which is the whole reason the wiki and CLI sections exist. Make the CLI your default surface for anything that touches files or systems, and use the IDE chat for the code in front of you.

1. PowerShell 7 is the native Windows choice. Objects in, ConvertTo-Json out, and every Windows cmdlet available. Install it with winget install Microsoft.PowerShell and make it the default profile in Windows Terminal.
2. WSL is the Linux option, and a good one. wsl --install gives you Ubuntu with the whole Unix toolbox — grep, sed, jq, pandoc from apt, and every tutorial on the internet works unmodified. Your Windows drive is at /mnt/c/. Keep the wiki on the Windows side (/mnt/c/Users/you/work-wiki) so both shells and Obsidian see the same files.
3. Pick one and be consistent. Agents do better when every command in your wiki is in the same dialect. Mixed PowerShell and bash in Queries.md is a recipe for the agent running the wrong one.

Tools your agent can put to work

Every one of these is a command the agent can call on your behalf. Install what you need; tell the agent it is there by listing it in wiki/Tools.md.

06Connect live data — the CLI

The wiki covers what you know. This covers what your systems know. The mechanism is one insight: an agent with a shell can query anything that has a command line.

Pasting is the worst option available — stale the moment you do it, truncated, and impossible to repeat. A command is live, complete, and the agent can run it again with different arguments.

1. Install the CLI for each system you care about. Each one turns an opaque system into something an agent can read:

   Tool	Makes readable
   gh	Issues, pull requests, checks, releases, Actions logs
   az / aws	Cloud resources, deployments, configuration, logs
   dotnet	Project graphs, package versions, outdated dependencies, test results
   sqlcmd / psql	The actual data, and the actual schema
   kubectl	Cluster and workload state
   Get-WinEvent, Get-Service	The real state of Windows, not a guess about it
   git log, git blame	Why the code is the way it is

2. Pipe PowerShell through ConvertTo-Json. This is the Windows advantage and most people miss it — cmdlets emit objects, not text, so the model parses them exactly instead of guessing at column alignment:

   Get-Service | Where-Object Status -eq 'Running' | ConvertTo-Json -Depth 3
   Get-WinEvent -LogName System -MaxEvents 50 | Select TimeCreated,Id,Message | ConvertTo-Json

3. Record the useful commands in the wiki. A wiki/Queries.md page of working one-liners is worth more than any of them individually, because next time the agent reads it and runs the right one unprompted.
4. Teach it your internal tooling by pointing at the help. No model has seen your company's CLI, and it does not need to:
   Use `ourtool --help` to learn the tool, then use it to list every
   service that missed its SLA last week and summarise the causes.
5. Use read-only credentials wherever the work is read-only. A role that cannot delete anything is far more reliable than an instruction not to.

07Connect live data — MCP servers

Where no CLI exists, an MCP server exposes a system to the agent the same way a CLI would. The judgement is simple: if there is a CLI, use it; if not, look for an MCP server; if neither exists, that system is invisible to your agents — and you should know which ones those are.

1. Add a server to the Copilot CLI:

   copilot mcp add --transport http NAME URL

   The GitHub MCP server is preconfigured. VS Code and Visual Studio read their own MCP configuration; the same servers work across all of them.
2. Prioritise the systems that hold answers your repository cannot give: the issue tracker, the observability stack, the wiki or docs platform your team actually uses, the ticketing system.
3. Record every server you add in the wiki — one page listing what each exposes and what it is good for. Six months on, you will not remember why you added it.
4. Consider a Space for questions your team keeps asking. Copilot Spaces are curated context containers on github.com built from repositories, files, issues and free text. They respect existing permissions — nobody sees a source they could not already read.
5. Correct memory deliberately. Copilot's memory is shared across the CLI, the cloud agent and code review, so a wrong fact there becomes durable. When it has learned something false, say so explicitly rather than working around it — and fix the wiki page that let it happen.

Ask for things you did not know you could ask

Once a system is connected, the agent can do work with it, not just answer questions — and it can write the results into the wiki so they become state. Most people never try, because nobody told them the sentence was allowed. It is:

1. Connect the mailbox first — an MCP server for Microsoft 365 / Outlook or Gmail, or a CLI if your organisation has one. If neither is available, the sentence above will fail politely; that is how you find out which systems are still invisible.
2. Make it a standing habit, not a one-off. Run the same prompt each morning and the log compounds: in December it is a dated record of every request anyone made of you this year — which is section 10's annual review, written by itself.
3. The same sentence works for anything connected: "read this week's tickets assigned to me and update wiki/Current Work.md", "log every deployment from the pipeline into wiki/Deployments.md", "check the on-call channel and list anything that mentions our service". Data in, wiki page out, state maintained.
4. Keep the guardrail. Reading and logging is safe; sending, replying and deleting are not. Say "do not send, reply or delete anything" in the prompt until you trust the setup, and prefer read-only access tokens where the service offers them.

08Go big — map an entire ecosystem

The same method scales from one page to a whole system. Pull a dozen repositories onto your machine, have the agent read every one and write the wiki, then ask questions of the whole thing. This is how you understand a system nobody on the team understands end to end.

1. Clone everything into one folder, outside the wiki. Code is not evidence and does not go in raw/; it gets its own tree:

   mkdir $env:USERPROFILE\eco; cd $env:USERPROFILE\eco
   'gateway','auth','billing','orders','inventory','notify',
   'web','mobile','infra','schemas','tools','docs' |
     ForEach-Object { gh repo clone "your-org/$_" }

2. Give the agent a brief, not a question. Write it once in wiki/eco/BRIEF.md so every pass produces the same shape of page:

   # For each repository write wiki/eco/<repo>.md with these headings:
   Purpose (two sentences) · Entry points · How to build and test ·
   Talks to (other repos, queues, databases, external APIs) ·
   Depended on by · Owners (from CODEOWNERS) · Traps and TODOs found in the code ·
   Open questions. Cite file paths for every claim.

3. One repository per session. Twelve repos in one context window is how you get a confident summary of nothing. Loop instead — each run starts clean, reads one repo and the brief, writes one page:
   Read wiki/eco/BRIEF.md. Analyse the repository at eco/billing and
   write wiki/eco/billing.md to that template. Do not guess at what other
   repos do — write "unknown, see <repo>" and move on.
4. Then synthesise — this is the pass that pays. With twelve pages written, one session reads only the pages, not the code:
   Read every page in wiki/eco/. Write wiki/Ecosystem.md: a Mermaid
   diagram of which repo calls which, the path of an order from the web
   app to the invoice, every shared schema, and a list of contradictions
   between what two pages claim. Add all new pages to index.md.
5. Now ask the questions you could never ask before.
   If we change the currency field in schemas/money.proto, which repos
   break, in what order do they need to deploy, and who owns each one?
   The answer comes with file paths and owners because the brief demanded them.
6. Keep it current. The repos move; the wiki must follow. Monthly, or before any big change:

   Get-ChildItem $env:USERPROFILE\eco -Directory | ForEach-Object { git -C $_.FullName pull -q }

   For each repo in eco/, run `git log --since="30 days ago" --stat`,
   then update the matching wiki/eco/ page and note what changed in log.md.

09Go to the agent first — the reflex

The habit that separates people who get value from this from people who do not is embarrassingly simple: for any task, start in the terminal with the agent, before you open the browser, Outlook, Excel or a blank document. Not because it will do everything — because it will do the first 60% of almost everything, and it knows your wiki.

1. Make the rule mechanical. For one week, every task starts with the agent — even the ones you are sure it cannot do. You will be wrong about a third of them, and those are the ones that change how you work.
2. Ask for the task, not the tool. Do not ask "how do I make a pivot table"; ask "here is the CSV, tell me which suppliers' lead time got worse this quarter". Let it pick the tool. It has mlr, pandoc and PowerShell; you gave it those in section 5.
3. Always say where the output goes. "…and write it to wiki/Suppliers.md, indexed" turns an answer into state. An answer in the chat scrollback is gone tomorrow; a page is there in December.
4. Feed it your own evidence. The wiki, the log, the raw folder and the connected systems are what make the answer yours rather than generic. "Using log.md and the last month of tickets…" beats any clever prompt.

Things people do not think to ask for

Every one of these is a real sentence that works. The pattern is the same each time: source → task → where to write it.

10What it pays for

Three everyday cases where a wiki plus live data beats memory, search and colleagues combined.

Troubleshooting

1. Dump the evidence into raw/ — the log, the stack trace, the failing output, unedited.
2. Ask with both halves connected:
   Read raw/2026-08-22-nightly.log. Search the wiki for anything we've
   seen like this before, then run `Get-WinEvent -LogName System
   -MaxEvents 100 | ConvertTo-Json` on the build box and correlate
   the timestamps. Cite the wiki pages you used.
3. When you find it, write the page before you fix it. The fix is fresh for an hour; the page lasts.
4. Next time, the first answer is "we have seen this — see [[Build Pipeline]]" and you are ten minutes ahead instead of ninety.

Remembering an old technical email or chat comment

1. The moment a message decides something — a limit, an owner, a "do not ever do X" — paste it verbatim into raw/ with a dated filename and the sender. That is the whole habit.
2. Distil it into a wiki page the same day, cross-linking the raw file as the citation.
3. Months later, ask in English rather than trying to guess the search keyword:
   Someone told me the firmware team caps the telemetry packet at
   512 bytes and there was a reason. Find it in raw/ and wiki/,
   quote the original message, and tell me who said it and when.
4. You get the quote, the author and the date — which is what actually settles the argument, and what mail search never gives you because you cannot remember a single word of the original.

Your annual review

1. This one is why the dating discipline matters. log.md plus git log is a complete, timestamped record of your year that you did not have to reconstruct in a panic in December.
2. Pull the raw material:
   Read log.md for the whole of this year. Group everything into
   themes, and for each theme list the concrete deliverables with
   dates. Flag anything that looks significant but has no follow-up.
3. Add the evidence your systems hold — this is where the CLI earns its place:

   gh search prs --author "@me" --created 2026-01-01..2026-12-31 --json title,url,closedAt
   git log --author="your.name" --since=2026-01-01 --pretty=format:"%ad %s" --date=short

4. Ask it to write against your actual review criteria, not generic ones:
   Here are my review criteria. Using the themes from log.md and the
   PR list, draft one paragraph per criterion. Every claim must cite
   a dated log entry or a PR — if you cannot cite it, leave a gap
   and tell me what evidence is missing.
5. The gaps it reports are the real output. They are either work you did and failed to record, or a criterion you genuinely did not serve this year — and both are worth knowing in November rather than at the meeting.

11Your first week

1. Today. Section 1, all nine steps. Three pages, one log entry, one commit. Half an hour.
2. Tomorrow. Tell the agent what to remember (section 4) and confirm it stuck. Add the wiki line to the AGENTS.md of the repository you are actually working in. Ask the agent one real question about your own infrastructure and see whether it answers from the wiki.
3. Rest of the week. Every task starts with the agent (section 9), no exceptions, even the ones you are sure it cannot do. Log every day, even on the days with nothing to say. Write a page whenever you explain something to somebody.
4. Next week. Install pandoc, rg and jq from section 5, and one CLI from section 6; add their useful commands to wiki/Queries.md. Add one MCP server if a system you need has no CLI.
5. The month after. Pick the system you understand least, clone its repositories, and run section 8. One weekend; it changes how you see your job.
6. Then leave it alone and keep feeding it. The wiki is only worth something at the moment you need it, which is months after you wrote the page. There is no way to short-cut that, which is exactly why so few people have one — and why having one is worth this much.