Problem
praxis's reviewer roster is category-based (backend, frontend, doc, test, structure, general) but language-agnostic. Backend code in a specific language carries language-specific correctness and idiom concerns that a generic backend-reviewer is not specialized to catch -- for Python: async/await misuse, pydantic v2 model pitfalls, common anti-patterns, type-safety gaps, error-handling and resilience conventions.
The marketplace already ships a pythonica plugin whose skills encode exactly this knowledge (python-anti-patterns, async-python-patterns, pydantic, python-type-safety, python-error-handling, python-testing, and more). The knowledge exists; no reviewer agent is wired to apply it during a PR review. So a Python PR gets reviewed by general backend heuristics plus whatever skills happen to auto-load, rather than by a reviewer whose mandate and skill set are Python-specific.
Current Workaround
backend-reviewer covers Python by default with general backend heuristics; language-specific depth depends on which skills happen to auto-load in the agent's context during the review. There is no reviewer whose scope is deliberately Python idiom + correctness.
Proposed Solution / Alternatives
Add a python-reviewer agent to praxis that reviews Python changes against the pythonica skill set and reports on the shared review-severity model.
Sketch:
- Categorization: in review-pr, Python file changes route to python-reviewer. Suggested relationship to backend-reviewer -- run alongside it, not instead of it: python-reviewer owns language idiom + correctness (async, pydantic, typing, anti-patterns), backend-reviewer keeps module/architecture/security. Worth deciding explicitly so their scopes do not overlap or leave gaps.
- Cross-plugin dependency (the "leveraging pythonica?" open point): a praxis agent leaning on pythonica skills couples the two plugins. Options:
- (a) praxis agent references pythonica skills by name and documents pythonica as a soft dependency;
- (b) the reviewer is self-contained with its own condensed checklist, with pythonica remaining the deep-dive reference;
- (c) a marketplace-level convention for cross-plugin skill reuse.
Prefer (a) if the marketplace supports declaring inter-plugin dependencies; otherwise (b).
- Generalizes: this opens a "language-specialist reviewer" seam -- future TypeScript / Go / etc. reviewers follow the same shape, each backed by a language plugin's skills. Scope this issue to Python as the first instance; the seam is a note, not a deliverable here.
Related: grimoire#34 (testing strategy for the marketplace's executable code) touches how agents like this would be validated.
Problem
praxis's reviewer roster is category-based (backend, frontend, doc, test, structure, general) but language-agnostic. Backend code in a specific language carries language-specific correctness and idiom concerns that a generic backend-reviewer is not specialized to catch -- for Python: async/await misuse, pydantic v2 model pitfalls, common anti-patterns, type-safety gaps, error-handling and resilience conventions.
The marketplace already ships a pythonica plugin whose skills encode exactly this knowledge (python-anti-patterns, async-python-patterns, pydantic, python-type-safety, python-error-handling, python-testing, and more). The knowledge exists; no reviewer agent is wired to apply it during a PR review. So a Python PR gets reviewed by general backend heuristics plus whatever skills happen to auto-load, rather than by a reviewer whose mandate and skill set are Python-specific.
Current Workaround
backend-reviewer covers Python by default with general backend heuristics; language-specific depth depends on which skills happen to auto-load in the agent's context during the review. There is no reviewer whose scope is deliberately Python idiom + correctness.
Proposed Solution / Alternatives
Add a
python-revieweragent to praxis that reviews Python changes against the pythonica skill set and reports on the shared review-severity model.Sketch:
Prefer (a) if the marketplace supports declaring inter-plugin dependencies; otherwise (b).
Related: grimoire#34 (testing strategy for the marketplace's executable code) touches how agents like this would be validated.