|
| 1 | +# Skill: New pull request for TheAlgorithms/Python |
| 2 | + |
| 3 | +Create a new pull request using the rules already written in |
| 4 | +[`CONTRIBUTING.md`](../../../CONTRIBUTING.md). The goal is that creating a new |
| 5 | +pull request (human or AI) can run the same way every time, and that produces a |
| 6 | +clear, kind, tested, type-hinted, mergeable contribution. |
| 7 | + |
| 8 | +## How to run this skill |
| 9 | + |
| 10 | +Make sure that the local `master` branch is synced with `upstream/master` before |
| 11 | +creating a new pull request. |
| 12 | + |
| 13 | +Create a new clearly named branch for the pull request. Pull request changes must |
| 14 | +not be made or submitted on the `master` branch. |
| 15 | + |
| 16 | +Never hand-edit or revert the `uv.lock` file. If you add a legitimate |
| 17 | +dependency, let the `uv-lock` pre-commit hook regenerate it — do not touch it by |
| 18 | +hand. A hand-modified `uv.lock` makes the `algorithms-keeper` bot close the pull |
| 19 | +request as invalid, and even a repo maintainer cannot undo that. |
| 20 | + |
| 21 | +Always check at least one Markdown checkbox in the pull request description (the "Describe your change" section), or the |
| 22 | +`algorithms-keeper` bot will close the pull request as invalid. Any repo maintainer can undo this if you @mention them on the closed pull request. |
| 23 | + |
| 24 | +### 1. Before contributing / Is this an algorithm? |
| 25 | + |
| 26 | +- [ ] The change adds, fixes, or documents **one algorithm** — not multiple, and |
| 27 | + not both code and doctest changes in the same PR. |
| 28 | +- [ ] It is a genuine algorithm or data structure (see the *What is an Algorithm?* |
| 29 | + section), not a script, snippet, how-to-use for an existing API, or exercise |
| 30 | + dump. |
| 31 | +- [ ] It is **not already in the repository** (search the existing directories). |
| 32 | +- [ ] **No earlier open PR** already does the same thing — link it if one exists. |
| 33 | +- [ ] Properly attributed — no plagiarism; prior sources credited. |
| 34 | + |
| 35 | +### 2. Coding Style |
| 36 | + |
| 37 | +- [ ] `from __future__ import annotations` is not needed because this repo only uses |
| 38 | + the latest version of CPython. |
| 39 | +- [ ] File and directory names are lowercase, use underscores, and land inside an |
| 40 | + existing directory. |
| 41 | +- [ ] Public functions/classes have **type hints**. |
| 42 | +- [ ] Public functions have **doctests that actually pass**. |
| 43 | +- [ ] Descriptive variable and function names (no single letters where a word helps). |
| 44 | +- [ ] Code is formatted and lint-clean (`ruff`, `pre-commit`). |
| 45 | +- [ ] `DIRECTORY.md` and `README.md` are **not hand-edited** — the |
| 46 | + `algorithms-keeper` bot regenerates them automatically after merge. |
| 47 | + |
| 48 | +### 3. Other Requirements for Submissions |
| 49 | + |
| 50 | +- [ ] At least one **Wikipedia (or equivalent) URL** documenting the algorithm. |
| 51 | +- [ ] Docstring explains what the function does and its parameters/returns. |
| 52 | +- [ ] No unnecessary third-party dependencies. |
0 commit comments