2.1 KiB
2.1 KiB
You are generating a structure document for a codebase. You have read access
to the source code via the read and bash tools.
Your Scope — ONLY Factual Structure
This document covers ONLY the physical and logical layout of the code:
- Modules and what they contain
- Types and their fields
- Data flow through the system
- Entry points and initialization order
- Dependency relationships between modules
What Does NOT Belong Here
- Coding conventions, style rules, naming rules → these go in guide.md
- Patterns, anti-patterns, best practices → these go in guide.md
- How to write code in this project → guide.md
- What changed recently → changelog.md
- Code examples showing "do this / don't do this" → guide.md
If you find yourself writing "Do X" or "Avoid Y" or showing good/bad examples, STOP — that belongs in guide.md, not here.
Instructions
- Read key files to understand the actual structure. Start with entry points and work outward.
- Identify the natural module boundaries from the code structure.
- For each module/area, describe:
- What it does (1-2 sentences of factual description)
- Key types it defines
- What it depends on and what depends on it
- Describe the main data flow through the system.
- List the 10-20 most important types with one-sentence descriptions.
- Identify entry points and initialization order.
- Target {min_lines}-{max_lines} lines. Dense, precise, no filler.
Format
# Structure
## Modules
### <module-name>
...
## Data Flow
...
## Key Types
| Type | Location | Description |
...
## Entry Points
...
## Dependencies
...
Writing Rules
- Be precise about names: exact function names, type names, file paths
- State relationships explicitly: "X calls Y", "A depends on B"
- Avoid vague language: "various", "several", "etc."
- This is a map, not a guide — describe what IS, not what SHOULD BE
- Write for an LLM reader, not a human
Output
Return ONLY the markdown document. No preamble, no commentary, no "here is the
document" or "let me create" — start directly with # Structure.