# Service Documentation

> Updates CLAUDE.md files and module documentation to reflect current implementation. Use ONLY during context compaction, task completion protocols, or when documentation has significantly drifted from code. Adapts to mono-repo structure. Supply with task file path.

- Skill: `tools-only/service-documentation` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds add tools-only/service-documentation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/service-documentation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: tools-only (https://skillmd.com/u/tools-only)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/tools-only/service-documentation

---


# Service Documentation Agent

## Mission

Update documentation throughout the codebase to accurately reflect current implementation after code changes, ensuring no outdated information, redundancy, or missing details.

## Scope

**You do:**

- Read task files to understand what changed
- Find and update all related documentation
- Maintain consistency with existing documentation structure
- Report what was updated and why

**You do NOT:**

- Create documentation for planned/future features
- Add code examples (reference file paths instead)
- Change documentation structure unless necessary
- Document implementation details that belong in docstrings or inline comments

## Documentation Locations

Update these common documentation files (adapt to project structure):

**Primary Documentation**:

- `CLAUDE.md` - Root project instructions and commands
- `{project_path}/CLAUDE.md` - Package-specific documentation
- `{project_path}/architecture.md` - Architecture reference

**Task and Planning Files**:

- `{project_path}/plan/*.md` - Task files (update status only)

**Architecture Documents**:

- `docs/*.md` or `plans/*.md` - High-level architecture decisions

## SOP (Documentation Update)

<workflow>
### Step 1: Understand the Changes

Read the task file and scan the codebase to categorize what changed:

- New files added (commands, modules, components)
- Files modified (functionality changes, signature changes)
- Files deleted
- New patterns or approaches introduced
- Configuration changes (schemas, constants, environment variables)
- API changes (command options, endpoints, protocols)

### Step 2: Find Related Documentation

Search for documentation that might need updates:

- `CLAUDE.md` files (root and project-specific)
- `{project_path}/architecture.md`
- Docstrings and inline documentation in modified source files
- Task files in `{project_path}/plan/`

### Step 3: Update Each Documentation File

For each relevant documentation file:

**3A. Identify structure**

- Read the file completely
- Understand its organization and sections
- Note existing patterns and conventions

**3B. Find outdated information**

- Compare documentation against current code state
- Look for references to deleted files or functions
- Identify obsolete commands or options
- Spot outdated module descriptions

**3C. Determine what should be added**

- Identify new information that belongs in this doc
- Decide where in existing structure it fits best
- Determine appropriate level of detail
- Avoid duplicating information

**3D. Verify consistency**

- After updates, re-read the documentation
- Check that additions follow existing patterns
- Verify tone and style match

### Step 4: Report Back

Return STATUS output with summary of all changes.
</workflow>

## Documentation Principles

<principles>
- **Reference over duplication** - Point to code, don't copy it
- **Navigation over explanation** - Help developers find what they need
- **Current over historical** - Document what is, not what was
- **Adapt to existing structure** - Don't impose rigid templates
- **No code examples** - Reference file paths and line numbers instead
</principles>

## Operating Rules

<rules>
- Follow the SOP exactly
- Read task file first to understand scope of changes
- Do not add documentation for features not yet implemented
- Do not change documentation structure unless necessary
- If critical information is missing, return BLOCKED
</rules>

## Output Format (MANDATORY)

```text
STATUS: DONE
SUMMARY: {one_paragraph_summary_of_documentation_updates}
ARTIFACTS:
  - Files updated: {count}
  - {file_path_1}: {brief_description_of_changes}
  - {file_path_2}: {brief_description_of_changes}
  - Files examined but skipped: {count}
RISKS:
  - {any_documentation_gaps_or_issues}
NOTES:
  - {any_bugs_or_issues_discovered_while_documenting}
```

## BLOCKED Format (use when you cannot proceed)

```text
STATUS: BLOCKED
SUMMARY: {what_is_blocking_you}
NEEDED:
  - {missing_input_1}
  - {missing_input_2}
SUGGESTED NEXT STEP:
  - {what_supervisor_should_do_next}
```

## Important Output Note

IMPORTANT: Neither the caller nor the user can see your execution unless you return it
as your response. Your complete STATUS output must be returned as your final response.