tsh-code-reviewing

name	tsh-code-reviewing
description	Perform code review. Quality analysis. Acceptance criteria verification. Best practices review.
user-invocable	false

Code review

This skill helps you verify that the implemented code follows all best practices and quality standards.

Code Review Process

Use the checklist below and track your progress:

Analysis progress:
- [ ] Step 1: Understand the task description
- [ ] Step 2: Understand the plan to implement task
- [ ] Step 3: Analyse the implemented solution and compare that to task description and implementation plan
- [ ] Step 4: Verify that solution has implemented all necessary tests
- [ ] Step 5: Run all unit tests
- [ ] Step 6: Run all integrations tests
- [ ] Step 7: Run all e2e tests
- [ ] Step 8: Verify that solution follows the best practices
- [ ] Step 9: Run static code analysis tools and formatting tools
- [ ] Step 10: Validate the solution is secure
- [ ] Step 11: Validate the solution is scalable

Step 1: Understand the task description

Look for *.research.md file to fully understand the business goal of the task. In case of task being connected to task management tool make sure to use that tool to access even more context.

In case of missing research file, follow the conversation to understand the goal.

Step 2: Understand the plan to implement task

Look for *.plan.md file to understand the planned solution implementation.

In case of missing it follow the conversation to understand the goal.

Step 3: Analyse the implemented solution and compare that to task description and implementation plan

Based on implementation plan and task description, compare it to actually implementation.

Focus not only on files that were actually changed or added, but also those that claim to be already implemented.

Step 4: Verify that solution has implemented all necessary tests

Make sure that all critical paths of the solutions are fully tested by combination of different tests - e2e, unit, integration.

Treat missing integration coverage as a substantive finding when correctness depends on a real database, transaction boundaries, SQL semantics, migrations, queues, or external services. In those cases, unit tests alone are not sufficient.

Step 5: Run all unit tests

Find unit tests and run them. Make sure they are passing.

Step 6: Run all integration tests

Find integration tests and run them. Make sure they are passing.

Step 7: Run all e2e tests

Find end-to-end tests and run them. Make sure they are passing.

Step 8: Verify that solution follows the best practices

Check the implemented solution. Make sure it follow the best development practices.

Take into account project standards and a practices like SOLID, SRP, DDD, DRY, KISS, Atomic Design.

Make sure that solution is not over engineered. Keep the cognitive complexity on a lower side.

Always check for these high-risk implementation anti-patterns and treat them as substantive findings unless the task context contains a clear and justified tradeoff:

• N+1 database access patterns, including queries executed inside loops, per-item lazy loading, or repeated external fetches caused by iterating over entities one by one.
• Pagination, filtering, sorting, or aggregation performed in memory after loading large datasets instead of pushing that work down to the database or upstream service.
• Missing integration tests for behavior that depends on a real database or external service boundary.

Step 9: Run static code analysis tools and formatting tools

Make sure to run linters, static code analysis tools and formatting tools.

Step 10: Validate the solution is secure

Focus on security. Check for potential OWASP TOP10 issues. Check for potential critical security issues that allows other users to take control over the system.

Step 11: Validate the solution is scalable

Analyse if the implemented solution is scalable. Focus on areas like being able to scale it horizontally, not having a stateful components, not having code with high computational complexity.

Connected Skills

• tsh-implementation-gap-analysing
• tsh-technical-context-discovering - for understanding project conventions and standards to review against
• tsh-sql-and-database-understanding - for validating SQL quality, index coverage, query performance, schema design, and ORM usage patterns
• tsh-engineering-prompts - for reviewing LLM prompt code: prompt structure, injection defenses, delimiter separation, output format, and anti-patterns