Add test coverage checklist, report template, and stack matrix for ecommerce project
- Created a test coverage checklist to ensure comprehensive testing of backend and frontend components. - Added a test report template to standardize reporting on test execution results and gaps. - Introduced a test stack matrix to guide the selection of testing tools and frameworks for backend and frontend. - Established a skill for repairing failing tests, including a failure triage checklist and a test repair template. - Documented recommended MCP stack for ecommerce development with FastAPI and React/Next.js. - Developed a detailed README outlining the project structure, agent capabilities, and recommended workflows. - Compiled a comprehensive workflow guide detailing step-by-step commands for project setup, testing, and SEO implementation.
This commit is contained in:
ВяткинАртём
@@ -0,0 +1,61 @@
|
||||
---
|
||||
name: ecommerce-code-review
|
||||
description: 'Perform a strict full-project code review for an ecommerce codebase. Use for harsh review of Python, React, architecture, performance, dependency hygiene, modern language features, and configuration-aware quality rules based on pyproject, package.json, and installed versions.'
|
||||
argument-hint: 'Describe whether to review the whole project or focus on backend, frontend, performance, architecture, or dependency quality'
|
||||
---
|
||||
# Ecommerce Code Review
|
||||
|
||||
## When to use
|
||||
- Reviewing a whole ecommerce project before release.
|
||||
- Auditing an existing codebase for quality, maintainability, performance, dependency issues, and outdated patterns.
|
||||
- Enforcing strong standards for Python backend and React frontend code.
|
||||
|
||||
## Goal
|
||||
- Produce a harsh, technically defensible review.
|
||||
- Prefer findings over praise.
|
||||
- Create or update .ai/CODE-REVIEW.md with prioritized findings, risks, and remediation steps.
|
||||
|
||||
## Review stance
|
||||
- Be strict.
|
||||
- Prefer root-cause findings over stylistic nitpicks.
|
||||
- Check current project configuration before judging the code.
|
||||
- Use current framework and language capabilities when the installed version supports them.
|
||||
- If version-specific guidance matters, verify it against official documentation or authoritative up-to-date sources.
|
||||
|
||||
## Required workflow
|
||||
1. Read `pyproject.toml`, `package.json`, `tsconfig.json`, lint configs, and other relevant project configs when they exist.
|
||||
2. Detect the configured Python quality toolchain using [python quality matrix](./assets/python-quality-matrix.md).
|
||||
3. Detect the React, Next.js, and TypeScript setup using [react review matrix](./assets/react-review-matrix.md).
|
||||
4. Review the codebase against [project review checklist](./assets/project-review-checklist.md).
|
||||
5. Classify issues with [severity rubric](./assets/severity-rubric.md).
|
||||
6. Write or update .ai/CODE-REVIEW.md using [code review template](./assets/code-review-template.md).
|
||||
7. Keep the final report findings-first, with concrete fixes and explicit assumptions.
|
||||
|
||||
## Python review expectations
|
||||
- Respect the configured checker in `pyproject.toml`.
|
||||
- If `mypy` is configured, review against `mypy --strict` expectations unless the project explicitly relaxes rules.
|
||||
- If `ty` is configured, review against `ty` expectations and the project's chosen strictness.
|
||||
- If `ruff` is configured, review import hygiene, complexity, unsafe patterns, and style issues that matter for maintainability.
|
||||
- If `deptry` is configured, review dependency hygiene, unused packages, misplaced dev dependencies, and import consistency.
|
||||
- If the project is missing these checks and the user is building new code, recommend adding a coherent baseline.
|
||||
- Prefer modern Python features only when supported by the configured Python version.
|
||||
|
||||
## React review expectations
|
||||
- Code should be readable, explicit, and easy for a human developer to modify.
|
||||
- Prefer clear component boundaries, descriptive prop names, predictable state flow, and minimal incidental abstraction.
|
||||
- Avoid clever patterns that obscure behavior.
|
||||
- Review hooks usage, render stability, accessibility, data fetching boundaries, loading and error states, and app-structure clarity.
|
||||
- When the installed React or Next.js version supports newer language or framework features, check whether their use would simplify or strengthen the code.
|
||||
- Do not force trendy APIs if they reduce clarity or conflict with the current architecture.
|
||||
|
||||
## Outputs
|
||||
- .ai/CODE-REVIEW.md.
|
||||
- Findings ordered by severity.
|
||||
- Explicit follow-up plan.
|
||||
|
||||
## References
|
||||
- [project review checklist](./assets/project-review-checklist.md)
|
||||
- [severity rubric](./assets/severity-rubric.md)
|
||||
- [python quality matrix](./assets/python-quality-matrix.md)
|
||||
- [react review matrix](./assets/react-review-matrix.md)
|
||||
- [code review template](./assets/code-review-template.md)
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
# CODE-REVIEW.md Template
|
||||
|
||||
## 1. Review Scope
|
||||
- Reviewed repository or area
|
||||
- Config files inspected
|
||||
- Runtime and toolchain assumptions
|
||||
|
||||
## 2. Executive Summary
|
||||
- Overall quality assessment
|
||||
- Highest-risk areas
|
||||
- Biggest maintainability concerns
|
||||
|
||||
## 3. Findings
|
||||
|
||||
### Critical
|
||||
- Findings
|
||||
|
||||
### High
|
||||
- Findings
|
||||
|
||||
### Medium
|
||||
- Findings
|
||||
|
||||
### Low
|
||||
- Findings
|
||||
|
||||
## 4. Python Quality Notes
|
||||
- Type system and strictness
|
||||
- Tooling alignment
|
||||
- Dependency hygiene
|
||||
- Modern Python usage
|
||||
|
||||
## 5. React and Frontend Notes
|
||||
- Readability and maintainability
|
||||
- State and effects
|
||||
- Performance-sensitive areas
|
||||
- Modern framework usage
|
||||
|
||||
## 6. Configuration and Tooling Notes
|
||||
- pyproject quality rules
|
||||
- frontend config quality
|
||||
- gaps and inconsistencies
|
||||
|
||||
## 7. Testing and Risk Gaps
|
||||
- Missing tests
|
||||
- weak assertions
|
||||
- release risks
|
||||
|
||||
## 8. Recommended Fix Order
|
||||
- Immediate blockers
|
||||
- short-term fixes
|
||||
- structural cleanup
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
# Project Review Checklist
|
||||
|
||||
## Architecture and maintainability
|
||||
- Module boundaries are clear.
|
||||
- Cross-layer dependencies are controlled.
|
||||
- The code does not hide business logic in the wrong layer.
|
||||
- Naming is precise and stable.
|
||||
- Public interfaces are coherent.
|
||||
|
||||
## Python backend
|
||||
- Type coverage and strictness align with project configuration.
|
||||
- Async and I/O boundaries are explicit and safe.
|
||||
- Data validation and domain modeling are coherent.
|
||||
- Error handling is consistent.
|
||||
- Dependency usage is justified and clean.
|
||||
- Imports, complexity, and dead code align with configured linters.
|
||||
- Modern Python features are used when they improve the code and match the configured interpreter version.
|
||||
|
||||
## React or Next.js frontend
|
||||
- Components are readable and easy to modify.
|
||||
- State ownership is clear.
|
||||
- Derived state and side effects are not overcomplicated.
|
||||
- Data fetching and caching strategy are coherent.
|
||||
- Accessibility, loading states, empty states, and error states are covered.
|
||||
- Expensive renders, unstable props, and unnecessary abstractions are avoided.
|
||||
- Newer framework features are used where they meaningfully improve code quality and are supported by the installed version.
|
||||
|
||||
## Performance and optimization
|
||||
- Hot paths are identified.
|
||||
- No obvious over-fetching or over-rendering.
|
||||
- Expensive work is not repeated without reason.
|
||||
- Assets and bundles are handled sensibly.
|
||||
|
||||
## Dependency and configuration hygiene
|
||||
- Dependencies match actual imports and usage.
|
||||
- Dev and runtime dependencies are separated properly.
|
||||
- Tooling configuration is coherent.
|
||||
- The code follows the quality rules implied by the configuration files.
|
||||
|
||||
## Security and reliability
|
||||
- Sensitive flows are validated.
|
||||
- Auth and permission checks are consistent.
|
||||
- Dangerous defaults are avoided.
|
||||
- Error handling does not leak implementation details.
|
||||
|
||||
## Testing and verification
|
||||
- Tests cover high-risk business flows.
|
||||
- Assertions are meaningful.
|
||||
- Cleanup and fixture behavior are reliable.
|
||||
- Gaps in test coverage are identified honestly.
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
# Python Quality Matrix
|
||||
|
||||
## Configuration detection
|
||||
- Read `pyproject.toml` first.
|
||||
- Detect the configured Python version.
|
||||
- Detect `mypy`, `ty`, `ruff`, `deptry`, `pytest`, and formatter configuration.
|
||||
|
||||
## Review rules
|
||||
- If `mypy` is configured, check the actual options before judging missing annotations or strictness violations.
|
||||
- If `ty` is configured, use its configured expectations and error model.
|
||||
- If both exist, respect whichever toolchain the project clearly treats as authoritative, and flag inconsistent duplication.
|
||||
- If `ruff` is configured, review for meaningful rule violations, not cosmetic churn.
|
||||
- If `deptry` is configured, verify dependency placement, unused dependencies, and hidden transitive reliance.
|
||||
|
||||
## Modern Python usage
|
||||
- Use modern typing syntax only when the configured Python version supports it.
|
||||
- Prefer `typing.Self`, `typing.TypeAliasType`, `typing.override`, `collections.abc` imports, `match`, `enum.StrEnum`, dataclass slots, and other newer features only when they improve clarity and compatibility.
|
||||
- Do not suggest a newer language feature that the configured interpreter cannot run.
|
||||
|
||||
## Common harsh checks
|
||||
- Weak or missing type boundaries.
|
||||
- Hidden `Any` spread.
|
||||
- Async misuse.
|
||||
- Leaky ORM or transport models.
|
||||
- Overly dynamic code that defeats static analysis.
|
||||
- Wrong dependency classification.
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# React Review Matrix
|
||||
|
||||
## Configuration detection
|
||||
- Read `package.json`, `tsconfig.json`, ESLint config, framework config, and build setup.
|
||||
- Detect React version, Next.js version, TypeScript version, and testing setup.
|
||||
|
||||
## Readability rules
|
||||
- Components should be easy to scan.
|
||||
- Props should be explicit and well named.
|
||||
- Business logic should not be buried in JSX noise.
|
||||
- Avoid deeply nested conditional rendering when a clearer structure would help.
|
||||
- Prefer predictable state flow over clever abstractions.
|
||||
|
||||
## Modern React usage
|
||||
- Use modern React and framework features only when the installed version supports them and they improve maintainability.
|
||||
- Check whether newer APIs such as `useEffectEvent`, transitions, server components, or framework-native data loading would simplify the code.
|
||||
- Do not insist on `useMemo` or `useCallback` unless they are justified.
|
||||
- Avoid stale patterns if the installed version provides a clearer and safer replacement.
|
||||
|
||||
## Harsh review checks
|
||||
- Unclear ownership of state.
|
||||
- Effect misuse.
|
||||
- Derived state bugs.
|
||||
- Excessive prop drilling when a better structure exists.
|
||||
- Over-componentization that hurts readability.
|
||||
- Poor separation between UI, data, and business rules.
|
||||
- Missing loading, empty, and error states.
|
||||
- Avoidable render churn and unstable object creation in hot paths.
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
# Severity Rubric
|
||||
|
||||
## Critical
|
||||
- Likely to cause broken behavior, data loss, security issues, or severe production instability.
|
||||
- Major architecture flaw affecting core flows.
|
||||
|
||||
## High
|
||||
- Strong risk of bugs, regressions, maintainability collapse, or significant performance issues.
|
||||
- Serious mismatch with configured quality rules.
|
||||
|
||||
## Medium
|
||||
- Clear quality issue or missed optimization that should be fixed, but not an immediate release blocker.
|
||||
|
||||
## Low
|
||||
- Smaller maintainability issues, cleanup, or polish items.
|
||||
|
||||
## Finding format
|
||||
- Severity
|
||||
- Area
|
||||
- Location
|
||||
- Problem
|
||||
- Why it matters
|
||||
- Recommended fix
|
||||
- Confidence or assumptions when relevant
|
||||
Reference in New Issue
Block a user