{"owner":"doocs","repo":"leetcode","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":2519,"categories":["root-instruction","anthropic-skill"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".agents/skills/git-commit/SKILL.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nThis file provides guidance to AI coding assistants when working with code in this repository.\n\n## Repository Overview\n\nThis is [doocs/leetcode](https://github.com/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).\n\n## Directory Structure\n\n- **`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:\n    - `README.md` / `README_EN.md` — Chinese/English problem descriptions\n    - `Solution.{py,java,cpp,go,ts,cs,rs,...}` — Solution files in each language\n    - Follow standard LeetCode class-based structure: `class Solution` with the method\n\n- **`lcof/`** — Coding Interviews (2nd Edition); problem directories use Chinese titles\n- **`lcof2/`** — Coding Interviews (Special Edition)\n- **`lcci/`** — Cracking the Coding Interview (6th Edition) — `01.01.Is Unique` format\n- **`lcp/`** — LeetCode Contest Problems\n- **`lcs/`** — LeetCode Contest (separate series)\n- **`basic/`** — Basic algorithm implementations (sorting algorithms like BubbleSort, QuickSort, etc.)\n\n## Branch model\n\n- **`main`** — problem sources, lint tooling, and deploy workflows.\n- **`docs`** — MkDocs site engine only (`build_site.py`, `mkdocs.yml`, `hooks/`, `overrides/`). Problem pages are generated at deploy time from `main`.\n\nDeploy 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.\n\nDependabot updates npm, GitHub Actions, and pip on `main`, and pip on `docs`.\n\n## Development Workflow\n\n### Adding a New Solution\n\n1. Create a new problem directory under the appropriate parent (e.g., `solution/0000-0099/0042.My Problem/`)\n2. Add `Solution.py`, `Solution.java`, `Solution.cpp`, `Solution.go`, `Solution.ts`, `Solution.rs`, `Solution.cs`, etc.\n3. Add `README.md` and `README_EN.md` from `solution/template.md` (problem statement, methods, complexity, code tabs)\n4. Optionally add a Thinking block after a method heading (see [Thinking section](#thinking-section-how-we-arrive-at-the-answer)). READMEs may omit it.\n5. All language solutions must implement the same algorithm logic\n6. Open the PR with `.github/pull_request_template.md` and complete the checklist (see also `CONTRIBUTING.md`)\n\n### Code Formatting\n\nAll code must be formatted before committing. The lint-staged hooks run automatically on pre-commit:\n\n```bash\n# JavaScript/TypeScript/PHP/SQL/Markdown\npnpm exec prettier --write \"**/*.{js,ts,php,sql,md}\"\n\n# Python\nnode scripts/run-py.js -m black -S <file>\n\n# C/C++/Java (LLVM 23 via pip clang-format)\nnode scripts/run-py.js run_format.py --clang-format <file>\n\n# Go (adds/removes the `package main` header used by Solution.go files)\nnode scripts/run-py.js run_format.py --gofmt <file>\n\n# Rust\nrustfmt --edition 2021 <file>\n```\n\nOr run the full formatting script:\n\n```bash\nnode scripts/run-py.js run_format.py\n```\n\n### Installation\n\n```bash\npnpm install              # Node/pnpm devDependencies (uses the committed lockfile)\npnpm run setup:python     # Optional: black and the problem-sync spider\n```\n\n### CI/CD\n\nGitHub Actions automatically run:\n\n- **clang-format** lint on changed C/C++/Java files (LLVM 23, same pip package as local)\n- **Black** lint on changed Python files\n- **gofmt** lint on changed Go files\n- **rustfmt** lint on changed Rust files\n- **Prettier** on JS/TS/PHP/SQL/Markdown files (auto-format same-repo PRs to `main`; `--check` on all PRs)\n- **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.\n- **Deploy** as described under Branch model. Same-repo Prettier uses `pull_request_target` and skips forks so it never installs untrusted `package.json`.\n\n## Solution Patterns\n\n- Python solutions use `List` from typing (imported implicitly by LeetCode environment)\n- Go solutions include `package main` header (added/removed by formatting script)\n- PHP solutions include `<?php` header (added/removed by formatting script)\n- SQL solutions uppercase built-in function names (handled by `run_format.py`)\n- C# solutions contributed by [@kfstorm](https://github.com/kfstorm); match existing brace style and do not add CSharpier\n\n## Key Conventions\n\n- Problem directories follow naming convention: `{NUMBER}.{Problem Name with Spaces}`\n- Each solution file is named `Solution.{ext}` (capital S)\n- README files use special HTML comment markers for templating (e.g., `<!-- problem:start -->`, `<!-- solution:start -->`, `<!-- thinking:start -->`)\n- A method heading may be followed by an optional Thinking block; see below\n- Solutions should match the problem's required class/method signature from LeetCode\n- New and updated solution PRs use `.github/pull_request_template.md`\n\n## Thinking section (how we arrive at the answer)\n\nOptional in `README.md` / `README_EN.md`. When present, teach the path to the solution, not only the finished algorithm.\n\n- 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.\n- Keep the original algorithm steps, complexity, and code tabs unchanged. Do not add a page-level Thinking heading.\n- 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.\n- 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.\n- 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).\n- 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.\n",".agents/skills/git-commit/SKILL.md":"---\nname: git-commit\ndescription: 'Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions \"/commit\". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping'\nlicense: MIT\nallowed-tools: Bash\n---\n\n# Git Commit with Conventional Commits\n\n## Overview\n\nCreate standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.\n\n## Conventional Commit Format\n\n```\n<type>[optional scope]: <description>\n\n[optional body]\n\n[optional footer(s)]\n```\n\n## Commit Types\n\n| Type       | Purpose                        |\n| ---------- | ------------------------------ |\n| `feat`     | New feature                    |\n| `fix`      | Bug fix                        |\n| `docs`     | Documentation only             |\n| `style`    | Formatting/style (no logic)    |\n| `refactor` | Code refactor (no feature/fix) |\n| `perf`     | Performance improvement        |\n| `test`     | Add/update tests               |\n| `build`    | Build system/dependencies      |\n| `ci`       | CI/config changes              |\n| `chore`    | Maintenance/misc               |\n| `revert`   | Revert commit                  |\n\n## Breaking Changes\n\n```\n# Exclamation mark after type/scope\nfeat!: remove deprecated endpoint\n\n# BREAKING CHANGE footer\nfeat: allow config to extend other configs\n\nBREAKING CHANGE: `extends` key behavior changed\n```\n\n## Workflow\n\n### 1. Analyze Diff\n\n```bash\n# If files are staged, use staged diff\ngit diff --staged\n\n# If nothing staged, use working tree diff\ngit diff\n\n# Also check status\ngit status --porcelain\n```\n\n### 2. Stage Files (if needed)\n\nIf nothing is staged or you want to group changes differently:\n\n```bash\n# Stage specific files\ngit add path/to/file1 path/to/file2\n\n# Stage by pattern\ngit add *.test.*\ngit add src/components/*\n\n# Interactive staging\ngit add -p\n```\n\n**Never commit secrets** (.env, credentials.json, private keys).\n\n### 3. Generate Commit Message\n\nAnalyze the diff to determine:\n\n- **Type**: What kind of change is this?\n- **Scope**: What area/module is affected?\n- **Description**: One-line summary of what changed (present tense, imperative mood, <72 chars)\n\n### 4. Execute Commit\n\n```bash\n# Single line\ngit commit -m \"<type>[scope]: <description>\"\n\n# Multi-line with body/footer\ngit commit -m \"$(cat <<'EOF'\n<type>[scope]: <description>\n\n<optional body>\n\n<optional footer>\nEOF\n)\"\n```\n\n## Best Practices\n\n- One logical change per commit\n- Present tense: \"add\" not \"added\"\n- Imperative mood: \"fix bug\" not \"fixes bug\"\n- Reference issues: `Closes #123`, `Refs #456`\n- Keep description under 72 characters\n- **Always use English for commit messages.** Never use other languages.\n\n## Git Safety Protocol\n\n- NEVER update git config\n- NEVER run destructive commands (--force, hard reset) without explicit request\n- NEVER skip hooks (--no-verify) unless user asks\n- NEVER force push to main/master\n- If commit fails due to hooks, fix and create NEW commit (don't amend)\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nThis file provides guidance to AI coding assistants when working with code in this repository.\n\n## Repository Overview\n\nThis is [doocs/leetcode](https://github.com/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).\n\n## Directory Structure\n\n- **`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:\n    - `README.md` / `README_EN.md` — Chinese/English problem descriptions\n    - `Solution.{py,java,cpp,go,ts,cs,rs,...}` — Solution files in each language\n    - Follow standard LeetCode class-based structure: `class Solution` with the method\n\n- **`lcof/`** — Coding Interviews (2nd Edition); problem directories use Chinese titles\n- **`lcof2/`** — Coding Interviews (Special Edition)\n- **`lcci/`** — Cracking the Coding Interview (6th Edition) — `01.01.Is Unique` format\n- **`lcp/`** — LeetCode Contest Problems\n- **`lcs/`** — LeetCode Contest (separate series)\n- **`basic/`** — Basic algorithm implementations (sorting algorithms like BubbleSort, QuickSort, etc.)\n\n## Branch model\n\n- **`main`** — problem sources, lint tooling, and deploy workflows.\n- **`docs`** — MkDocs site engine only (`build_site.py`, `mkdocs.yml`, `hooks/`, `overrides/`). Problem pages are generated at deploy time from `main`.\n\nDeploy 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.\n\nDependabot updates npm, GitHub Actions, and pip on `main`, and pip on `docs`.\n\n## Development Workflow\n\n### Adding a New Solution\n\n1. Create a new problem directory under the appropriate parent (e.g., `solution/0000-0099/0042.My Problem/`)\n2. Add `Solution.py`, `Solution.java`, `Solution.cpp`, `Solution.go`, `Solution.ts`, `Solution.rs`, `Solution.cs`, etc.\n3. Add `README.md` and `README_EN.md` from `solution/template.md` (problem statement, methods, complexity, code tabs)\n4. Optionally add a Thinking block after a method heading (see [Thinking section](#thinking-section-how-we-arrive-at-the-answer)). READMEs may omit it.\n5. All language solutions must implement the same algorithm logic\n6. Open the PR with `.github/pull_request_template.md` and complete the checklist (see also `CONTRIBUTING.md`)\n\n### Code Formatting\n\nAll code must be formatted before committing. The lint-staged hooks run automatically on pre-commit:\n\n```bash\n# JavaScript/TypeScript/PHP/SQL/Markdown\npnpm exec prettier --write \"**/*.{js,ts,php,sql,md}\"\n\n# Python\nnode scripts/run-py.js -m black -S <file>\n\n# C/C++/Java (LLVM 23 via pip clang-format)\nnode scripts/run-py.js run_format.py --clang-format <file>\n\n# Go (adds/removes the `package main` header used by Solution.go files)\nnode scripts/run-py.js run_format.py --gofmt <file>\n\n# Rust\nrustfmt --edition 2021 <file>\n```\n\nOr run the full formatting script:\n\n```bash\nnode scripts/run-py.js run_format.py\n```\n\n### Installation\n\n```bash\npnpm install              # Node/pnpm devDependencies (uses the committed lockfile)\npnpm run setup:python     # Optional: black and the problem-sync spider\n```\n\n### CI/CD\n\nGitHub Actions automatically run:\n\n- **clang-format** lint on changed C/C++/Java files (LLVM 23, same pip package as local)\n- **Black** lint on changed Python files\n- **gofmt** lint on changed Go files\n- **rustfmt** lint on changed Rust files\n- **Prettier** on JS/TS/PHP/SQL/Markdown files (auto-format same-repo PRs to `main`; `--check` on all PRs)\n- **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.\n- **Deploy** as described under Branch model. Same-repo Prettier uses `pull_request_target` and skips forks so it never installs untrusted `package.json`.\n\n## Solution Patterns\n\n- Python solutions use `List` from typing (imported implicitly by LeetCode environment)\n- Go solutions include `package main` header (added/removed by formatting script)\n- PHP solutions include `<?php` header (added/removed by formatting script)\n- SQL solutions uppercase built-in function names (handled by `run_format.py`)\n- C# solutions contributed by [@kfstorm](https://github.com/kfstorm); match existing brace style and do not add CSharpier\n\n## Key Conventions\n\n- Problem directories follow naming convention: `{NUMBER}.{Problem Name with Spaces}`\n- Each solution file is named `Solution.{ext}` (capital S)\n- README files use special HTML comment markers for templating (e.g., `<!-- problem:start -->`, `<!-- solution:start -->`, `<!-- thinking:start -->`)\n- A method heading may be followed by an optional Thinking block; see below\n- Solutions should match the problem's required class/method signature from LeetCode\n- New and updated solution PRs use `.github/pull_request_template.md`\n\n## Thinking section (how we arrive at the answer)\n\nOptional in `README.md` / `README_EN.md`. When present, teach the path to the solution, not only the finished algorithm.\n\n- 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.\n- Keep the original algorithm steps, complexity, and code tabs unchanged. Do not add a page-level Thinking heading.\n- 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.\n- 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.\n- 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).\n- 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.\n",".agents/skills/git-commit/SKILL.md":"---\nname: git-commit\ndescription: 'Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions \"/commit\". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping'\nlicense: MIT\nallowed-tools: Bash\n---\n\n# Git Commit with Conventional Commits\n\n## Overview\n\nCreate standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.\n\n## Conventional Commit Format\n\n```\n<type>[optional scope]: <description>\n\n[optional body]\n\n[optional footer(s)]\n```\n\n## Commit Types\n\n| Type       | Purpose                        |\n| ---------- | ------------------------------ |\n| `feat`     | New feature                    |\n| `fix`      | Bug fix                        |\n| `docs`     | Documentation only             |\n| `style`    | Formatting/style (no logic)    |\n| `refactor` | Code refactor (no feature/fix) |\n| `perf`     | Performance improvement        |\n| `test`     | Add/update tests               |\n| `build`    | Build system/dependencies      |\n| `ci`       | CI/config changes              |\n| `chore`    | Maintenance/misc               |\n| `revert`   | Revert commit                  |\n\n## Breaking Changes\n\n```\n# Exclamation mark after type/scope\nfeat!: remove deprecated endpoint\n\n# BREAKING CHANGE footer\nfeat: allow config to extend other configs\n\nBREAKING CHANGE: `extends` key behavior changed\n```\n\n## Workflow\n\n### 1. Analyze Diff\n\n```bash\n# If files are staged, use staged diff\ngit diff --staged\n\n# If nothing staged, use working tree diff\ngit diff\n\n# Also check status\ngit status --porcelain\n```\n\n### 2. Stage Files (if needed)\n\nIf nothing is staged or you want to group changes differently:\n\n```bash\n# Stage specific files\ngit add path/to/file1 path/to/file2\n\n# Stage by pattern\ngit add *.test.*\ngit add src/components/*\n\n# Interactive staging\ngit add -p\n```\n\n**Never commit secrets** (.env, credentials.json, private keys).\n\n### 3. Generate Commit Message\n\nAnalyze the diff to determine:\n\n- **Type**: What kind of change is this?\n- **Scope**: What area/module is affected?\n- **Description**: One-line summary of what changed (present tense, imperative mood, <72 chars)\n\n### 4. Execute Commit\n\n```bash\n# Single line\ngit commit -m \"<type>[scope]: <description>\"\n\n# Multi-line with body/footer\ngit commit -m \"$(cat <<'EOF'\n<type>[scope]: <description>\n\n<optional body>\n\n<optional footer>\nEOF\n)\"\n```\n\n## Best Practices\n\n- One logical change per commit\n- Present tense: \"add\" not \"added\"\n- Imperative mood: \"fix bug\" not \"fixes bug\"\n- Reference issues: `Closes #123`, `Refs #456`\n- Keep description under 72 characters\n- **Always use English for commit messages.** Never use other languages.\n\n## Git Safety Protocol\n\n- NEVER update git config\n- NEVER run destructive commands (--force, hard reset) without explicit request\n- NEVER skip hooks (--no-verify) unless user asks\n- NEVER force push to main/master\n- If commit fails due to hooks, fix and create NEW commit (don't amend)\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/doocs/leetcode/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nThis file provides guidance to AI coding assistants when working with code in this repository.\n\n## Repository Overview\n\nThis is [doocs/leetcode](https://github.com/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).\n\n## Directory Structure\n\n- **`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:\n    - `README.md` / `README_EN.md` — Chinese/English problem descriptions\n    - `Solution.{py,java,cpp,go,ts,cs,rs,...}` — Solution files in each language\n    - Follow standard LeetCode class-based structure: `class Solution` with the method\n\n- **`lcof/`** — Coding Interviews (2nd Edition); problem directories use Chinese titles\n- **`lcof2/`** — Coding Interviews (Special Edition)\n- **`lcci/`** — Cracking the Coding Interview (6th Edition) — `01.01.Is Unique` format\n- **`lcp/`** — LeetCode Contest Problems\n- **`lcs/`** — LeetCode Contest (separate series)\n- **`basic/`** — Basic algorithm implementations (sorting algorithms like BubbleSort, QuickSort, etc.)\n\n## Branch model\n\n- **`main`** — problem sources, lint tooling, and deploy workflows.\n- **`docs`** — MkDocs site engine only (`build_site.py`, `mkdocs.yml`, `hooks/`, `overrides/`). Problem pages are generated at deploy time from `main`.\n\nDeploy 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.\n\nDependabot updates npm, GitHub Actions, and pip on `main`, and pip on `docs`.\n\n## Development Workflow\n\n### Adding a New Solution\n\n1. Create a new problem directory under the appropriate parent (e.g., `solution/0000-0099/0042.My Problem/`)\n2. Add `Solution.py`, `Solution.java`, `Solution.cpp`, `Solution.go`, `Solution.ts`, `Solution.rs`, `Solution.cs`, etc.\n3. Add `README.md` and `README_EN.md` from `solution/template.md` (problem statement, methods, complexity, code tabs)\n4. Optionally add a Thinking block after a method heading (see [Thinking section](#thinking-section-how-we-arrive-at-the-answer)). READMEs may omit it.\n5. All language solutions must implement the same algorithm logic\n6. Open the PR with `.github/pull_request_template.md` and complete the checklist (see also `CONTRIBUTING.md`)\n\n### Code Formatting\n\nAll code must be formatted before committing. The lint-staged hooks run automatically on pre-commit:\n\n```bash\n# JavaScript/TypeScript/PHP/SQL/Markdown\npnpm exec prettier --write \"**/*.{js,ts,php,sql,md}\"\n\n# Python\nnode scripts/run-py.js -m black -S <file>\n\n# C/C++/Java (LLVM 23 via pip clang-format)\nnode scripts/run-py.js run_format.py --clang-format <file>\n\n# Go (adds/removes the `package main` header used by Solution.go files)\nnode scripts/run-py.js run_format.py --gofmt <file>\n\n# Rust\nrustfmt --edition 2021 <file>\n```\n\nOr run the full formatting script:\n\n```bash\nnode scripts/run-py.js run_format.py\n```\n\n### Installation\n\n```bash\npnpm install              # Node/pnpm devDependencies (uses the committed lockfile)\npnpm run setup:python     # Optional: black and the problem-sync spider\n```\n\n### CI/CD\n\nGitHub Actions automatically run:\n\n- **clang-format** lint on changed C/C++/Java files (LLVM 23, same pip package as local)\n- **Black** lint on changed Python files\n- **gofmt** lint on changed Go files\n- **rustfmt** lint on changed Rust files\n- **Prettier** on JS/TS/PHP/SQL/Markdown files (auto-format same-repo PRs to `main`; `--check` on all PRs)\n- **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.\n- **Deploy** as described under Branch model. Same-repo Prettier uses `pull_request_target` and skips forks so it never installs untrusted `package.json`.\n\n## Solution Patterns\n\n- Python solutions use `List` from typing (imported implicitly by LeetCode environment)\n- Go solutions include `package main` header (added/removed by formatting script)\n- PHP solutions include `<?php` header (added/removed by formatting script)\n- SQL solutions uppercase built-in function names (handled by `run_format.py`)\n- C# solutions contributed by [@kfstorm](https://github.com/kfstorm); match existing brace style and do not add CSharpier\n\n## Key Conventions\n\n- Problem directories follow naming convention: `{NUMBER}.{Problem Name with Spaces}`\n- Each solution file is named `Solution.{ext}` (capital S)\n- README files use special HTML comment markers for templating (e.g., `<!-- problem:start -->`, `<!-- solution:start -->`, `<!-- thinking:start -->`)\n- A method heading may be followed by an optional Thinking block; see below\n- Solutions should match the problem's required class/method signature from LeetCode\n- New and updated solution PRs use `.github/pull_request_template.md`\n\n## Thinking section (how we arrive at the answer)\n\nOptional in `README.md` / `README_EN.md`. When present, teach the path to the solution, not only the finished algorithm.\n\n- 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.\n- Keep the original algorithm steps, complexity, and code tabs unchanged. Do not add a page-level Thinking heading.\n- 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.\n- 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.\n- 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).\n- 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.\n","isInternal":false,"tokens":1757,"sizeBytes":7290},{"name":"SKILL.md","path":".agents/skills/git-commit/SKILL.md","rawUrl":"https://raw.githubusercontent.com/doocs/leetcode/HEAD/.agents/skills/git-commit/SKILL.md","title":"git-commit","category":"anthropic-skill","format":"markdown","content":"---\nname: git-commit\ndescription: 'Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions \"/commit\". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping'\nlicense: MIT\nallowed-tools: Bash\n---\n\n# Git Commit with Conventional Commits\n\n## Overview\n\nCreate standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.\n\n## Conventional Commit Format\n\n```\n<type>[optional scope]: <description>\n\n[optional body]\n\n[optional footer(s)]\n```\n\n## Commit Types\n\n| Type       | Purpose                        |\n| ---------- | ------------------------------ |\n| `feat`     | New feature                    |\n| `fix`      | Bug fix                        |\n| `docs`     | Documentation only             |\n| `style`    | Formatting/style (no logic)    |\n| `refactor` | Code refactor (no feature/fix) |\n| `perf`     | Performance improvement        |\n| `test`     | Add/update tests               |\n| `build`    | Build system/dependencies      |\n| `ci`       | CI/config changes              |\n| `chore`    | Maintenance/misc               |\n| `revert`   | Revert commit                  |\n\n## Breaking Changes\n\n```\n# Exclamation mark after type/scope\nfeat!: remove deprecated endpoint\n\n# BREAKING CHANGE footer\nfeat: allow config to extend other configs\n\nBREAKING CHANGE: `extends` key behavior changed\n```\n\n## Workflow\n\n### 1. Analyze Diff\n\n```bash\n# If files are staged, use staged diff\ngit diff --staged\n\n# If nothing staged, use working tree diff\ngit diff\n\n# Also check status\ngit status --porcelain\n```\n\n### 2. Stage Files (if needed)\n\nIf nothing is staged or you want to group changes differently:\n\n```bash\n# Stage specific files\ngit add path/to/file1 path/to/file2\n\n# Stage by pattern\ngit add *.test.*\ngit add src/components/*\n\n# Interactive staging\ngit add -p\n```\n\n**Never commit secrets** (.env, credentials.json, private keys).\n\n### 3. Generate Commit Message\n\nAnalyze the diff to determine:\n\n- **Type**: What kind of change is this?\n- **Scope**: What area/module is affected?\n- **Description**: One-line summary of what changed (present tense, imperative mood, <72 chars)\n\n### 4. Execute Commit\n\n```bash\n# Single line\ngit commit -m \"<type>[scope]: <description>\"\n\n# Multi-line with body/footer\ngit commit -m \"$(cat <<'EOF'\n<type>[scope]: <description>\n\n<optional body>\n\n<optional footer>\nEOF\n)\"\n```\n\n## Best Practices\n\n- One logical change per commit\n- Present tense: \"add\" not \"added\"\n- Imperative mood: \"fix bug\" not \"fixes bug\"\n- Reference issues: `Closes #123`, `Refs #456`\n- Keep description under 72 characters\n- **Always use English for commit messages.** Never use other languages.\n\n## Git Safety Protocol\n\n- NEVER update git config\n- NEVER run destructive commands (--force, hard reset) without explicit request\n- NEVER skip hooks (--no-verify) unless user asks\n- NEVER force push to main/master\n- If commit fails due to hooks, fix and create NEW commit (don't amend)\n","frontmatter":{"name":"git-commit","description":"Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions \"/commit\". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping","license":"MIT","allowed-tools":"Bash","allowedTools":["Bash"]},"allowedTools":["Bash"],"isInternal":false,"tokens":762,"sizeBytes":3271}],"systemPromptSnippet":"<yakaai_skills repo=\"doocs/leetcode\">\n<!-- File: AGENTS.md (Tokens: ~1757 | Category: root-instruction) -->\n# AGENTS.md\n\nThis file provides guidance to AI coding assistants when working with code in this repository.\n\n## Repository Overview\n\nThis is [doocs/leetcode](https://github.com/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).\n\n## Directory Structure\n\n- **`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:\n    - `README.md` / `README_EN.md` — Chinese/English problem descriptions\n    - `Solution.{py,java,cpp,go,ts,cs,rs,...}` — Solution files in each language\n    - Follow standard LeetCode class-based structure: `class Solution` with the method\n\n- **`lcof/`** — Coding Interviews (2nd Edition); problem directories use Chinese titles\n- **`lcof2/`** — Coding Interviews (Special Edition)\n- **`lcci/`** — Cracking the Coding Interview (6th Edition) — `01.01.Is Unique` format\n- **`lcp/`** — LeetCode Contest Problems\n- **`lcs/`** — LeetCode Contest (separate series)\n- **`basic/`** — Basic algorithm implementations (sorting algorithms like BubbleSort, QuickSort, etc.)\n\n## Branch model\n\n- **`main`** — problem sources, lint tooling, and deploy workflows.\n- **`docs`** — MkDocs site engine only (`build_site.py`, `mkdocs.yml`, `hooks/`, `overrides/`). Problem pages are generated at deploy time from `main`.\n\nDeploy 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.\n\nDependabot updates npm, GitHub Actions, and pip on `main`, and pip on `docs`.\n\n## Development Workflow\n\n### Adding a New Solution\n\n1. Create a new problem directory under the appropriate parent (e.g., `solution/0000-0099/0042.My Problem/`)\n2. Add `Solution.py`, `Solution.java`, `Solution.cpp`, `Solution.go`, `Solution.ts`, `Solution.rs`, `Solution.cs`, etc.\n3. Add `README.md` and `README_EN.md` from `solution/template.md` (problem statement, methods, complexity, code tabs)\n4. Optionally add a Thinking block after a method heading (see [Thinking section](#thinking-section-how-we-arrive-at-the-answer)). READMEs may omit it.\n5. All language solutions must implement the same algorithm logic\n6. Open the PR with `.github/pull_request_template.md` and complete the checklist (see also `CONTRIBUTING.md`)\n\n### Code Formatting\n\nAll code must be formatted before committing. The lint-staged hooks run automatically on pre-commit:\n\n```bash\n# JavaScript/TypeScript/PHP/SQL/Markdown\npnpm exec prettier --write \"**/*.{js,ts,php,sql,md}\"\n\n# Python\nnode scripts/run-py.js -m black -S <file>\n\n# C/C++/Java (LLVM 23 via pip clang-format)\nnode scripts/run-py.js run_format.py --clang-format <file>\n\n# Go (adds/removes the `package main` header used by Solution.go files)\nnode scripts/run-py.js run_format.py --gofmt <file>\n\n# Rust\nrustfmt --edition 2021 <file>\n```\n\nOr run the full formatting script:\n\n```bash\nnode scripts/run-py.js run_format.py\n```\n\n### Installation\n\n```bash\npnpm install              # Node/pnpm devDependencies (uses the committed lockfile)\npnpm run setup:python     # Optional: black and the problem-sync spider\n```\n\n### CI/CD\n\nGitHub Actions automatically run:\n\n- **clang-format** lint on changed C/C++/Java files (LLVM 23, same pip package as local)\n- **Black** lint on changed Python files\n- **gofmt** lint on changed Go files\n- **rustfmt** lint on changed Rust files\n- **Prettier** on JS/TS/PHP/SQL/Markdown files (auto-format same-repo PRs to `main`; `--check` on all PRs)\n- **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.\n- **Deploy** as described under Branch model. Same-repo Prettier uses `pull_request_target` and skips forks so it never installs untrusted `package.json`.\n\n## Solution Patterns\n\n- Python solutions use `List` from typing (imported implicitly by LeetCode environment)\n- Go solutions include `package main` header (added/removed by formatting script)\n- PHP solutions include `<?php` header (added/removed by formatting script)\n- SQL solutions uppercase built-in function names (handled by `run_format.py`)\n- C# solutions contributed by [@kfstorm](https://github.com/kfstorm); match existing brace style and do not add CSharpier\n\n## Key Conventions\n\n- Problem directories follow naming convention: `{NUMBER}.{Problem Name with Spaces}`\n- Each solution file is named `Solution.{ext}` (capital S)\n- README files use special HTML comment markers for templating (e.g., `<!-- problem:start -->`, `<!-- solution:start -->`, `<!-- thinking:start -->`)\n- A method heading may be followed by an optional Thinking block; see below\n- Solutions should match the problem's required class/method signature from LeetCode\n- New and updated solution PRs use `.github/pull_request_template.md`\n\n## Thinking section (how we arrive at the answer)\n\nOptional in `README.md` / `README_EN.md`. When present, teach the path to the solution, not only the finished algorithm.\n\n- 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.\n- Keep the original algorithm steps, complexity, and code tabs unchanged. Do not add a page-level Thinking heading.\n- 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.\n- 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.\n- 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).\n- 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.\n\n<!-- File: .agents/skills/git-commit/SKILL.md (Tokens: ~762 | Category: anthropic-skill) -->\n---\nname: git-commit\ndescription: 'Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions \"/commit\". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping'\nlicense: MIT\nallowed-tools: Bash\n---\n\n# Git Commit with Conventional Commits\n\n## Overview\n\nCreate standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.\n\n## Conventional Commit Format\n\n```\n<type>[optional scope]: <description>\n\n[optional body]\n\n[optional footer(s)]\n```\n\n## Commit Types\n\n| Type       | Purpose                        |\n| ---------- | ------------------------------ |\n| `feat`     | New feature                    |\n| `fix`      | Bug fix                        |\n| `docs`     | Documentation only             |\n| `style`    | Formatting/style (no logic)    |\n| `refactor` | Code refactor (no feature/fix) |\n| `perf`     | Performance improvement        |\n| `test`     | Add/update tests               |\n| `build`    | Build system/dependencies      |\n| `ci`       | CI/config changes              |\n| `chore`    | Maintenance/misc               |\n| `revert`   | Revert commit                  |\n\n## Breaking Changes\n\n```\n# Exclamation mark after type/scope\nfeat!: remove deprecated endpoint\n\n# BREAKING CHANGE footer\nfeat: allow config to extend other configs\n\nBREAKING CHANGE: `extends` key behavior changed\n```\n\n## Workflow\n\n### 1. Analyze Diff\n\n```bash\n# If files are staged, use staged diff\ngit diff --staged\n\n# If nothing staged, use working tree diff\ngit diff\n\n# Also check status\ngit status --porcelain\n```\n\n### 2. Stage Files (if needed)\n\nIf nothing is staged or you want to group changes differently:\n\n```bash\n# Stage specific files\ngit add path/to/file1 path/to/file2\n\n# Stage by pattern\ngit add *.test.*\ngit add src/components/*\n\n# Interactive staging\ngit add -p\n```\n\n**Never commit secrets** (.env, credentials.json, private keys).\n\n### 3. Generate Commit Message\n\nAnalyze the diff to determine:\n\n- **Type**: What kind of change is this?\n- **Scope**: What area/module is affected?\n- **Description**: One-line summary of what changed (present tense, imperative mood, <72 chars)\n\n### 4. Execute Commit\n\n```bash\n# Single line\ngit commit -m \"<type>[scope]: <description>\"\n\n# Multi-line with body/footer\ngit commit -m \"$(cat <<'EOF'\n<type>[scope]: <description>\n\n<optional body>\n\n<optional footer>\nEOF\n)\"\n```\n\n## Best Practices\n\n- One logical change per commit\n- Present tense: \"add\" not \"added\"\n- Imperative mood: \"fix bug\" not \"fixes bug\"\n- Reference issues: `Closes #123`, `Refs #456`\n- Keep description under 72 characters\n- **Always use English for commit messages.** Never use other languages.\n\n## Git Safety Protocol\n\n- NEVER update git config\n- NEVER run destructive commands (--force, hard reset) without explicit request\n- NEVER skip hooks (--no-verify) unless user asks\n- NEVER force push to main/master\n- If commit fails due to hooks, fix and create NEW commit (don't amend)\n</yakaai_skills>"}