autodoc-analyst
Skill0 starsChanged 5 months agoMITView on GitHub
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.
In this repository76 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- autodoc-architectSkill
- autodoc-assemblerSkill
- autodoc-orchestratorSkill
- autodoc-scannerSkill
- autodoc-writerSkill
- brainstormSkill
- brd-creatorSkill
- caveman-modeSkill
- changelogSkill
- claude-md-managementSkill
- code-ai-reviewSkill
- code-boss-reviewSkill
- code-mobx-store-reviewSkill
- code-reviewSkill
- code-style-reviewSkill
- code-verifierSkill
- commitSkill
- constraint-driven-developmentSkill
- context-collectorSkill
- db-migrateSkill
- dependency-updateSkill
- deploySkill
- doubt-driven-developmentSkill
- feature-analyzerSkill
- feature-devSkill
- fsd-creatorSkill
- gproject-consistency-checkerSkill
- gproject-discoverySkill
- gproject-orchestratorSkill
- gproject-patterns-researcherSkill
- gproject-plannerSkill
- gproject-problem-definerSkill
- gproject-spec-writerSkill
- gproject-stack-advisorSkill
- hookifySkill
- iagoSkill
- interviewerSkill
- interviewSkill
- issue-analyzerSkill
- job-documenterSkill
- job-orchestratorSkill
- perf-checkSkill
- plan-gatekeeperSkill
- prd-creatorSkill
- pr-issue-documenterSkill
- pr-review-commentsSkill
- prSkill
- pushSkill
- review-architectureSkill
- review-backendSkill
- review-clean-codeSkill
- review-core-boundariesSkill
- review-flow-graphSkill
- review-frontend-conventionsSkill
- review-frontendSkill
- review-greptileSkill
- review-highloadSkill
- review-logicSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 60
Read the entry point file(s) listed in project-map.
- Distinctive: line 67
Read directory structure 2-3 levels deep.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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
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
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
# 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>Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

