Files
lighthouse/.claude/commands/release.md
Jimmy Chen 8948159a40 Add AI assistant documentation and commands (#8785)
* 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)
2026-02-09 23:41:57 -07:00

86 lines
2.2 KiB
Markdown

# Release Notes Generation Task
You are generating release notes for a new Lighthouse version.
## Input Required
- **Version number** (e.g., v8.1.0)
- **Base branch** (typically `stable` for previous release)
- **Release branch** (e.g., `release-v8.1`)
- **Release name** (Rick and Morty character - check existing to avoid duplicates)
## Step 1: Gather Changes
```bash
# Get commits between branches
git log --oneline origin/<base-branch>..origin/<release-branch>
# Check existing release names
gh release list --repo sigp/lighthouse --limit 50
```
## Step 2: Analyze PRs
For each PR:
1. Extract PR numbers from commit messages
2. Check for `backwards-incompat` label:
```bash
gh pr view <PR> --repo sigp/lighthouse --json labels --jq '[.labels[].name] | join(",")'
```
3. Get PR details for context
## Step 3: Categorize
Group into sections (skip empty):
- **Breaking Changes** - schema changes, CLI changes, API changes
- **Performance Improvements** - user-noticeable optimizations
- **Validator Client Improvements** - VC-specific changes
- **Other Notable Changes** - new features, metrics
- **CLI Changes** - new/changed flags (note if BN or VC)
- **Bug Fixes** - significant user-facing fixes only
## Step 4: Write Release Notes
```markdown
## <Release Name>
## Summary
Lighthouse v<VERSION> includes <brief description>.
This is a <recommended/mandatory> upgrade for <target users>.
## <Section>
- **<Title>** (#<PR>): <User-facing description>
## Update Priority
| User Class | Beacon Node | Validator Client |
|:------------------|:------------|:-----------------|
| Staking Users | Low/Medium/High | Low/Medium/High |
| Non-Staking Users | Low/Medium/High | --- |
## All Changes
- <commit title> (#<PR>)
## Binaries
[See pre-built binaries documentation.](https://lighthouse-book.sigmaprime.io/installation_binaries.html)
```
## Guidelines
- State **user impact**, not implementation details
- Avoid jargon users won't understand
- For CLI flags, mention if BN or VC
- Check PR descriptions for context
## Step 5: Generate Announcements
Create drafts for:
- **Email** - Formal, include priority table
- **Discord** - Tag @everyone, shorter
- **Twitter** - Single tweet, 2-3 highlights