# Autodoc Analyst

> Phase 2 subagent for autodoc-orchestrator. Deep-dives into a single module to extract purpose, structure, public API surface, patterns, and key dependencies. Use when: dispatched by autodoc-orchestrator Phase 2 (one instance per module). NOT for: direct user invocation.

- Skill: `mrciphersmith/autodoc-analyst` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mrciphersmith/autodoc-analyst`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mrciphersmith/autodoc-analyst/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: MrCipherSmith (https://skillmd.com/u/mrciphersmith)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mrciphersmith/autodoc-analyst

---


# autodoc-analyst

## Purpose

Produce a complete semantic understanding of one module that the architect
and writers can use without re-reading the source code.

## Iron Laws

| # | Law |
|---|-----|
| 1 | Analyze ONE module per invocation — do not cross module boundaries |
| 2 | Read actual source files — understanding must come from code, not assumptions |
| 3 | Prioritize: public interfaces > internal implementation > tests |
| 4 | Document what the code DOES, not how it does it internally |
| 5 | Extract concrete examples from code (real function names, real endpoints) |

---

## Input Contract

```yaml
module:
  slug: "<module slug>"
  path: "<absolute module path>"
  type: "backend | frontend | shared | ..."
  language: "<lang>"
  framework: "<framework>"
  entry_points: ["<file>"]
project_map: "jobs/<job>/artifacts/project-map.md"
JOB_DIR: "<job directory>"
CONFIG: "<from state.json.config>"
```

## Output Contract

```yaml
status: "DONE" | "DONE_WITH_CONCERNS" | "NEEDS_CONTEXT"
summary: "<3-5 sentences: what the module does, its main components, key patterns>"
concerns: ["<concern>"]
artifact_path: "jobs/<job>/artifacts/analysis/<slug>.md"
```

---

## Workflow

### Step 1: Entry Point Analysis

Read the entry point file(s) listed in project-map. Understand:
- What is bootstrapped / initialized?
- What are the top-level exports?
- What dependencies are injected or imported?

### Step 2: Module Structure Mapping

Read directory structure 2-3 levels deep. Identify organizational pattern:

| Pattern | Indicators |
|---------|-----------|
| Feature-based | `src/features/`, `src/modules/` with self-contained subdirs |
| Layer-based | `controllers/`, `services/`, `repositories/` at top level |
| DDD | `domain/`, `application/`, `infrastructure/`, `presentation/` |
| Component-based (frontend) | `components/`, `pages/`, `hooks/`, `stores/` |

### Step 3: Public API Surface Extraction

For **backend modules**:
- Find controller/router files → extract endpoints (method, path, description)
- Find DTO/schema files → extract request/response shapes
- Find exported service methods → extract public operations

For **frontend modules**:
- Find page/route components → extract routes
- Find exported components → extract component library
- Find custom hooks → extract hook API
- Find store/state definitions → extract state shape

For **shared/lib modules**:
- Find index.ts exports → extract public API
- Find type definitions → extract key types and interfaces

### Step 4: Pattern Detection

Identify patterns actually used in the code:

| Pattern | What to look for |
|---------|----------------|
| Dependency Injection | `@Injectable`, `@Module`, constructor params, containers |
| Repository pattern | `Repository`, `findById`, `save`, `delete` methods |
| CQRS | `Command`, `Query`, `Handler`, `Bus` classes |
| Event-driven | `EventEmitter`, `@OnEvent`, message queue clients |
| React Query / SWR | `useQuery`, `useMutation` hook patterns |
| MobX | `@observable`, `@action`, `makeAutoObservable` |
| Redux | `createSlice`, `createAsyncThunk`, `useSelector` |

### Step 5: Dependencies & Integrations

From imports and config files, identify:
- External services (databases, queues, caches, auth providers)
- Internal cross-module dependencies
- Third-party libraries central to the module's function

### Step 6: Write Analysis Artifact

```markdown
# Module Analysis: <Module Name>

## Purpose
<1-2 paragraphs: what this module does, what problem it solves>

## Architecture Pattern
<pattern name + brief explanation>

## Structure
<annotated directory tree, 2-3 levels>

## Public API

### Endpoints (backend) / Routes (frontend)
| Method | Path | Description |
|--------|------|-------------|

### Key Exports / Components / Services
| Name | Type | Purpose |
|------|------|---------|

### Data Models / DTOs
| Model | Fields (key ones) | Used in |
|-------|------------------|---------|

## Key Patterns Used
<list with brief explanation of each>

## External Dependencies
| Dependency | Purpose |
|-----------|---------|

## Internal Dependencies
<which other modules this module depends on>

## Configuration
<env vars, config files, feature flags used>

## Error Handling
<how errors are handled and propagated>

## Testing
<test coverage summary, test patterns used>

## Notes & Observations
<unusual patterns, technical debt, important constraints>
```