Claude-skill-registry api-field-descriptions
install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/api-field-descriptions" ~/.claude/skills/majiayu000-claude-skill-registry-api-field-descriptions && rm -rf "$T"
manifest:
skills/data/api-field-descriptions/SKILL.mdsource content
API Field Descriptions
Field descriptions are the most-read part of API documentation. Users scan for specific fields and need clear, consistent information.
Field Description Structure
Every field description answers: What is it? (purpose), What type? (data type), Required? (mandatory), Constraints? (limits/validations), Example? (valid data)
Table Format (Preferred)
| Field | Type | Required | Description | |-------|------|----------|-------------| | id | uuid | — | The unique identifier of the Account | | name | string | Yes | The display name of the Account (max 255 chars) | | status | enum | — | Account status: `ACTIVE`, `INACTIVE`, `BLOCKED` |
Note: Use
— for response-only fields (not applicable for requests).
For nested objects:
status.code, status.description
Description Patterns by Type
| Type | Pattern | Example |
|---|---|---|
| UUID | "The unique identifier of the [Entity]" | |
| String | "[Purpose] (constraints)" | |
| String (format) | "[Purpose] (format example)" | |
| Enum | "[Purpose]: , , " | currency`, `crypto`, `commodity`` |
| Boolean | "If , [what happens]. Default: " | true`, sending permitted. Default: `true`` |
| Integer | "[Purpose] (range)" | |
| Timestamp | "Timestamp of [event] (UTC)" | |
| Object (jsonb) | "[Purpose] including [fields]" | |
| Array | "List of [what it contains]" | |
Required vs Optional
In Requests:
= Must be providedYes
= OptionalNo
= Required in specific scenarios (explain in description)Conditional
In Responses: Use
— (response fields are always returned or null)
Special Field Documentation
| Pattern | Format |
|---|---|
| Default values | "Results per page. Default: 10" |
| Nullable fields | "Soft deletion timestamp, or if not deleted" |
| Deprecated fields | "[Deprecated] Use instead" |
| Read-only fields | "Read-only. Generated by the system" |
| Relationships | "References an Asset code. Must exist in the Ledger" |
Writing Good Descriptions
| Don't | Do |
|---|---|
| "The name" | "The display name of the Account" |
| "Status info" | "Account status: , , " |
| "A number" | "Balance version, incremented with each transaction" |
| "The code" | "The asset code (max 10 chars, uppercase)" |
| "The timestamp" | "Timestamp of creation (UTC)" |
Quality Checklist
- Description explains the field's purpose
- Data type is accurate
- Required/optional status is clear
- Constraints documented (max length, valid values)
- Default value noted (if optional)
- Nullable behavior explained (if applicable)
- Deprecated fields marked
- Read-only fields indicated
- Relationships to other entities clear
- Example values realistic