76 lines
2.2 KiB
Markdown
76 lines
2.2 KiB
Markdown
You are generating a development guide for a codebase. You have read access
|
|
to the source code via the `read` and `bash` tools.
|
|
|
|
## Your Scope — ONLY Conventions, Patterns, and How-To
|
|
|
|
This document covers ONLY how to write code in this project:
|
|
- Naming conventions
|
|
- Formatting rules
|
|
- Architectural patterns (with code examples)
|
|
- Anti-patterns to avoid (with code examples)
|
|
- Testing conventions
|
|
- Build and development workflow
|
|
|
|
## What Does NOT Belong Here
|
|
|
|
- **Module listings, type catalogs, dependency graphs** → these go in structure.md
|
|
- **Data flow descriptions** → structure.md
|
|
- **Entry points, initialization order** → structure.md
|
|
- **What changed recently** → changelog.md
|
|
- **Describing what each module does** → structure.md
|
|
|
|
If you find yourself listing all the modules or types or describing what each
|
|
system does, STOP — that belongs in structure.md, not here.
|
|
|
|
You may REFERENCE specific types or modules as examples of a pattern, but do not
|
|
catalog them.
|
|
|
|
## Instructions
|
|
|
|
1. If a CLAUDE.md or AGENTS.md exists, read it first — these contain authoritative
|
|
project rules. Summarize and reference them, don't duplicate verbatim.
|
|
2. Read representative source files to discover recurring patterns.
|
|
3. For each pattern, show a concrete code example from the actual codebase.
|
|
4. For each anti-pattern, show what to avoid and why.
|
|
5. Target {min_lines}-{max_lines} lines. Dense, prescriptive, no fluff.
|
|
|
|
## Format
|
|
|
|
```
|
|
# Guide
|
|
|
|
## Conventions
|
|
### Naming
|
|
### Formatting
|
|
### Imports
|
|
|
|
## Patterns
|
|
### <pattern-name>
|
|
<why it exists, code example>
|
|
|
|
## Anti-Patterns
|
|
### <anti-pattern-name>
|
|
<what to avoid, why, code example>
|
|
|
|
## Testing
|
|
### Structure
|
|
### What to Test
|
|
### Running Tests
|
|
|
|
## References
|
|
- See CLAUDE.md for authoritative project rules
|
|
```
|
|
|
|
## Writing Rules
|
|
|
|
- Be prescriptive: "Do X" not "X is sometimes done"
|
|
- Give concrete code examples for each pattern
|
|
- Explain WHY a pattern exists, not just WHAT it is
|
|
- Reference specific types/modules as examples, don't catalog them
|
|
- Write for an LLM reader that will be writing code in this project
|
|
|
|
## Output
|
|
|
|
Return ONLY the markdown document. No preamble, no commentary, no "here is the
|
|
document" or "let me create" — start directly with `# Guide`.
|