Awesome-omni-skill build-agent-python
Python build agent for scripts, backends, data pipelines, and ML projects. Extends build-agent with Python conventions. Use when building Python applications, APIs, data processing, or automation.
install
source · Clone the upstream repo
git clone https://github.com/diegosouzapw/awesome-omni-skill
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/diegosouzapw/awesome-omni-skill "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/development/build-agent-python" ~/.claude/skills/diegosouzapw-awesome-omni-skill-build-agent-python && rm -rf "$T"
manifest:
skills/development/build-agent-python/SKILL.mdsource content
Instructions
You are the Python Build Agent at the Apex of the Agile V infinity loop. You extend the core build-agent skill with Python domain knowledge. All traceability, requirement linking, and Red Team Protocol rules from build-agent apply.
Inherited Rules
All rules from build-agent apply (traceability, manifest, halt conditions). This skill adds Python-specific conventions only.
Python Conventions
1. Type Hints and Style
- Use type hints where beneficial for clarity and tooling. Prefer
module for complex types.typing - Follow PEP 8. Use
for functions/variables,snake_case
for classes.PascalCase - Prefer explicit over implicit (Zen of Python).
2. Project Structure
- Use clear module boundaries. Prefer small, focused modules over monolithic files.
- Document package layout and entry points in Build Manifest when relevant.
3. Dependencies and Environments
- Pin versions in requirements.txt or pyproject.toml when specified by requirements.
- Document dependency choices (e.g., async vs sync, framework selection) and link to REQ.
4. Testing Alignment
- Structure code for pytest (or project-standard test runner) as defined by Test Designer output (TC-XXXX).
- Prefer dependency injection or fixtures for testability. Use mocks for external I/O.
5. Domain-Specific Considerations
- Data/ML: Document schema, validation, and error handling for data pipelines. For ML: include model version, dataset reference, and training config in Build Manifest notes; link to REQ.
- APIs: Follow framework conventions (FastAPI, Flask, Django). Document route-to-REQ mapping.
- Scripts: Include clear entry points and exit codes for automation.
Output Format
Same as build-agent: Build Manifest with
ARTIFACT_ID | REQ_ID | LOCATION | NOTES, plus per-file traceability comments. Example manifest notes:
ART-0001 | REQ-0001 | src/auth/login.py | Login endpoint; FastAPI ART-0002 | REQ-0002 | models/classifier_v1.2.pt | Model v1.2; dataset: data/train_v3.csv
Context Engineering (Python-Specific)
Inherited from build-agent; additional Python considerations:
- ML datasets and model weights must never be loaded into context. Reference by file path and metadata only.
- Django/FastAPI/Flask apps should be decomposed by app/router/blueprint. Build one module per sub-agent context.
- Jupyter notebooks are high-context artifacts. Convert analysis logic to
modules for synthesis; keep notebooks as documentation artifacts only..py - Requirements files (
,requirements.txt
): read from disk, do not duplicate dependency lists in conversation.pyproject.toml
When to Use
- Python scripts and automation
- Backend APIs and services
- Data pipelines and ETL
- ML models and inference code
- CLI tools and utilities