Reference Builder
Generate comprehensive API and technical documentation
Creating exhaustive technical documentation manually is time-consuming and error-prone. This skill automates the generation of complete reference materials with consistent formatting and thorough parameter coverage.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez Ă utiliser
Tester
Utilisation de "Reference Builder". Document a REST API endpoint: POST /api/users with parameters: name (string, required), email (string, required), age (integer, optional)
RĂ©sultat attendu:
- ### POST /api/users
- Â
- **Description**: Creates a new user account in the system.
- Â
- **Parameters**:
- - `name` (string, required): User's full name, 2-100 characters
- - `email` (string, required): Valid email address, must be unique
- - `age` (integer, optional): User's age in years, 18-120
- Â
- **Returns**: User object with id, name, email, created_at
- Â
- **Errors**: 400 (validation), 409 (duplicate email), 500 (server error)
- Â
- **Example**:
- POST /api/users
- {"name": "Jane Doe", "email": "jane@example.com", "age": 30}
Utilisation de "Reference Builder". Document a database User schema with fields: id, username, email, created_at, status
RĂ©sultat attendu:
- ### User Schema
- Â
- | Field | Type | Constraints | Description |
- |-------|------|-------------|-------------|
- | id | UUID | PRIMARY KEY | Unique identifier |
- | username | VARCHAR(50) | NOT NULL, UNIQUE | User's display name |
- | email | VARCHAR(255) | NOT NULL, UNIQUE | Contact email address |
- | created_at | TIMESTAMP | NOT NULL, DEFAULT NOW() | Account creation time |
- | status | ENUM | NOT NULL, DEFAULT 'active' | Account status: active, suspended, deleted |
- Â
- **Indexes**: username_idx, email_idx, status_idx
- Â
- **Relationships**: One-to-many with Posts, One-to-one with Profile
Audit de sécurité
SûrThis is a prompt-only skill containing no executable code. Static analysis scanned 0 files with 0 lines of code and detected no security patterns. The skill consists entirely of documentation instructions and prompt templates for creating technical references.
Score de qualité
Ce que vous pouvez construire
API Reference Generation
Create comprehensive API documentation for internal or public APIs with complete parameter listings, return types, error codes, and usage examples.
Configuration Documentation
Generate detailed configuration guides for complex applications, documenting all settings, defaults, constraints, and environment-specific values.
SDK Documentation
Produce exhaustive SDK reference materials including class hierarchies, method signatures, type definitions, and integration examples.
Essayez ces prompts
Document the following API endpoint as a complete reference entry. Include the method signature, all parameters with types and constraints, return values, possible errors, and a basic usage example: Endpoint: [METHOD] [URL] Parameters: [list parameters] Context: [describe what it does]
Create a comprehensive configuration reference table for the following settings. For each parameter, document the type, default value, valid range, whether it is required, environment variable name, and any dependencies on other settings: [Provide list of configuration parameters]
Generate complete schema documentation for the following data model. Include field types, validation rules, constraints, relationships to other models, indexing information, and provide three examples: a minimal valid record, a fully populated record, and an edge case: [Provide schema definition]
Create a full technical reference for the following module. Structure it with: 1) Overview section explaining purpose, 2) Quick reference table of all public methods, 3) Detailed entries for each method with signatures, parameters, return types, errors, and examples, 4) Cross-references between related methods, 5) Performance considerations, and 6) Common pitfalls to avoid: [Provide module source code or interface definition]
Bonnes pratiques
- Document behavior and intent, not implementation details - focus on what the code does, not how
- Include both happy path examples and error handling scenarios for complete coverage
- Use consistent terminology throughout all documentation - create and follow a glossary
Éviter
- Writing examples that omit error handling - always show how to handle failures
- Using implementation-specific jargon instead of clear, user-focused language
- Creating documentation without version markers - always indicate which version each feature applies to