name: mdf-md-api-docs-majo description: | MDF-style API reference documentation for markdown files. Use when writing API references or documentation from code using the meadow Docstring Format (MDF). Covers function and class documentation templates with proper formatting for arguments, returns, raises, methods, and usage examples. license: Unlicense OR 0BSD metadata: author: Mark Joshwel mark@joshwel.co version: "2026.2.2"
MDF API Reference Documentation
API reference format following meadow Docstring Format (MDF) structure for markdown documentation.
Goal
Provide clear, consistent API documentation in markdown files that mirrors Python docstring conventions while remaining readable as plaintext.
When to Use This Skill
- Writing API reference sections in README files
- Documenting Python libraries/modules for users
- Creating function/class documentation in markdown
- Following up
writing-docs-majowhen API docs are needed
Do NOT Use
- Python code docstrings (use
mdf-majoinstead) - Internal code comments
- Non-API documentation (use
writing-docs-majo)
Process
- Identify what to document — functions, classes, or modules
- Write the header —
### def|class module.Name() - Add preamble — one-line description
- Add signature — Python code block
- Document inputs — arguments or attributes
- Document outputs — methods or returns
- Document errors — raises section
- Add usage example — if helpful
Constraints
- Always use backticks around Python types and code
- Two-space linebreak before descriptions in lists
- Latest Python syntax —
T | NonenotOptional[T] - Link when helpful — to other sections or external docs
Testing Skills
- Headers use correct format:
### def|class module.Name() - All Python code wrapped in backticks
- Two-space linebreaks before descriptions
- Consistent indentation (4 spaces for nested content)
- Links use proper markdown format with backticks
Header Format
### <def|class> module.Name()
Examples:
### def tomlantic.ModelBoundTOML.set_field()### class tomlantic.ModelBoundTOML### def surplus.process()
Section Structure
Order (all optional except preamble):
- preamble — brief one-line description
- body — longer explanation if needed
- signature — Python code block
- attributes (classes) or arguments (functions)
- methods (classes)
- returns — return type
- raises — exceptions
- usage — code example
Section Formats
Arguments / Attributes / Methods
Use list format with two-space linebreak:
- arguments:
- `name: str`
description of the argument
- `count: int = 0`
optional count with default
- methods:
- [`def process()`](#def-moduleprocess)
processes the data
- `def validate()`
validates inputs
Returns (Single)
- returns: `ProcessedResult`
structured result containing processed fields
Returns (Multiple Types)
- returns:
- `SuccessResult`
when processing succeeds
- `ErrorResult`
when processing fails with error details
Raises (Single)
- raises: `ValueError`
raised when input is invalid
Raises (Multiple)
- raises:
- `ValueError`
raised when input is invalid
- `TimeoutError`
raised when operation exceeds time limit
- [`CustomError`](#class-modulecustomerror)
raised for domain-specific failures
Complete Examples
Function Example
### def tomlantic.ModelBoundTOML.set_field()
sets a field by its location. not recommended for general use due to a lack of
type safety, but useful when setting fields programatically
will handle `pydantic.ValidationError` into more toml-friendly error messages.
set `handle_errors` to `False` to raise the original `pydantic.ValidationError`
- signature:
```python
def set_field(
self,
location: str | tuple[str, ...],
value: object,
handle_errors: bool = True,
) -> None: ...
-
arguments:
location: str | tuple[str, ...]
dot-separated location of the field to setvalue: object
value to set at the specified locationhandle_errors: bool = True
whether to convert pydantic ValidationErrors to tomlantic errors
-
raises:
AttributeError
if the field does not existtomlantic.TOMLValidationError
if validation failspydantic.ValidationError
if validation fails andhandle_errorsisFalse
### Class Example
```markdown
### class tomlantic.ModelBoundTOML
glue class for pydantic models and tomlkit documents
- signature:
```python
class ModelBoundTOML(Generic[M]): ...
-
attributes:
model: pydantic.BaseModel
the bound pydantic model instance
-
methods:
def model_dump_toml()
dumps the model as a style-preserved tomlkit.TOMLDocumentdef get_field()
safely retrieve a field by its locationdef set_field()
sets a field by its location
-
usage:
toml = ModelBoundTOML(YourModel, tomlkit.parse(...)) toml.model.message = "hello" document = toml.model_dump_toml()
### Simple Function Example
```markdown
### def surplus.process_file()
process a single file through the surplus pipeline
- signature:
```python
def process_file(
path: Path,
options: ProcessingOptions | None = None,
) -> ProcessingResult: ...
-
arguments:
path: Path
path to the file to processoptions: ProcessingOptions | None = None
optional processing configuration
-
returns:
ProcessingResult
result containing processed output and metadata -
raises:
FileNotFoundError
if the file does not exist -
usage:
result = process_file(Path("data.txt")) if result.success: print(result.output)
## Formatting Quick Reference
| Element | Format |
|---------|--------|
| Type | `` `Type` `` or `` `module.Type` `` |
| Variable | `` `name: Type` `` |
| Function signature | `` `def name(...) -> Return: ...` `` |
| Link internal | `` [`Type`](#section) `` |
| Link external | `` [`Type`](https://...) `` |
| Description separator | Two spaces + newline |
| Nested indentation | 4 spaces |
## Integration
This skill works alongside:
- `writing-docs-majo` — General documentation standards
- `mdf-majo` — Python docstring format (the inspiration for this markdown format)
- `python-majo` — Python code standards