Document Code with C4 Model Standards

Produces C4-model "Code level" documentation for a specific code directory: function and method signatures with parameter/return types and dependencies, class or module structure, internal and external dependency lists, and relationship diagrams, all following a fixed documentation template (name, description, location, language, purpose).

For code elements it documents functions/methods as functionName(param1: Type, param2: Type): ReturnType with description, file:line location, and dependencies, and classes/modules with description, location, method list, and dependencies - then separately lists internal code dependencies and external libraries, frameworks, or services.

For relationships it generates optional Mermaid diagrams, chosen by programming paradigm rather than a one-size-fits-all format. Object-oriented code (classes, interfaces, inheritance) uses a classDiagram showing implementation and usage relationships. Functional or procedural code gets a choice of three diagram styles: a module structure diagram (classDiagram with <<module>> stereotypes showing each module's exported functions and their usage relationships), a data-flow diagram (flowchart showing a function pipeline stage by stage, e.g. readFile to parseJSON to validateInput to normalize to aggregate to writeFile, with data labels on each edge), or a function dependency graph (flowchart grouping public API functions, internal functions, and pure utilities, with call edges between them). A reference table maps code style to the recommended primary diagram: OOP to classDiagram for inheritance/composition/interfaces, FP pipelines to flowchart for data transformations, FP modules to classDiagram with <<module>> for module structure, procedural (structs plus functions) to classDiagram, and mixed paradigms to a combination of diagrams. Per the C4 model itself, code-level diagrams are only recommended when a component is complex enough to warrant them - most teams find system-context and container diagrams sufficient on their own.

Example interactions span object-oriented codebases (analyzing an API directory, documenting a service layer's class hierarchy, showing repository-layer interface implementations), functional/procedural codebases (documenting an authentication module's function signatures and data flow, creating an ETL pipeline diagram, documenting pure functions and composition patterns, documenting Rust module function dependencies or Elixir GenServer modules), and mixed-paradigm codebases (a Go handlers package mixing structs and functions, or a TypeScript codebase mixing classes and functional utilities).

Use this skill when producing code-level C4 documentation for a specific directory or component - full function/method signatures, dependency lists, and paradigm-appropriate diagrams. Do not use it for tasks unrelated to this specific documentation scope, or when a different C4 level is actually needed: it is explicitly distinct from a Component-level agent (which synthesizes multiple code files into components), a Container-level agent (which maps components to deployment units), and a Context-level agent (which produces high-level system diagrams) - each of those operates one abstraction level up from this skill's code-element focus.

Input is a target code directory or component to document. Output is structured C4 Code-level documentation: complete function/method signatures, class/module descriptions, internal and external dependency lists, source-location links, and Mermaid diagrams selected by the code's programming paradigm.

Outputs Mermaid classDiagram and flowchart diagram syntax directly, and follows the C4 model's documentation conventions (c4model.com) for the code-detail level specifically, complementary to but distinct from the Component/Container/Context levels of the same model.

Engineers and technical writers documenting a specific codebase directory's internal structure - functions, classes, modules, and their dependencies - who need consistent, diagram-backed C4 Code-level documentation rather than higher-level architecture diagrams.