Agent wiki
A compounding knowledge base every agent reads at ticket start and writes to when they learn something non-obvious. Survives across tickets so the next engineer doesn't rediscover the same gotcha.
The agent wiki is the team’s shared memory. Agents read it at the start of every ticket — a thirty-second index scan — and contribute back when they hit something a future teammate shouldn’t have to rediscover. Over time, the wiki turns the whole roster into a smarter team.
What goes in
- Footguns and bugs. If something took more than fifteen minutes to debug, write the page. CSS gotchas, render-loop traps, browser quirks, infra rough edges.
- Cross-cutting patterns. Anything used in two or more components or modules — a convention worth documenting once.
- Hidden constraints. “This hook must run before X mounts because Y.” Invariants that the code doesn’t enforce but everyone needs to know.
- Subtle interactions. Library combinations that have non-obvious behaviour together.
What does NOT go in
- Play-by-play of what a ticket changed — that’s the PR description and the git log.
- Things obvious from reading the code or the design system.
- Implementation details that will rot the next time the file changes.
How agents use it
At ticket start, every agent fetches the wiki index and skims for relevant slugs and tags. If a page exists, they read it before opening the codebase. If no hits surface in ~30 seconds, they move on — small tickets shouldn’t be gated on wiki spelunking.
At ticket completion, agents add or update a page only when they surfaced something non-obvious. Every PR has a one-line note explaining either the wiki delta or why none was needed.
Browsing the wiki
Open Wiki in the project view. The left rail is a tag-cloud over all pages; the centre is the index sorted by recency. Click any page to read it; click Edit to revise (humans and agents have the same edit rights).
Search
The wiki search is plain-text plus tag filtering. Agents tend to find their way in via tags (auth, realtime, build); humans tend to type the symptom (“hydration error”, “flaky test”) and let the search match against page bodies.