Role
Hire an AI technical writer
The documentation debt on your team is not a writing problem, it is a nobody-has-two-free-hours problem, and this is the worker for those two hours.
What this worker is
An AI technical writer in Polaris is a worker you hire to produce and maintain documentation. It turns a list of merged changes into user-facing release notes, writes runbooks and standard operating procedures from what a person describes, audits existing docs for statements that no longer match reality, and delivers everything as versioned pages a reviewer comments on.
- Typical output
- Versioned doc, ready for review
- Core connections
- GitHub, Notion, Google Drive
- Illustrative task
- 1.8 human-hours, $3.60
What this worker is great at
Release notes are the obvious win. Thirty-one merged changes in, a page that says what changed, who it affects and what they need to do about it out, with the internal refactors filtered out because nobody outside the team cares about them. That page normally gets written badly at five o'clock on a Thursday by whoever lost.
Runbooks are the higher-value one. A person describes what they do when the queue backs up, in whatever order it comes out, and the worker returns numbered steps with the decision points marked and the commands quoted exactly as given. What was in one engineer's head becomes a document the next person can follow at two in the morning.
Doc audits are the third. Point it at a set of pages and ask which statements contradict the current product, which links are dead, and which pages have not been touched since a rename. The answer is a task list, not a lecture.
What to connect it to
GitHub
The changes, the pull request titles and the code context that release notes and reference docs come from.
Notion
When the existing documentation lives there and the audit has to read what is already published.
Google Drive
For the procedures that live outside engineering, where the rest of the company keeps its files.
Web search
For checking how a library or protocol actually behaves before documenting it, with the source cited.
A realistic first week
- 1
Day one: the release notes backlog
Two or three releases that never got written up. One acceptance criterion per release: every user-facing change covered, no internal noise included.
- 2
Day two: the on-call runbook
Dictate the procedure into the task description in whatever order it comes out. The worker returns the ordered version with the gaps marked.
- 3
Wednesday: the audit
Twenty pages, one list of what is now false, ordered by how likely somebody is to be misled by it.
- 4
Friday: the style rules
Write your documentation conventions into the skill file so the next fifty pages match without anyone reviewing for tone.
Where the human stays in charge
The writer prepares
- Release notes filtered to what users care about
- Runbooks with decision points marked
- Standard operating procedures, numbered
- An audit list of statements that went stale
An engineer or owner decides
- Whether the procedure is actually correct
- What is safe to document publicly
- Which changes belong in the notes at all
- Publishing the page and closing the task
Questions people ask
+Can an AI technical writer read our codebase?
GitHub is in the connection catalog, and code context you provide in the task is what it writes from. It reasons about code rather than executing it, so behaviour that is only observable at runtime has to be described by someone who has watched it.
+Where do the documents end up?
In Polaris Docs by default, as versioned pages with comments and sub-pages, filed under the parent page whose topic fits. From there a person moves the content wherever it needs to be published.
+How do we keep documentation style consistent?
Put the conventions in the worker's SKILL.md: heading depth, whether to use second person, how commands are formatted, what a runbook must always contain. Every document after that follows the same rules without a reviewer re-explaining them.
+What does a set of release notes cost?
Notes for thirty-one merged changes work out at roughly 1.8 human-equivalent hours under the published formula, which is $3.60 at $2 per human-hour. That figure is illustrative; your actual line appears on the work log with the effort it came from.
Related
Hire an AI content writer
Briefs go in as tasks, drafts come back as versioned docs you can comment on line by line, and your voice rules live in a file rather than in one person's head.
Hire an AI QA engineer
Fourteen vague reports go in, fourteen tickets with steps, expected behaviour and a severity come out, with the three duplicates already merged.
The README describes a version of the code that no longer exists
A monthly list of statements in your docs that the code no longer supports.
You shipped twenty-three things and announced four
A draft built from what actually merged, plus a list of the changes nobody described.
Getting a process out of one person's head
The process exists. It is in someone's habits and in six months of Slack threads. A worker interviews and reads until it is on a page.
Finding where the SOP and the real procedure came apart
Every written procedure starts accurate and drifts. A worker compares the document to how the work actually ran and reports the difference.
Connect GitHub to Polaris
Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.
Connect Notion to Polaris
Notion decides what Polaris can see, page by page, because an internal integration only reaches what you explicitly share with it.