proposal: use LLM to accelerate TiDB development workflows

## Enhancement

### Motivation

TiDB development already has a large amount of high-quality documentation, test workflows, and review conventions, but the entry points are still optimized for humans who already know the repository well. LLM-assisted workflows are becoming practical for repetitive engineering tasks, yet they still need explicit repository affordances to be reliable.

Today, common development loops such as flaky test triage, command selection, repo navigation, docs lookup, and repeated review feedback are still fragmented across personal notes, CI logs, and scattered docs. That fragmentation makes it hard to reuse LLMs consistently and safely in day-to-day TiDB development.

### Proposal

Treat "LLM-assisted TiDB development" as an incremental engineering improvement rather than a one-off experiment. The goal is to make the repository easier for LLM tools and human contributors to use together, while keeping correctness and human review as the default gate.

Suggested work items:

1. Add repository-level LLM entry points.
- Maintain a root `llms.txt` that points to canonical developer and user documentation.
- Keep links stable so local or hosted agents can discover the right docs without bespoke prompts.

2. Encode repeatable workflows as skills or playbooks.
- Package common repo tasks such as targeted test selection, failpoint handling, integration-test recording, docs lookup, and optimizer bugfix flows into reusable skills.
- Reduce prompt drift and avoid re-explaining local conventions every time.

3. Use LLMs to assist flaky test investigation.
- Cluster recurring CI failures by signature.
- Summarize the likely failure mode and affected subsystem.
- Generate minimal reproduction hints and next-step checklists for human debugging.

4. Improve contribution ergonomics for repetitive changes.
- Use LLMs to draft issue/PR descriptions, route contributors to the right docs, and surface nearby tests or examples.
- Keep the human in the loop for correctness-sensitive code changes.

### Expected Benefits

- Faster triage for flaky tests and intermittent CI failures.
- Lower overhead for contributors who need to find the correct docs, commands, and validation steps.
- More consistent use of repository conventions across human and agent-driven workflows.
- Better leverage from the documentation and skills that already exist in the repo.

### Non-goals

- No unsupervised landing of correctness-sensitive changes.
- No replacement of existing review, testing, or release gates.
- No requirement that every contributor must use LLM tooling.

### Alternatives Considered

- Keep using ad-hoc prompts and personal notes.
- Low process change, but knowledge remains fragmented and non-reusable.

- Build fully automated coding agents first.
- Higher upside in theory, but too risky before repo workflows and documentation entry points are standardized.

### Adoption Strategy

Start with low-risk, high-leverage pieces:

- repository-level doc discovery (`llms.txt`);
- reusable skills for existing workflows;
- flaky test triage assistance with human verification.

If these pieces prove useful, the next step can be measuring iteration time improvements for tasks such as test triage, docs lookup, and PR preparation.