Build a Personal Work Wiki — with Grok Build 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 Windows Terminal:

   winget install Git.Git
   winget install Obsidian.Obsidian      # optional, a pleasant reader for the files
   irm https://x.ai/cli/install.ps1 | iex   # Grok Build

   The installer adds %USERPROFILE%\.grok\bin to your PATH. Access comes with SuperGrok or X Premium+, or set XAI_API_KEY from console.x.ai.
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 Grok the wiki exists. Grok Build reads AGENTS.md natively — the same file Claude Code, Copilot and Cursor read, which is why it is worth investing in. 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. Run Grok from inside the wiki, and check discovery before anything else:

   cd $env:USERPROFILE\work-wiki
   grok inspect      # what config, instructions, skills and MCP servers were found
   grok              # the TUI

   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.
   Run grok inspect first, every time you try it somewhere new. It answers the only question that matters at the start — did it find my conventions? — and it is the fastest way to discover your AGENTS.md is in the wrong place.

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 a session in the wiki: cd $env:USERPROFILE\work-wiki; grok.
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.
4. Use plan mode when you want it to survey the wiki without touching it. Grok's plan mode is read-only except for the plan file — edits to any other file are rejected outright, in every permission mode. It is the safe way to say "tell me what you would change".

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 grok 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%\.grok — config.toml, your skills, roles and personas, MCP servers, and the global memory file if memory is on. This is the same in every folder.
2. It reads the folder's instruction files. AGENTS.md in the current directory and its parents (it also honours CLAUDE.md and .claude/ settings, so Claude Code configuration works untouched). This is what makes the same agent behave differently in two folders.
3. It works out which workspace this is. Identity is the git origin remote in org/repo form, falling back to the directory path — and that decides which per-workspace memory directory it opens.
4. Run grok inspect to see exactly what it found. Config sources, instruction files, skills, plugins, hooks and MCP servers, listed. If the wiki pointer is not in that output, the agent does not know the wiki exists.

Layer 1 — global memory: you and your setup

1. Switch it on — it is off by default. In %USERPROFILE%\.grok\config.toml:

   [memory]
   enabled = true

   ($env:GROK_MEMORY=1 for one shell; /memory on for one session.)
2. What goes here: facts that are true in every folder. Your OS, shell, editor, where the wiki is, how you like answers. It lives in %USERPROFILE%\.grok\memory\MEMORY.md — plain markdown, loaded in every session.
3. Add something — say it plainly, as a standing fact, then confirm it landed in the file:
   Remember globally: 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.

   Get-Content $env:USERPROFILE\.grok\memory\MEMORY.md

4. Or just edit the file. It is yours. Open MEMORY.md, add a line, save. Faster than asking, and you know exactly what it says.
5. Remove something: delete the line from MEMORY.md, or tell it — "forget that I use Visual Studio 2022; I am on 2026 now" — and check the file afterwards.

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. A plain file you control completely — grok inspect confirms it was picked up.
2. Every workspace also gets its own memory directory under %USERPROFILE%\.grok\memory\, with its own MEMORY.md and session summaries. That is where things Grok learns while working in this repo accumulate. Because identity is the origin remote, a second clone of the same repo shares it — occasionally surprising when a scratch clone inherits opinions.
3. What goes in AGENTS.md: 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. Commit it; the whole team inherits the memory, and so does every other vendor's agent.
4. Add something: edit the file, or "add to this folder's AGENTS.md that the integration tests need the VPN up". Remove something: delete the line. For the workspace memory directory, the same — open its MEMORY.md and edit.
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. Set the approval mode deliberately. grok --permission-mode auto stops the prompt fatigue that makes people approve everything by reflex, and deny rules still apply on top of it. Turn remember_tool_approvals on in ~/.grok/config.toml so a command you have blessed once stops asking.
6. 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 — and on Windows it is your main structural guard, since the sandbox is not there.

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. Manage servers from the TUI: /mcps. Grok Build also picks up MCP servers already configured for Claude Code, so anything you set up there works here untouched.
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. Watch what they cost you. Run /context: it itemises the fixed overhead — tool definitions, the skills listing, MCP announcements — which is the honest answer to why a fresh session already feels full. Servers you never use are pure tax.
5. Memory is optional and off by default. Enable with GROK_MEMORY=1 or [memory] enabled = true; it stores plain markdown under ~/.grok/memory/. Useful, but the wiki is the durable record — memory is a convenience, not the archive.

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, then run grok inspect there to confirm it was found. Ask 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.