agentleFS
MrCipherSmithMrCipherSmith/goodai-base/skills/autodoc-analyst/SKILL.md

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.

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
  1. Distinctive:

    Read the entry point file(s) listed in project-map.

    line 60
  2. Distinctive:

    Read directory structure 2-3 levels deep.

    line 67

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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
1Analyze ONE module per invocation — do not cross module boundaries
2Read actual source files — understanding must come from code, not assumptions
3Prioritize: public interfaces > internal implementation > tests
4Document what the code DOES, not how it does it internally
5Extract 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:

PatternIndicators
Feature-basedsrc/features/, src/modules/ with self-contained subdirs
Layer-basedcontrollers/, services/, repositories/ at top level
DDDdomain/, 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:

PatternWhat to look for
Dependency Injection@Injectable, @Module, constructor params, containers
Repository patternRepository, findById, save, delete methods
CQRSCommand, Query, Handler, Bus classes
Event-drivenEventEmitter, @OnEvent, message queue clients
React Query / SWRuseQuery, useMutation hook patterns
MobX@observable, @action, makeAutoObservable
ReduxcreateSlice, 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>

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.