Project Context Enforcer
This skill enforces project awareness, code structure, testing, and documentation standards for Python projects that use `PLANNING.md` and `TASK.md` conventions. It includes integration patterns for MCP servers like Crawl4AI RAG and Neon.
What This Skill Does
Ensures project context is read from `PLANNING.md` at conversation startMaintains task tracking via `TASK.md`Enforces code modularity (max 500 lines per file)Creates and updates Pytest unit tests for all featuresIntegrates with MCP servers for documentation and database operationsMaintains Python best practices (PEP8, type hints, docstrings)Updates documentation when features changeInstructions
1. Project Awareness & Context
**At the start of every conversation:**
Read `PLANNING.md` to understand architecture, goals, style, and constraintsCheck `TASK.md` before starting any new taskIf the task isn't listed in `TASK.md`, add it with a brief description and today's dateUse consistent naming conventions, file structure, and architecture patterns as described in `PLANNING.md`2. Code Structure & Modularity
**File size constraint:**
Never create a file longer than 500 lines of codeIf a file approaches this limit, refactor by splitting it into modules or helper files**Organization:**
Organize code into clearly separated modules, grouped by feature or responsibilityUse clear, consistent imports (prefer relative imports within packages)3. Testing & Reliability
**Test creation (mandatory):**
Always create Pytest unit tests for new features (functions, classes, routes, etc.)After updating any logic, check whether existing unit tests need updates and update themTests should live in a `/tests` folder mirroring the main app structure**Test coverage requirements:**
Include at least:
1 test for expected use1 edge case test1 failure case test**Test execution:**
When testing, always activate the virtual environment in `venv_linux`Run Python commands with `python3`4. MCP Server Usage
#### Crawl4AI RAG MCP Server
Use for external documentation retrieval:
**Check available sources first:** Use `get_available_sources` to see what's crawled**Get documentation:** Use for fetching docs (e.g., Pydantic AI documentation)**Code examples:** Use `search_code_examples` when looking for implementation patterns#### Neon MCP Server
Use for database project management:
**Create projects:** Use `create_project` to create new Neon database projects**Execute SQL:** Use `run_sql` to execute schema and data operations**Inspect schema:** Use `get_database_tables` and `describe_table_schema` for inspection**Always specify project ID:** Pass the project ID to all database operations**Example workflow:**
1. `create_project` - create new database project
2. `run_sql` with schema SQL - set up tables
3. `get_database_tables` - verify schema creation
4. Use returned connection string for application config
5. Task Completion
Mark completed tasks in `TASK.md` immediately after finishing themAdd new sub-tasks or TODOs discovered during development to `TASK.md` under a "Discovered During Work" section6. Style & Conventions
**Language and frameworks:**
Use Python as the primary languageFollow PEP8 standardsUse type hints throughoutFormat with `black`Use `pydantic` for data validationUse `FastAPI` for APIsUse `SQLAlchemy` or `SQLModel` for ORM if applicable**Docstring requirements:**
Write docstrings for every function using Google style:
```python
def example(param1: str) -> int:
"""
Brief summary.
Args:
param1 (str): Description of param1.
Returns:
int: Description of return value.
"""
```
7. Documentation & Explainability
Update `README.md` when new features are added, dependencies change, or setup steps are modifiedComment non-obvious code to ensure understandability for mid-level developersWhen writing complex logic, add inline `# Reason:` comments explaining the why, not just the what8. AI Behavior Rules
**Critical constraints:**
Never assume missing context. Ask questions if uncertain.Never hallucinate libraries or functions – only use known, verified Python packages.Always confirm file paths and module names exist before referencing them in code or tests.Never delete or overwrite existing code unless explicitly instructed or part of a task from `TASK.md`.Always refer to official sources before implementing features to ensure correct usage and best practices.**Intellectual approach:**
Maintain a constructive but rigorous approachDo not simply affirm statements or assume conclusions are correctAct as an intellectual sparring partner, not just an agreeable assistantPush toward greater clarity, accuracy, and intellectual honestyChallenge assumptions when appropriate, but not for the sake of arguingExamples
Example 1: Starting a New Task
```
User: "Add user authentication to the API"