Guidelines for communicating with users and formatting documentation output
during the extraction process.
Users will specify what they want documented in their initial message
Start working immediately based on their request
Only ask for clarification if genuinely ambiguous
Multiple features with identical names found
Request is genuinely ambiguous (rare)
User explicitly asks for options
I found multiple authentication systems. Which one should I document?
JWT-based authentication system (src/auth/jwt/*)
OAuth2 integration (src/auth/oauth/*)
Basic authentication middleware (src/middleware/basic-auth.ts)
All authentication features comprehensively
]]>
Starting major analysis phase
Completed significant extraction
Found unexpected complexity
Discovered related features
Analyzing [component/feature]...
- Found [X] files related to [feature]
- Identified [Y] API endpoints
- Discovered [Z] configuration options
Alert user to potential security concerns found during analysis
Note deprecated features that need migration documentation
Highlight areas where code lacks inline documentation
Warn about intricate dependency chains affecting the feature
Use # for main title only
Use ## for major sections
Use ### for subsections
Use #### sparingly for minor subsections
Never skip heading levels
Always specify language for syntax highlighting
Use appropriate language identifiers (typescript, javascript, json, yaml, bash)
Include file paths as comments when relevant
{
// Implementation
}
}
```
]]>
Use tables for structured data like configurations
Include headers with proper alignment
Keep cell content concise
Use bullet points for unordered lists
Use numbers for sequential steps
Nest lists with proper indentation
Keep list items parallel in structure
[Link text](#section-anchor)
Use lowercase, hyphenated anchors
Test all internal links
[Link text](https://example.com)
Use HTTPS when available
Link to official documentation
`path/to/file.ts`
Use relative paths from project root
Use backticks for inline file references
> ⚠️ **Warning**: [message]
Security concerns, breaking changes, deprecations
> 📝 **Note**: [message]
Important information, clarifications
> 💡 **Tip**: [message]
Best practices, optimization suggestions
Be conversational and approachable
Use active voice and "you" to address the reader
Lead with benefits, not features
Use concrete examples and scenarios
Keep paragraphs short and scannable
Avoid unnecessary technical details
Write as if explaining to a colleague who isn't technical
Use analogies and comparisons to familiar concepts
Focus on "what" and "why" before "how"
Include practical examples users can relate to
Address common concerns and questions directly
Friendly, helpful, encouraging
Plain language, minimal jargon
Real-world scenarios, before/after comparisons
Problem → Solution → Benefits → How to use
Technical when needed, but still approachable
Use standard programming terminology
Include code snippets and implementation details
Friendly, instructional, step-by-step
Avoid technical jargon, explain concepts simply
Use screenshots and real-world scenarios
Professional, operational focus
Use IT/DevOps terminology
Include command-line examples and configurations
Business-oriented, value-focused
Use business terminology, avoid implementation details
Include metrics, ROI, and business benefits
Summary of what was documented
Key findings or insights
File location and name
Suggestions for next steps (if applicable)
I couldn't find a feature matching "[feature name]". Here are some similar features I found:
- [List similar features]
Would you like me to document one of these instead?
The code for [feature] has limited inline documentation. I'll extract what I can from:
- Code structure and naming
- Test files
- Related documentation
- Usage patterns
This feature is quite complex with [X] components. Would you like me to:
- Document everything comprehensively (may result in a large document)
- Focus on the core functionality
- Split into multiple documentation files
All sections have content (no placeholders)
Code examples are syntactically correct
Links and cross-references work
Tables are properly formatted
Version information is included
File naming follows convention