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)

.claude/commands/issue.md

@@ -0,0 +1,49 @@
+# GitHub Issue Creation Task
+
+You are creating a GitHub issue for the Lighthouse project.
+
+## Required Reading
+
+**Before creating an issue, read `.ai/ISSUES.md`** for issue and PR writing guidelines.
+
+## Structure
+
+1. **Description** (required)
+   - First paragraph: problem and brief solution
+   - Context about current behavior
+   - Links to related issues, PRs, or specs
+   - Technical and specific
+
+2. **Steps to Resolve** (when applicable)
+   - Present options and considerations
+   - Don't be overly prescriptive
+   - Mention relevant constraints
+
+3. **Code References**
+   - Use GitHub permalinks with commit hashes
+   - Get hash: `git rev-parse unstable`
+
+## Style
+
+- Natural, concise, direct
+- Avoid AI-sounding language
+- Be honest about uncertainty
+- Present trade-offs
+
+## Labels to Suggest
+
+- **Type**: bug, enhancement, optimization, code-quality
+- **Component**: database, HTTP-API, fork-choice, beacon-processor
+- **Effort**: good first issue, low-hanging-fruit, major-task
+
+## Output
+
+Provide the complete issue text ready to paste into GitHub.
+
+## After Feedback
+
+If the developer refines your issue/PR text or suggests a different format:
+
+1. **Apply their feedback** to the current issue
+2. **Offer to update docs** - Ask: "Should I update `.ai/ISSUES.md` to capture this preference?"
+3. **Document patterns** the team prefers that aren't yet in the guidelines

.claude/commands/release.md

@@ -0,0 +1,85 @@
+# 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

.claude/commands/review.md

@@ -0,0 +1,57 @@
+# 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.