Documentation engineering and information architecture work, 2020 to 2026.
I build the systems that produce documentation. Some of what follows is writing. More of it is the structure, tooling, and process underneath the writing, which is the part I care about and the part I get hired for.
Every sample states plainly whether I wrote it, directed it, or designed the system that produced it. Those are different claims and they should not be blurred.
If you have five minutes and you are hiring a Documentation Engineer:
- Building a documentation system, not writing documentation — a 20-stage AI-assisted pipeline, a full Diátaxis restructure, and a documentation MCP server. The site is public and you can check every claim against it.
- Documentation work intake automation — a 23-step automation that turned an untracked request queue into routed, acknowledged work.
If you are hiring an Information Architect:
- Documentation tooling UX research — survey research on an internal wiki, with a flaw in its own measurement scale named in the report.
- Consolidating two intake forms into one — field-by-field analysis with a recorded reason for every field kept, merged, or cut.
- Scoring documentation pages for freshness — content lifecycle triage, so maintenance goes where it matters.
| Sample | What it shows | My role |
|---|---|---|
| Documentation system at Forage | AI-assisted pipeline, Diátaxis restructure, llms.txt, MCP server | Directed and built the system |
| Work intake automation | 23-step request-to-ticket automation | Designed and built |
| Sample | What it shows | My role |
|---|---|---|
| Documentation tooling UX research | Survey design, findability analysis, structural recommendations | Wrote |
| Intake form consolidation | Content modeling, field-level reasoning | Analyzed and designed |
| Page freshness scoring | Content lifecycle triage system | Wrote and built |
| Documentation lifecycle model | Process model with stage ownership | Built |
Published help center documentation. I wrote these.
| Sample | What it shows |
|---|---|
| Suspend or unsuspend a member | Technical depth, user-facing and backend behavior together |
| Get company members | Parameter tables and worked examples |
| Audit log examples | Runnable examples, pagination |
| Sample | What it shows |
|---|---|
| Formatting keyboard shortcuts | Rule-writing that survives many writers |
| Using graphics in documentation | Screenshot conventions and accessibility, kept as a PDF because the images are the argument |
Some of these are Markdown and some are not, on purpose.
Where the words are the work, the sample is Markdown. Documentation belongs in source form: it diffs, it reviews, it ships from a repo.
Where the layout or the diagram carries the meaning, the original is kept. A style guide about using graphics with no graphics in it is not a style guide. Diagrams that were originally large collaborative canvases have been rebuilt as Mermaid, so they are readable as source and render in the browser rather than being a picture of a decision.
Original source files are in assets/.
context-engineering-toolkit — the working tools: a documentation pipeline, style guides, and the architecture patterns behind them. That repo is the system. This one is the output and the reasoning.
Former employers appear here by name where the work is already public. Where it was internal, colleague names, customer identities, internal channels, and product names have been removed. The reasoning and structure are unchanged.