mirror of
https://github.com/sigp/lighthouse.git
synced 2026-05-07 16:55:46 +00:00
* Add AI assistant documentation and commands Adds structured documentation for AI coding assistants: - CLAUDE.md / AGENTS.md: Lightweight entry points with critical rules - .ai/: Shared knowledge base (CODE_REVIEW.md, DEVELOPMENT.md, ISSUES.md) - .claude/commands/: Claude Code skills for review, issue, release - .github/copilot-instructions.md: GitHub Copilot instructions Supports Claude Code, OpenAI Codex, and GitHub Copilot with modular, pointer-based structure for maintainability. Includes guidelines for AI assistants to prompt developers about updating these docs after receiving feedback, creating a continuous improvement loop. * Add parallel development tip with git worktrees * Address review feedback - Add missing details to DEVELOPMENT.md: fork-specific testing, database backends, cross-compilation targets, make test-release - Simplify AGENTS.md to pointer to CLAUDE.md (Codex can read files) * Address review feedback - Add priority signaling: Critical vs Important vs Good Practices - Restore actionable file references (canonical_head.rs, test_utils.rs, etc.) - Add Rayon CPU oversubscription context - Add tracing span guidelines - Simplify AGENTS.md to pointer * Address review feedback and remove Copilot instructions - Restore anti-patterns section (over-engineering, unnecessary complexity) - Restore design principles (simplicity first, high cohesion) - Add architecture guidance (dependency bloat, schema migrations, backwards compat) - Improve natural language guidance for AI comments - Add try_read lock pattern - Remove copilot-instructions.md (can't follow file refs, untestable)
58 lines
1.5 KiB
Markdown
58 lines
1.5 KiB
Markdown
# Code Review Task
|
|
|
|
You are reviewing code for the Lighthouse project.
|
|
|
|
## Required Reading
|
|
|
|
**Before reviewing, read `.ai/CODE_REVIEW.md`** for Lighthouse-specific safety requirements and review etiquette.
|
|
|
|
## Focus Areas
|
|
|
|
1. **Consensus Crate Safety** (if applicable)
|
|
- Safe math operations (saturating_*, checked_*)
|
|
- Zero panics
|
|
- Deterministic behavior
|
|
|
|
2. **General Code Safety**
|
|
- No `.unwrap()` or `.expect()` at runtime
|
|
- No array indexing without bounds checks
|
|
- Proper error handling
|
|
|
|
3. **Code Clarity**
|
|
- Clear variable names (avoid ambiguous abbreviations)
|
|
- Well-documented complex logic
|
|
- TODOs linked to GitHub issues
|
|
|
|
4. **Error Handling**
|
|
- Errors are logged, not silently swallowed
|
|
- Edge cases are handled
|
|
- Return values are checked
|
|
|
|
5. **Concurrency & Performance**
|
|
- Lock ordering is safe
|
|
- No blocking in async context
|
|
- Proper use of rayon thread pools
|
|
|
|
## Output
|
|
|
|
- Keep to 3-5 actionable comments
|
|
- Use natural, conversational language
|
|
- Provide specific line references
|
|
- Ask questions rather than making demands
|
|
|
|
## After Review Discussion
|
|
|
|
If the developer corrects your feedback or you learn something new:
|
|
|
|
1. **Acknowledge and learn** - Note what you got wrong
|
|
2. **Offer to update docs** - Ask: "Should I update `.ai/CODE_REVIEW.md` with this lesson?"
|
|
3. **Format the lesson:**
|
|
```markdown
|
|
### Lesson: [Title]
|
|
**Issue:** [What went wrong]
|
|
**Feedback:** [What developer said]
|
|
**Learning:** [What to do differently]
|
|
```
|
|
|
|
This keeps the review guidelines improving over time.
|