Hire an AI developer documentation reviewer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• Each README step marked working or broken, with proof and the edit
• Every doc that disagrees with the code, with file and line
• New modules and endpoints with no doc
• A changelog draft for the month's releases, grouped into added, changed and fixed
• Proposed rewrites for docstrings, the API spec and the glossary
• A map of which doc covers which code, kept current

How it does the job well

• Turn every request into owned actions: who, what and by when.
• Work from the real calendar, notes and lists. Never invent meetings, people or dates.
• Put the most important decision or deadline first, then the details.
• Prepare drafts and proposals. Sending, booking and changing records waits for approval.

Mistakes it avoids

• Rewriting docs that did not drift.
• Writing a changelog from commit messages nobody meant users to read.
• Updating the spec to match a bug.
• Letting a broken first step wait while the glossary is tidied.
• Losing commitments buried in long notes.
• Mixing confirmed facts with guesses about other people's plans.

What a good result looks like

An example, not your task: Other people build on or install your code and keep hitting the same broken step.

• This month in one line. README steps passed and broken, docs drifted, endpoints out of spec, compared with last month.
• Broken first. Each README step that failed, with the proof and the edit that fixes it.
• Drifted docs. Each false claim, with the doc, the code file and line, and the fix.
• Undocumented. New modules or endpoints that have no doc yet.
• Changelog draft. The month's released changes grouped into added, changed and fixed, in plain words.
• Proposed rewrites. Docstring, usage guide, API spec and glossary changes, each as a diff or a file.

How the work is checked

• Every README step has a working or broken mark with proof.
• Every drifted doc names the code file and line it disagrees with.
• The changelog covers only what was released.
• The spec changes match the code, not the other way round.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Read last month. Picks up the fixes marked done, to re-test first.
• Test the README as a stranger. Tries each step in order and marks it working or broken with proof and the fix. A broken first step tops the report.
• Find what changed. Lists the files changed this month and, from the map, every doc that describes them, plus new modules with no doc.
• Check the docs that should have moved. Each doc that describes changed code is checked for false claims and drift, with file and line.
• Draft the changelog. The month's released commits grouped into added, changed and fixed, in words a user understands.
• Fix the drifted docs as proposals. Docstring and usage guide rewrites, the API spec matched to the code, and glossary entries for new or doubled terms.
• Log and hand back. Updates the health and map files, then stops. You merge.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id monthly-developer-docs-keeper only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/monthly-developer-docs-keeper/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• Your repo with its README, docs, changelog, API spec and the month's git history
• Docs that live outside the repo, such as a wiki page (optional)
• The release tags for the month (advised)
• Last month's keeper file, once it exists

Helpful context (optional)

• Questions new developers asked this month, so the test knows where they got stuck
• Your release notes for the month

Tools and access

• Claude Code: It can run the README steps, read the git history and keep the health and map files between months.
• Your docs site: Export or link the hosted docs, so pages outside the repo are checked too.

Functions and deliverables

• Developer documentation reviewer: Check project docs against code and recent releases. Get broken setup steps, stale claims and proposed fixes.
  • Each README step marked working or broken, with proof and the edit
  • Every doc that disagrees with the code, with file and line
  • New modules and endpoints with no doc
  • A changelog draft for the month's releases, grouped into added, changed and fixed
  • Proposed rewrites for docstrings, the API spec and the glossary
  • A map of which doc covers which code, kept current
• README first-run tester: Check your README first-run steps against your repo. See each step marked working or broken, with proof and the edits that fix it.
  • Step list marked working, broken, missing or unchecked
  • Evidence with file and line
  • The real first-run path
  • README edits to fix problems
  Source: Pro Skill Packs.
• Documentation accuracy reviewer: Check documentation claims against the actual code. Get false or unverified claims, source evidence and fixes to make before publishing.
  • A list of false or missing claims
  • Code samples marked as working or broken
  • Places where docs and code disagree
  • Fixes for each issue
  Source: sickn33.
• Changelog entry writer: Share a commit range or pull request. Get a release entry grouped by what changed.
  • A changelog entry in a standard format
  • Changes grouped as added, changed, fixed and so on
  • Short plain-language lines per change
  • Flags for anything odd in the history
  Source: sickn33.
• Code documentation writer: Turn source files and tests into docstrings, README files, and usage examples in your project's style.
  • Docstrings for public code
  • A project README
  • Usage examples
  • A list of docs that were stale
  Source: Burhan Sebin.
• API spec writer: Share routes, code or an API description. Get an OpenAPI or Swagger spec with schemas, errors and sign-in rules to validate.
  • A complete OpenAPI or Swagger file
  • Endpoints with request and response shapes
  • Security setup
  • Reusable data schemas
  Source: sickn33.
• Project glossary writer: Build a project glossary by talking through your terms. Your AI flags clashing words and writes down the agreed ones, plus short decision records.
  • Glossary of agreed terms
  • Flagged clashes and unclear words
  • Short decision records
  • Glossary map for projects with several areas
  Source: Matt Pocock.
• me.md builder: Answer a few questions, or let your AI use what it remembers. Get one private file that tells any AI who you are.
  • One me.md file with up to ten dated sections
  • A list of facts taken from memory, for you to check
  • A short note of what it removed for privacy
  • The two next steps, to save it and set it up

Tasks you can use it for

• Other people build on or install your code and keep hitting the same broken step.
• Your changelog stopped months ago and the spec does not match the API.
• You want docs checked on a schedule instead of when someone complains.

Limits to check before starting

• You want a one-off review of a single release: ask the Software release verification coordinator, or read that release's notes yourself.
• Nobody installs or builds on your repo: a short note in the README is enough, so skip a monthly check.
• You want the docs published or merged for you: this agent only proposes changes, so a person must commit them.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Start a chat with the agent. In Claude Code, add it as a skill or save it in .claude/agents, then point it at the repo.
• Tell it which releases shipped this month, or let it read the tags.
• Read the broken README steps first. Fix those before anything else.
• Review the proposed rewrites and the changelog draft. Commit and publish what you approve yourself.
• Run it again on the first Tuesday of next month. It re-tests what you fixed.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/monthly-developer-docs-keeper for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.