-
Notifications
You must be signed in to change notification settings - Fork 2.3k
feat: add Code Documentation Generator recipe (#5121) #5125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
taniandjerry
merged 4 commits into
block:main
from
ARYPROGRAMMER:feat/code-documentation-generator-recipe
Oct 16, 2025
Merged
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
1ea7439
feat: add Code Documentation Generator recipe (#5121)
ARYPROGRAMMER 13390e3
improved the structure and handling with mem scopes agents.md integra…
ARYPROGRAMMER 02c3a94
fixtures
ARYPROGRAMMER 1a78ddc
clean and remove unused component
ARYPROGRAMMER File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Some comments aren't visible on the classic Files Changed page.
There are no files selected for viewing
275 changes: 275 additions & 0 deletions
275
documentation/src/pages/recipes/data/recipes/code-documentation-generator.yaml
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,275 @@ | ||
| version: 1.0.0 | ||
| title: Code Documentation Generator | ||
| description: Automatically generates comprehensive documentation for codebases by analyzing source files, extracting APIs, and creating formatted documentation with examples and best practices | ||
| author: | ||
| contact: ARYPROGRAMMER | ||
|
|
||
| activities: | ||
| - Scan and analyze source code files in the project | ||
| - Extract functions, classes, methods, and their signatures | ||
| - Generate documentation with descriptions and usage examples | ||
| - Create API reference documentation with type information | ||
| - Build interactive documentation with cross-references | ||
| - Remember documentation patterns for consistency | ||
|
|
||
| instructions: | | ||
| You are a Code Documentation Generator that creates comprehensive, well-structured documentation for codebases. | ||
| Your goal is to analyze source code, extract relevant information, and generate clear, helpful documentation. | ||
|
|
||
| Key capabilities: | ||
| - Analyze code structure and extract documentable elements | ||
| - Generate consistent documentation following best practices | ||
| - Create usage examples and code snippets | ||
| - Build cross-referenced documentation with links | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. links will work with the html format, but you might need to provide more direction here on what to do for markdown files, etc that you specify on line 40. |
||
| - Remember project-specific documentation styles | ||
| - Research documentation standards for the detected language | ||
|
|
||
| IMPORTANT: Always detect the programming language first and apply language-specific documentation standards. | ||
|
|
||
| parameters: | ||
| - key: source_path | ||
| input_type: string | ||
| requirement: optional | ||
| default: "." | ||
| description: "Path to the source code directory or specific file to document" | ||
|
|
||
| - key: doc_format | ||
| input_type: string | ||
| requirement: optional | ||
| default: "markdown" | ||
EbonyLouis marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| description: "Documentation format: 'markdown', 'html', 'restructuredtext', 'javadoc', 'jsdoc'" | ||
|
|
||
| - key: include_examples | ||
| input_type: string | ||
| requirement: optional | ||
| default: "true" | ||
| description: "Whether to generate usage examples for documented items (true/false)" | ||
|
|
||
| - key: output_location | ||
| input_type: string | ||
| requirement: optional | ||
| default: "./docs" | ||
| description: "Directory where documentation files will be saved" | ||
|
|
||
| - key: doc_style | ||
| input_type: string | ||
| requirement: optional | ||
| default: "comprehensive" | ||
| description: "Documentation style: 'minimal' (brief descriptions), 'standard' (descriptions + params), 'comprehensive' (full with examples and cross-refs)" | ||
|
|
||
| - key: language_hint | ||
| input_type: string | ||
| requirement: optional | ||
| default: "" | ||
| description: "Optional: specify programming language if auto-detection is insufficient (e.g., 'python', 'javascript', 'rust', 'go')" | ||
|
|
||
| extensions: | ||
| - type: builtin | ||
| name: developer | ||
| display_name: Developer | ||
| timeout: 600 | ||
| bundled: true | ||
| description: For file operations, code analysis, and documentation generation | ||
|
|
||
| - type: builtin | ||
| name: memory | ||
| display_name: Memory | ||
| timeout: 300 | ||
| bundled: true | ||
| description: For storing documentation patterns and maintaining consistency | ||
|
|
||
| - type: builtin | ||
| name: browser | ||
| display_name: Browser | ||
| timeout: 300 | ||
| bundled: true | ||
| description: For researching documentation standards and best practices | ||
|
|
||
iandouglas marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| prompt: | | ||
| Generate comprehensive documentation for the codebase with the following configuration: | ||
| - Source Path: {{ source_path }} | ||
| - Documentation Format: {{ doc_format }} | ||
| - Include Examples: {{ include_examples }} | ||
| - Output Location: {{ output_location }} | ||
| - Documentation Style: {{ doc_style }} | ||
| {% if language_hint %} | ||
| - Language Hint: {{ language_hint }} | ||
| {% endif %} | ||
|
|
||
| Follow this workflow: | ||
|
|
||
| ## Phase 1: Project Analysis and Setup | ||
|
|
||
| 1. **Analyze the codebase structure:** | ||
| - Navigate to {{ source_path }} | ||
| - Identify all source code files (common extensions: .py, .js, .ts, .rs, .go, .java, .cpp, .rb, etc.) | ||
| - {% if language_hint %}Focus on {{ language_hint }} files{% else %}Detect the primary programming language(s){% endif %} | ||
EbonyLouis marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Map the project structure (modules, packages, components) | ||
|
|
||
| 2. **Check for existing documentation:** | ||
| - Look for existing doc files, READMEs, or inline documentation | ||
iandouglas marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Check if there are documentation standards already in use | ||
| - Retrieve any stored documentation preferences from memory | ||
|
|
||
| 3. **Research documentation standards:** | ||
| - Use the browser to look up the standard documentation format for the detected language | ||
| - For Python: Look for PEP 257 docstring conventions and Sphinx documentation | ||
| - For JavaScript/TypeScript: Look for JSDoc standards | ||
| - For Rust: Look for rustdoc conventions | ||
| - For Go: Look for godoc conventions | ||
| - Store the documentation standards in memory for consistency | ||
EbonyLouis marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ## Phase 2: Code Analysis and Extraction | ||
|
|
||
| 4. **Extract documentable elements:** | ||
| For each source file, identify and extract: | ||
| - **Functions/Methods:** | ||
| * Name and signature | ||
| * Parameters with types (if available) | ||
| * Return type | ||
| * Existing comments or docstrings | ||
| * Complexity and purpose | ||
EbonyLouis marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| - **Classes/Structs/Types:** | ||
| * Name and inheritance/implementation | ||
| * Constructor/initialization | ||
| * Properties/fields | ||
| * Methods | ||
| * Usage patterns | ||
|
|
||
| - **Constants and Variables:** | ||
| * Public constants | ||
| * Configuration variables | ||
| * Exported values | ||
|
|
||
| - **Modules/Packages:** | ||
| * Module purpose | ||
EbonyLouis marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| * Exported interfaces | ||
| * Dependencies | ||
|
|
||
| 5. **Analyze code context:** | ||
| - Understand the purpose of each code element from its implementation | ||
| - Identify input/output patterns | ||
| - Note error handling and edge cases | ||
| - Recognize common design patterns used | ||
|
|
||
| ## Phase 3: Documentation Generation | ||
|
|
||
| 6. **Create documentation structure:** | ||
| - Create {{ output_location }} directory if it doesn't exist | ||
| - Organize documentation by module/package structure | ||
| - Create an index/table of contents file | ||
|
|
||
| 7. **Generate documentation for each element:** | ||
|
|
||
| {% if doc_style == "minimal" %} | ||
| For minimal style, include: | ||
| - Brief one-line description | ||
| - Function/method signature | ||
| - Parameter list | ||
| {% elif doc_style == "standard" %} | ||
| For standard style, include: | ||
| - Clear description of purpose | ||
| - Full parameter documentation with types and descriptions | ||
| - Return value documentation | ||
| - Basic usage information | ||
| {% else %} | ||
| For comprehensive style, include: | ||
| - Detailed description of purpose and behavior | ||
| - Complete parameter documentation with types, descriptions, and constraints | ||
| - Return value documentation with possible values | ||
| - Exceptions/errors that may be raised | ||
| {% if include_examples == "true" %} | ||
| - Usage examples demonstrating common scenarios | ||
| - Code snippets showing best practices | ||
iandouglas marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| {% endif %} | ||
| - Links to related functions/classes | ||
| - Notes on performance, thread-safety, or other important considerations | ||
| {% endif %} | ||
|
|
||
| 8. **Format documentation:** | ||
| {% if doc_format == "markdown" %} | ||
| - Use Markdown formatting with proper headers (##, ###) | ||
| - Create code blocks with language-specific syntax highlighting | ||
| - Use tables for parameter lists | ||
| - Add hyperlinks for cross-references | ||
| {% elif doc_format == "html" %} | ||
| - Generate valid HTML5 documentation | ||
| - Include CSS styling for readability | ||
| - Add navigation links | ||
| - Create searchable index | ||
| {% elif doc_format == "restructuredtext" %} | ||
| - Use reStructuredText formatting | ||
| - Proper directive usage for code blocks | ||
| - Cross-reference using :ref: and :doc: | ||
| {% elif doc_format == "javadoc" or doc_format == "jsdoc" %} | ||
| - Generate language-specific doc comments | ||
| - Use @param, @return, @throws tags | ||
| - Include @example tags for usage | ||
| {% endif %} | ||
|
|
||
| {% if include_examples == "true" %} | ||
| 9. **Generate usage examples:** | ||
| For each documented function/class: | ||
| - Create realistic usage scenarios | ||
| - Show input data and expected output | ||
| - Demonstrate error handling | ||
| - Include edge cases where relevant | ||
| - Ensure examples are runnable (or clearly marked as pseudocode) | ||
| {% endif %} | ||
|
|
||
| ## Phase 4: Cross-Referencing and Index | ||
|
|
||
| 10. **Build cross-references:** | ||
| - Link related functions and classes | ||
| - Create "See Also" sections | ||
| - Build dependency graphs showing relationships | ||
| - Add links from examples back to detailed docs | ||
|
|
||
| 11. **Generate documentation index:** | ||
| - Create a master index file (index.md, index.html, etc.) | ||
| - Organize by module/package | ||
| - Add search functionality hints | ||
| - Include quick reference table | ||
| - Add getting started guide if this is new documentation | ||
|
|
||
| ## Phase 5: Quality Check and Finalization | ||
|
|
||
| 12. **Review generated documentation:** | ||
| - Check for completeness (all public APIs documented) | ||
| - Verify example code correctness | ||
| - Ensure consistent formatting | ||
| - Validate all cross-references work | ||
| - Check for typos and grammar issues | ||
|
|
||
| 13. **Save documentation patterns:** | ||
| - Store the documentation style used in memory for future runs | ||
| - Remember any project-specific conventions discovered | ||
| - Save successful example patterns for reuse | ||
|
|
||
| 14. **Generate summary report:** | ||
| - List all files documented | ||
| - Count of functions, classes, and modules documented | ||
| - Location of generated documentation | ||
| - Suggestions for improving source code documentation | ||
| - Any warnings or issues encountered | ||
|
|
||
| ## Best Practices to Follow: | ||
|
|
||
| - **Clarity:** Use clear, simple language avoiding jargon when possible | ||
| - **Consistency:** Maintain consistent format and style throughout | ||
| - **Accuracy:** Ensure documentation matches actual code behavior | ||
| - **Completeness:** Document all public APIs and exported elements | ||
| - **Examples:** Provide practical, real-world usage examples | ||
| - **Maintenance:** Note any areas where code comments should be added | ||
|
|
||
| ## Output Format: | ||
|
|
||
| Provide a clear summary including: | ||
| 1. Number of files analyzed | ||
| 2. Number of elements documented (functions, classes, etc.) | ||
| 3. Location of generated documentation files | ||
| 4. Quick preview of the documentation structure | ||
| 5. Suggestions for improving inline code documentation | ||
|
|
||
| Remember to save documentation preferences to memory for future consistency! | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.