Imported from doocs/leetcode (AGENTS.md). Install upstream with npx skills add doocs/leetcode. Copyright stays with the author.

AGENTS.md

This file provides guidance to AI coding assistants when working with code in this repository.

Repository Overview

This is doocs/leetcode — a large collection of LeetCode, Coding Interviews, and other algorithm problem solutions, each implemented in multiple programming languages (Python, Java, C++, Go, TypeScript, Rust, C#, PHP, JavaScript, Kotlin, Swift, Scala, Ruby, Nim, Shell, SQL).

Directory Structure

• solution/ — Main LeetCode solutions, organized by problem number ranges (e.g., 0000-0099/, 0100-0199/). Each problem has its own directory (e.g., 0000-0099/0001.Two Sum/) containing:

  • README.md / README_EN.md — Chinese/English problem descriptions
  • Solution.{py,java,cpp,go,ts,cs,rs,...} — Solution files in each language
  • Follow standard LeetCode class-based structure: class Solution with the method

• lcof/ — Coding Interviews (2nd Edition); problem directories use Chinese titles

• lcof2/ — Coding Interviews (Special Edition)

• lcci/ — Cracking the Coding Interview (6th Edition) — 01.01.Is Unique format

• lcp/ — LeetCode Contest Problems

• lcs/ — LeetCode Contest (separate series)

• basic/ — Basic algorithm implementations (sorting algorithms like BubbleSort, QuickSort, etc.)

Branch model

• main — problem sources, lint tooling, and deploy workflows.
• docs — MkDocs site engine only (build_site.py, mkdocs.yml, hooks/, overrides/). Problem pages are generated at deploy time from main.

Deploy checks out both branches, overlays a whitelist from docs onto main, runs python3 build_site.py, then builds zh/en in parallel. Content pushes on main (problem trees, worker.js, and wrangler.jsonc) go through deploy-request.yml (about 90s quiet period, then gh workflow run deploy.yml). Pushes to docs use .github/workflows/trigger-deploy.yml on the docs branch the same way. A started deploy.yml run is not cancelled. Gitee Pages publish is a separate publish-gitee.yml workflow dispatched after the site build, so a slow Gitee push does not hold the deploy-site concurrency group. Pushes to main run sync-gitee.yml to force-push that branch to Gitee; pushes to docs run trigger-sync-gitee.yml on the docs branch, which dispatches the same sync for docs. Branch mirroring uses its own concurrency group and does not queue site deploys.

Dependabot updates npm, GitHub Actions, and pip on main, and pip on docs.

Development Workflow

Adding a New Solution

1. Create a new problem directory under the appropriate parent (e.g., solution/0000-0099/0042.My Problem/)
2. Add Solution.py, Solution.java, Solution.cpp, Solution.go, Solution.ts, Solution.rs, Solution.cs, etc.
3. Add README.md and README_EN.md from solution/template.md (problem statement, methods, complexity, code tabs)
4. Optionally add a Thinking block after a method heading (see Thinking section). READMEs may omit it.
5. All language solutions must implement the same algorithm logic
6. Open the PR with .github/pull_request_template.md and complete the checklist (see also CONTRIBUTING.md)

Code Formatting

All code must be formatted before committing. The lint-staged hooks run automatically on pre-commit:

# JavaScript/TypeScript/PHP/SQL/Markdown
pnpm exec prettier --write "**/*.{js,ts,php,sql,md}"

# Python
node scripts/run-py.js -m black -S <file>

# C/C++/Java (LLVM 23 via pip clang-format)
node scripts/run-py.js run_format.py --clang-format <file>

# Go (adds/removes the `package main` header used by Solution.go files)
node scripts/run-py.js run_format.py --gofmt <file>

# Rust
rustfmt --edition 2021 <file>

Or run the full formatting script:

node scripts/run-py.js run_format.py

Installation

pnpm install              # Node/pnpm devDependencies (uses the committed lockfile)
pnpm run setup:python     # Optional: black and the problem-sync spider

CI/CD

GitHub Actions automatically run:

• clang-format lint on changed C/C++/Java files (LLVM 23, same pip package as local)
• Black lint on changed Python files
• gofmt lint on changed Go files
• rustfmt lint on changed Rust files
• Prettier on JS/TS/PHP/SQL/Markdown files (auto-format same-repo PRs to main; --check on all PRs)
• thinking-check on changed README.md / README_EN.md: existing Thinking blocks must be non-empty and not outnumber method headings. Missing blocks are allowed.
• Deploy as described under Branch model. Same-repo Prettier uses pull_request_target and skips forks so it never installs untrusted package.json.

Solution Patterns

• Python solutions use List from typing (imported implicitly by LeetCode environment)
• Go solutions include package main header (added/removed by formatting script)
• PHP solutions include <?php header (added/removed by formatting script)
• SQL solutions uppercase built-in function names (handled by run_format.py)
• C# solutions contributed by @kfstorm; match existing brace style and do not add CSharpier

Key Conventions

• Problem directories follow naming convention: {NUMBER}.{Problem Name with Spaces}
• Each solution file is named Solution.{ext} (capital S)
• README files use special HTML comment markers for templating (e.g., <!-- problem:start -->, <!-- solution:start -->, <!-- thinking:start -->)
• A method heading may be followed by an optional Thinking block; see below
• Solutions should match the problem's required class/method signature from LeetCode
• New and updated solution PRs use .github/pull_request_template.md

Thinking section (how we arrive at the answer)

Optional in README.md / README_EN.md. When present, teach the path to the solution, not only the finished algorithm.

• Insert a **Thinking** blockquote (use the matching Chinese label from solution/template.md in README.md) immediately after the method heading, wrapped in <!-- thinking:start --> / <!-- thinking:end -->, before the existing algorithm write-up. Do not add a page-level or #### heading — the quote box is what separates path-to-answer from the formal write-up.
• Keep the original algorithm steps, complexity, and code tabs unchanged. Do not add a page-level Thinking heading.
• Walk in four beats: naive first idea and whether it fits the constraints; the bottleneck; the key observation that reshapes the problem; why this method's data structure and operation order follow from that observation.
• Write against the code that is actually in the repo. Do not describe a different algorithm. Do not restate the step-by-step that already follows.
• For later methods, only explain what the previous method still lacks (space, constants, implementation). Typical length is 3–6 sentences; hard problems may be longer. Match the existing voice (first-person plural in Chinese READMEs, LaTeX variables).
• The Chinese walkthrough must read as the same formal written prose as the algorithm section that follows. Vary sentence openings and use complete paragraphs. Do not use template slogans.