If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/charlax/professional-programming shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 5d ago
• 11 active contributors
• MIT licensed
• Tests present
• ⚠ Single-maintainer risk — top contributor 88% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live charlax/professional-programming repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/charlax/professional-programming.

What it runs against: a local clone of charlax/professional-programming — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in charlax/professional-programming | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 35 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of charlax/professional-programming. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/charlax/professional-programming.git
#   cd professional-programming
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of charlax/professional-programming and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "charlax/professional-programming(\\.git)?\\b" \\
  && ok "origin remote is charlax/professional-programming" \\
  || miss "origin remote is not charlax/professional-programming (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "antipatterns/README.md" \\
  && ok "antipatterns/README.md" \\
  || miss "missing critical file: antipatterns/README.md"
test -f "glossary.md" \\
  && ok "glossary.md" \\
  || miss "missing critical file: glossary.md"
test -f "training/front-end/README.md" \\
  && ok "training/front-end/README.md" \\
  || miss "missing critical file: training/front-end/README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 35 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~5d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/charlax/professional-programming"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A curated, community-driven knowledge base of learning resources and best practices for software engineers, organized by topic (antipatterns, design, databases, career growth, etc.). It aggregates links, cheatsheets, code examples, and training materials—primarily markdown documents with Python and HTML components—to help developers level up across full-stack disciplines without needing to hunt across the web. Flat, topic-driven hierarchy: antipatterns/ contains markdown guides + Python/SQLAlchemy code examples; training/ organizes learning paths by discipline (front-end with JavaScript/React/TypeScript modules); cheatsheets/ holds PDFs; list-of-links/ curates external resources; root markdown files cover glossary, feature-flags, and specific patterns. No monorepo or package structure—this is a reference doc repository.

Mid-level to senior software engineers who want to deepen their understanding of professional software development practices, code quality, system design, and career progression. Also useful for engineering teams onboarding juniors who need a structured curriculum covering everything from clean code to distributed systems.

This is a mature, actively maintained reference project (not a framework or library). It shows signs of continuous curation with a well-organized directory structure, .pre-commit-config.yaml for quality gates, and clear CONTRIBUTING.md guidelines. The README uses doctoc for auto-generated TOCs, indicating attention to maintainability. Verdict: actively maintained reference material with stable structure.

Minimal risk as this is a documentation/knowledge repository, not production software with runtime dependencies. No package.json or requirements.txt observed, so no dependency security concerns. Risk is reputational: quality of linked resources depends on curator diligence and community contributions. Single-maintainer repos (charlax) can experience stale links or outdated advice if not regularly reviewed, but the breadth of topics and CONTRIBUTING.md suggest community involvement.

Active curation of AI/LLM learning resources (visible in list-of-links/List of AI and LLM learning resources 20260104144118.md with recent timestamp). Ongoing maintenance of antipatterns documentation with Python and SQLAlchemy-specific examples. Training material actively organized by technology (modern JavaScript, React, TypeScript, CSS/HTML). No specific PR/issue data visible, but the file modification dates and structured CONTRIBUTING guidelines suggest regular updates.

Clone and browse locally: git clone https://github.com/charlax/professional-programming.git && cd professional-programming. No build or install step required—this is pure markdown/documentation. Read README.md for the curated table of contents, then navigate by topic: antipatterns/, training/, or list-of-links/. No dependencies, no runtime.

Daily commands: This is not a runnable application. To view locally: cat README.md or open in a markdown viewer. To preview in browser: use any markdown-to-HTML renderer (e.g., grip README.md if grip is installed, or paste into GitHub). Python examples can be executed individually: python antipatterns/python-examples/reraise_exceptions_good.py (if they're runnable scripts). No dev server or runtime environment.

• README.md — Entry point documenting the entire learning resource collection, principles, and curated topic structure that defines the repo's scope and educational mission.
• CONTRIBUTING.md — Establishes contribution guidelines and standards that all curators and contributors must follow to maintain consistency across the learning resource list.
• antipatterns/README.md — Index and overview of the antipatterns module, which is a core teaching component covering code, database, error-handling, and architectural pitfalls.
• glossary.md — Centralized terminology reference that ensures consistent understanding of key software engineering concepts across all resources in the repo.
• training/front-end/README.md — Structured learning path for front-end development that demonstrates the repo's modular training approach and establishes conventions for other training modules.
• feature-flags.md — Advanced topic document exemplifying how to contribute feature-specific content and best practices within the professional programming knowledge base.

• README.md (Markdown, GitHub Markdown rendering) — Single source of truth for repo purpose, principles, and organized topic index; acts as navigation hub
  • Failure mode: If outdated or poorly structured, learners cannot find topics; discoverability breaks
• Antipatterns module (Markdown, Python code examples) — Educates on code, database, error-handling, testing, and scalability pitfalls with real examples
  • Failure mode: If examples are incorrect or outdated, learners internalize wrong patterns; reverse education effect
• Training modules (front-end, backend, web-dev, etc.) — Provides structured, progressive learning paths with clear prerequisites and dependencies

Add a new antipattern category

1. Create a new markdown file in antipatterns/ directory (e.g., antipatterns/new-topic-antipatterns.md) following the naming convention (antipatterns/README.md)
2. Document 3–5 antipatterns with clear description, consequences, and solutions in markdown format (antipatterns/code-antipatterns.md)
3. If antipattern includes code examples, add Python or language-specific examples in antipatterns/python-examples/ directory (antipatterns/python-examples/reraise_exceptions_good.py)
4. Update antipatterns/README.md to link to the new antipattern category (antipatterns/README.md)

Add a new training module

1. Create a new directory under training/ (e.g., training/backend) with a README.md that outlines the learning path (training/front-end/README.md)
2. Create numbered markdown files (01-topic.md, 02-topic.md, etc.) for each lesson module (training/front-end/01-modern-javascript.md)
3. Add supporting examples in a training/backend/examples/ subdirectory if code samples are needed (training/front-end/examples/hoisting.html)
4. Link new training module from the main README.md under the Topics section (README.md)

Add a new feature or topic guide

1. Create a new markdown file at the root level (e.g., performance-optimization.md) with a descriptive title and intro (feature-flags.md)
2. Structure content with clear sections: Overview, Patterns, Best Practices, and Common Pitfalls (feature-flags.md)
3. Include relevant images in the images/ directory if diagrams or visual aids enhance understanding (images/premature-optimization-flowchart.png)
4. Reference the topic in the main README.md Topics section for discoverability (README.md)

Add new glossary entries

1. Open glossary.md and add new terms in alphabetical order with clear, concise definitions (glossary.md)
2. Include related terms and cross-references where applicable to create a knowledge graph (glossary.md)

• Markdown (.md files) — Simple, version-controllable, platform-agnostic format for long-form educational content that integrates natively with GitHub
• Git + GitHub — Enables collaborative curation, community contributions, version history, and low-friction forking for personalized learning paths
• Python code examples — Demonstrates antipatterns and best practices in a widely-understood language for both backend and scripting contexts
• PDF reference materials (cheatsheets) — Provides printable, offline-accessible distillations of complex concepts (Clean Code, Clean Architecture) for quick reference

• No interactive platform or executable code environment

  • Why: Keeps the repo lightweight and maintainable by volunteers; GitHub Markdown is the interface
  • Consequence: Learners cannot run code directly in the repo; examples are read-only references they must copy locally

• Curated, opinionated list rather than exhaustive catalog

  • Why: Focuses quality and prevents information overload; respects contributor time and reader cognitive load
  • Consequence: Some valid resources/techniques may be omitted; requires community consensus for inclusion

• Minimal dependencies and no build system

  • Why: Maximizes accessibility and reduces barrier to forking, reading, and contributing
  • Consequence: No automated testing, linting, or deployment pipeline; quality relies on human review

• Topic-based organization rather than role-based (e.g., no separate 'for QA' or 'for DevOps' sections)

  • Why: Reflects the repo's philosophy that good software engineering principles apply universally
  • Consequence: Learners must navigate across topics to build role-specific competency; no pre-packaged learning paths by job title

• Not an interactive learning platform with exercises, quizzes, or progress tracking
• Not a project template or boilerplate generator; focuses on concepts, not starter code
• Not a live service or runnable system; purely a static collection of markdown and reference materials
• Not a replacement for hands-on coding practice; emphasis is on theory and pattern recognition
• Not exhaustive; explicitly curated to avoid overwhelming learners with every possible resource

No environment variables or external services required. However, pre-commit hooks require Python tooling installed locally (see .pre-commit-config.yaml)—if you want to contribute code examples or markdown, you'll need pre-commit and whatever linters/formatters it specifies. The doctoc tool must be installed (npm) to regenerate table of contents. PDF cheatsheets (Clean-Architecture-V1.0.pdf, Clean-Code-V2.4.pdf) are vendored but may go stale relative to original publications—treat as reference only.

• N+1 Query Problem — Demonstrated in antipatterns/sqlalchemy-examples/; a critical performance antipattern that juniors must recognize early to avoid database bottlenecks
• Test Pyramid — Referenced in antipatterns/images/test-pyramid.png; foundational concept for understanding cost-effective test coverage across unit, integration, and E2E
• Anti-patterns in Error Handling — Specific to Python (reraise_exceptions_good.py); understanding exception re-raising and stack trace preservation prevents masking of root causes in production
• Clean Architecture (Cone diagram) — Visualized in cheatsheets/Clean-Architecture-V1.0.pdf and images/clean-architecture-cone.jpg; core organizing principle for separating concerns across layers (entities, use cases, interface adapters, frameworks)
• Feature Flags (toggles) — Dedicated feature-flags.md document; essential practice for safe deployment, A/B testing, and gradual rollouts in production systems
• Technical Debt — Visualized in images/tech-debt.jpeg; concept from antipatterns and design sections; critical for communicating short-term trade-offs and long-term costs to non-technical stakeholders
• Premature Optimization — Referenced in images/premature-optimization-flowchart.png; foundational mindset for junior engineers to avoid wasting effort on micro-optimizations before measuring bottlenecks

• donnemartin/system-design-primer — Companion resource covering system design and architecture at scale; complements this repo's design patterns and scalability antipatterns
• google/styleguide — Official language-specific style guides (Python, JavaScript, C++, etc.) that align with the code-quality and best-practices sections
• 97-things/97-things-every-programmer-should-know — Similar curated wisdom collection on software engineering fundamentals; shares the same 'axioms and principles' philosophy
• kamranahmedse/developer-roadmap — Structured learning paths by role (frontend, backend, DevOps); complements this repo's training materials with visual roadmaps
• tycrek/awesome-yt-creators — Example of another awesome-style curated list; shares methodology of organizing learning resources for engineers

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create a comprehensive antipatterns index and cross-reference guide

The antipatterns/ directory has multiple well-organized markdown files (code, database, error-handling, mvcs, sqlalchemy, scalability, tests) but lacks a unified index or navigation system. New contributors often don't know which antipattern file to read first or how they relate. Adding a structured index with cross-references and categorization would significantly improve discoverability and learning outcomes.

• [ ] Create antipatterns/INDEX.md with categorized listings of all antipatterns across the subdirectories
• [ ] Add cross-references between related antipatterns (e.g., link tests-antipatterns.md to code-antipatterns.md where applicable)
• [ ] Update antipatterns/README.md to prominently feature the new index and reading order recommendations
• [ ] Add navigation links at the top/bottom of each antipattern file pointing to related topics

Expand training/learning-python/README.md with structured curriculum and examples

The training/ directory contains well-developed front-end and web-dev guides with multiple chapters and examples, but training/learning-python/README.md appears minimal compared to its peers. This is a high-impact gap since Python is fundamental to many software engineers. Structuring this guide similarly to front-end training (with numbered modules, example files, and image assets) would significantly improve the repo's value.

• [ ] Review structure of training/front-end/ and training/web-dev/ to establish consistent format
• [ ] Create numbered markdown files (01-fundamentals.md, 02-oop.md, 03-testing.md, etc.) following the existing pattern
• [ ] Create training/learning-python/examples/ directory with runnable Python examples (similar to training/front-end/examples/)
• [ ] Create training/learning-python/img/ directory and add relevant diagrams/flowcharts
• [ ] Update training/learning-python/README.md with a structured table of contents and learning roadmap

Add validation rules and lint checks to pre-commit configuration

The repo has .pre-commit-config.yaml but it likely only includes basic hooks. Given the repo's focus on professional programming standards and the presence of code examples (Python, JavaScript, SQLAlchemy), adding language-specific linters and validators would enforce quality and serve as a practical example for contributors. This also ensures code examples remain maintainable.

• [ ] Audit .pre-commit-config.yaml for completeness and add Python linters (pylint, flake8, or ruff) for training/learning-python/ and antipatterns/python-examples/
• [ ] Add JavaScript/TypeScript linters (eslint) for training/front-end/examples/ and training/web-dev/
• [ ] Add markdown linting (markdownlint-cli2) to ensure consistent formatting across README.md and documentation files
• [ ] Update CONTRIBUTING.md with instructions for running pre-commit locally before submitting PRs
• [ ] Test the updated configuration on existing code examples to ensure they pass

• Add Python code examples for the database-antipatterns.md section (currently has markdown but no runnable examples like antipatterns/python-examples/). Create good/bad SQLAlchemy snippets demonstrating N+1 queries and lazy loading pitfalls.
• Expand the testing-antipatterns.md with a 'Common assertions to avoid' code example file, mirroring the structure of reraise_exceptions_good.py to show anti-patterns in pytest or unittest.
• Review and update links in list-of-links/ and topic markdown files for 404 or outdated resources; create a audit checklist and document the link validation process in CONTRIBUTING.md for future maintainers.

This repository is a documentation and learning resource collection with minimal security risks. No critical or high-severity vulnerabilities were identified. The codebase contains primarily markdown documentation, images, and educational code examples rather than production code. Main recommendations: (1) Verify integrity of included PDF files, (2) Add a SECURITY.md vulnerability disclosure policy, (3) Ensure educational antipattern examples are clearly marked as such, (4) Add SPDX license identifiers for better license compliance tracking. The security posture is strong for a learning resource repository with no apparent hardcoded secrets, injection vulnerabilities, or infrastructure misconfigurations.

• Low · No dependency management file detected — Root directory. The repository does not contain a package.json, requirements.txt, Gemfile, or other dependency management files in the provided context. While this is a documentation/learning resource repository, if any code examples are meant to be executed, dependency tracking should be explicit. Fix: If code examples are provided, ensure they include proper dependency management files with pinned versions. Document any external dependencies clearly.
• Low · PDF documents included without integrity verification — cheatsheets/Clean-Architecture-V1.0.pdf, cheatsheets/Clean-Code-V2.4.pdf. The repository includes PDF files (Clean-Architecture-V1.0.pdf, Clean-Code-V2.4.pdf) in the cheatsheets directory. PDFs can potentially contain malicious content or be modified. Fix: Verify the integrity of these PDF files using checksums or digital signatures. Consider linking to official sources instead of distributing copies. Document the source and date of acquisition.
• Low · No security policy or vulnerability disclosure mechanism — Root directory. The repository does not appear to have a SECURITY.md or vulnerability disclosure policy based on the file listing. Fix: Create a SECURITY.md file documenting how security issues should be reported responsibly, especially important for educational repositories that may be widely used.
• Low · Python example files may require security review — antipatterns/python-examples/, antipatterns/sqlalchemy-examples/. The repository contains Python example files demonstrating exception handling (reraise_exceptions_bad.py, reraise_exceptions_good.py) and SQLAlchemy patterns. While these are educational antipatterns, ensure they don't inadvertently demonstrate exploitable patterns. Fix: Review example code to ensure bad patterns are clearly marked and not executable in production contexts. Add warnings where appropriate. Ensure the code doesn't demonstrate SQL injection vulnerabilities.
• Low · Missing SPDX license identifier in common locations — Root directory and source files. While a LICENSE file exists, there's no evidence of SPDX headers in code files or standardized license metadata for easier license scanning. Fix: Add SPDX-License-Identifier headers to source files. Document the license prominently in README.md using standard identifiers.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.