leetcode-solutions

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

Repository instructions for coding agents

Purpose

This repository records Python solutions completed while following the NeetCode All roadmap and while preparing independently for company online assessments and interviews. Keep solutions readable, easy to explain, compatible with Python 3, and free of external dependencies. Correctness, clear complexity analysis, accurate progress metadata, and focused commits matter more than clever abstractions.

Read CONTRIBUTING.md before making changes. Preserve the user's solution and approach unless correctness or an explicit request requires an edit. Never add confidential assessment content, recruiter messages, or private interview information.

Repository structure and sources of truth

• neetcode-all/<topic-slug>/<problem-number>.py: NeetCode All roadmap solutions.
• data/roadmap.json: source of truth for roadmap topics, dated totals snapshot, problem metadata, personal difficulty, status, solve date, and complexity.
• SOLUTIONS.md: generated roadmap catalog; do not edit it directly.
• README.md: manual prose plus generated roadmap and company summary blocks.
• companies/<company>/company.json: source of truth for personal company practice selected for tracking.
• The external company candidate list is a separate, pinned source layer; never copy its complete dataset into a manifest.
• companies/<company>/README.md and companies/README.md: generated by scripts/company-tracker.js; do not edit them directly.
• scripts/company-tracker.js: thin company CLI orchestration.
• scripts/lib/company.js: company state, validation, workspace rules, and Markdown generation.
• scripts/lib/company-source.js: external source caching, normalization, ranking, filtering, and selection.
• scripts/lib/csv.js: dependency-free CSV parsing.
• scripts/roadmap-tracker.js: roadmap lifecycle CLI for registering, starting, solving, validating, and regenerating roadmap problems.
• scripts/automation.test.js: automation test suite for the automation layer.
• scripts/lib/cli.js: shared CLI parsing and error handling.
• scripts/lib/generated-files.js: generated-file drift detection and writes.
• scripts/lib/json.js: JSON reads and formatting.
• scripts/lib/markdown.js: Markdown generation and escaping.
• scripts/lib/paths.js: canonical repository paths.
• scripts/lib/progress.js: progress aggregation.
• scripts/lib/roadmap.js: roadmap validation and generation.
• scripts/lib/solutions.js: solution scaffolds and solution-file checks.
• scripts/lib/validation.js: shared metadata validation.
• .github/workflows/ci.yml: CI definition.

Keep CLI entry points focused on orchestration. Put reusable behavior in the narrowest existing scripts/lib/ module. Reuse shared rules across roadmap and company flows instead of duplicating logic or adding unnecessary abstractions.

Do not commit cache files, bytecode, editor files, or unrelated changes. Do not overwrite or discard pre-existing user changes.

Workflow 1: add a NeetCode All problem

Use this workflow when asked to add or finish a roadmap problem.

1. Inspect git status, the current diff, nearby solutions, data/roadmap.json, README.md, and SOLUTIONS.md. Confirm that the problem is not already cataloged.
2. Identify the numeric LeetCode ID, exact title, canonical URL, difficulty, and correct registered topic slug. Ask instead of guessing when the topic or metadata is uncertain.
3. If the problem is untracked, register it with node scripts/roadmap-tracker.js add <id> "<title>" <topic-slug> <Easy|Medium|Hard> --url <canonical-url> [--personal-difficulty 1-10]. Never infer a personal rating.
4. If the problem is planned, run node scripts/roadmap-tracker.js start <id>. If the user already created the target solution, preserve it: move it temporarily if needed, run add and start, then restore it. Never let the scaffold replace user work. Skip this command when the manifest already says in-progress.
5. Finish the accepted solution at the tracked path, preserve the LeetCode method signature and local Python style, and remove TODO(roadmap-solution) if the scaffold contains it.
6. Run node scripts/roadmap-tracker.js solve <id> --time "O(...)" --space "O(...)" [--personal-difficulty 1-10]. The first solve records the current UTC instant in solvedAt; another solve is rejected. Never invent or casually replace that timestamp. Define every complexity symbol such as n, k, or a, and distinguish auxiliary space from returned output when useful.
7. Do not manually edit SOLUTIONS.md or generated README marker blocks. Confirm the CLI regenerated the catalog, solved badge, counts, charts, and topic table.
8. Review links, ordering, counts, filename, final newline, whitespace, and the complete diff. Test representative normal and boundary cases when possible.
9. Run the full validation suite under Required pre-commit review.
10. When asked to commit, use the commit skill and the exact subject solve leetcode #<id>.

Workflow 2: add a company problem

Use this workflow for company-specific preparation, whether the workspace already exists or must be created first.

1. Inspect the working tree. If the workspace exists, read its company.json and generated README; otherwise create it with add-company using only confirmed metadata. Confirm the problem is not already registered.

2. Collect the ID, exact title, URL, platform difficulty, optional 1–10 personal difficulty, time complexity, space complexity, and optional notes. Use null when the personal difficulty is unrated; never infer it. Notes must define complexity variables where needed, for example k = number of distinct characters.

3. For a source-backed problem, use source-sync, next, and add-from-source so canonical URL, source rank, and frequency come from the pinned CSV. For a manual or OA-specific problem, use add-problem. For planned problems use start; for in-progress problems continue with the existing file. Run tracker commands from the repository root and do not manually synchronize generated README files:

   node scripts/company-tracker.js source-sync <company-slug>
   node scripts/company-tracker.js next <company-slug>
   node scripts/company-tracker.js add-from-source <company-slug> <source-key> [--id problem-id]
   node scripts/company-tracker.js add-problem <company-slug> <id> "<title>" <Easy|Medium|Hard> [--url URL]
   node scripts/company-tracker.js start <company-slug> <id>
   node scripts/company-tracker.js solve <company-slug> <id> --time "O(...)" --space "O(...)" [--personal-difficulty 1-10] [--notes TEXT]

4. If the user already created companies/<company>/solutions/<id>.py, preserve it. Temporarily move it outside the solution path if necessary, run add-problem and start, then restore the original solution before solve. Never let the generated template replace user work.

5. Preserve source repository, commit, snapshot date, window, and path. Do not silently refresh the external source. Source-backed ordering follows sourceRank; manual and custom OA entries remain supported.

6. Confirm that the tracker updated company.json, the company dashboard, companies/README.md, and the company summary in README.md.

7. Review the implementation, metadata, generated files, and complete diff, then run the full validation suite.

8. When asked to commit, use the exact subject solve leetcode #<id> @ <company-slug>, preserving the folder slug's spelling and case.

When a requested company workspace does not exist, run node scripts/company-tracker.js add-company "Company Name" first. Add --focus, --slug, or --website only from known information.

Workflow 3: update documentation

1. Determine whether the target is manual or generated documentation.
2. For roadmap metadata or statistics, update data/roadmap.json, then run node scripts/roadmap-tracker.js; the shared roadmap automation owns SOLUTIONS.md and the generated README roadmap blocks. Update roadmap snapshotDate only when NeetCode totals were actually verified, and backfill solvedAt only from reliable repository history.
3. For company progress, update the manifest through tracker commands, then run node scripts/company-tracker.js. Company source snapshotDate is separate from roadmap snapshotDate. Preserve pinned provenance and never hand-edit generated company dashboards.
4. For prose-only changes, preserve links, headings, and marker comments. Match the file's voice: keep README.md and CONTRIBUTING.md friendly, informal, concise, and naturally first-person where the maintainer is speaking.
5. Check internal paths, anchors, code examples, progress counts, and whether documentation still matches actual behavior.
6. Run documentation checks and the relevant tests. Generate a concise imperative commit subject from the final diff.

Workflow 4: update CI or automation

1. Read .github/workflows/ci.yml, .github/dependabot.yml, and every script or check affected by the proposed change.
2. Make the smallest compatible change. Preserve least-privilege permissions, bounded timeouts, concurrency cancellation, supported Python versions, and reproducible action references.
3. Keep the public CLI behavior in the entry points and reusable behavior in scripts/lib/. Update scripts/automation.test.js when automation behavior changes rather than creating overlapping test suites without a clear reason.
4. Ensure local commands, documentation, and CI commands remain aligned. If a check is added to CI, document it in CONTRIBUTING.md when contributors are expected to run it locally.
5. Validate JavaScript syntax and tests locally. Review YAML structure, event triggers, permissions, matrix behavior, shell portability, and dependency-update configuration.
6. Inspect the final diff for accidental secret exposure or untrusted pull-request execution risks. Generate the commit subject from the final diff.

Workflow 5: review everything / prepare for commit

Treat review as a real quality check, not just a summary of the changes.

1. Inspect git status --short, unstaged changes, staged changes, and every untracked file intended for the commit.
2. Confirm scope: one coherent change, no caches or editor artifacts, no accidental deletions, and no unrelated user work.
3. Review solution correctness, edge cases, method signatures, complexity claims, personal difficulty metadata, status-consistent solvedAt values, both distinct snapshot-date concepts, company source provenance and ordering, links, generated files, and documentation counts.
4. Run all available checks. Report any command that cannot run; never describe an unavailable check as passed.
5. Check whitespace for tracked and untracked files. Before committing, stage only intended paths and run git diff --cached --check plus git diff --cached.
6. Use .agents/skill/commit/SKILL.md when the user asks to commit. After committing, show the resulting subject and remaining working-tree status.

Workflow 6: general maintenance, fixes, and refactors

For requests not covered above, first infer the repository subsystem and desired outcome from the request and existing code. Read adjacent files and tests, keep the diff minimal, preserve public behavior unless the request changes it, update all affected documentation, and add or adjust tests when behavior changes. Apply the same review gate as every other workflow. Derive a concise imperative commit subject from the actual diff rather than from an early plan.

Required pre-commit review

Run from the repository root:

for file in scripts/*.js scripts/lib/*.js; do node --check "$file"; done

node scripts/roadmap-tracker.js --check
node scripts/company-tracker.js --check
node --test scripts/automation.test.js

ruff check neetcode-all companies
python -m compileall -q neetcode-all companies

git diff --check

Also run focused tests for changed behavior and inspect untracked files because plain git diff --check does not include them. If Python is unavailable, say so clearly and rely on CI for that check; do not install tools or dependencies without permission.

Commit and Dependabot rules

• Do not commit unless the user explicitly asks.
• Never use git add .; stage only reviewed paths.
• NeetCode roadmap commit: solve leetcode #<id>.
• Company solution commit: solve leetcode #<id> @ <company-slug>.
• Documentation, CI, review fixes, and general maintenance: derive a short imperative subject from the final staged diff.
• Do not append a generated Merge pull request #... subject to a normal commit.
• The GitHub repository is configured as squash-only: merge commits and rebase merges are disabled, squash merging is enabled, merged branches are deleted, and a one-commit PR keeps its commit title. Preserve these repository settings.
• For a Dependabot PR requested as a squash merge, create exactly one squash commit containing the dependency update. Use the Dependabot commit/PR subject, not an additional local commit and not a merge commit. Follow the dedicated instructions in .agents/skill/commit/SKILL.md.