Files
panopticon/prompts/worker-guide.md
2026-04-06 15:09:41 +02:00

2.2 KiB

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.