
Sql Code Review
Review SQL in your repo for injection risk, permissions, and maintainability before you ship database-backed features.
Overview
SQL Code Review is an agent skill most often used in Ship (also Build) that performs cross-database SQL security, maintainability, and quality analysis with injection and access-control focus.
Install
npx skills add https://github.com/github/awesome-copilot --skill sql-code-reviewWhat is this skill?
- Universal review across MySQL, PostgreSQL, SQL Server, and Oracle
- SQL injection examples with parameterized-query fixes
- Access control checks: least privilege, roles, schema and routine security
- Data protection guidance on SELECT *, sensitive columns, and audit logging
- Anti-pattern and maintainability analysis alongside security
Adoption & trust: 11.1k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have SQL scattered across migrations and app code and need a consistent security and standards review without hiring a DBA for every PR.
Who is it for?
Indie builders maintaining multi-database or legacy SQL who want a repeatable review checklist before release.
Skip if: Pure query-plan tuning or index-only optimization workflows—use a dedicated SQL optimization skill or prompt instead.
When should I use this skill?
When you need comprehensive SQL code review for security, maintainability, and best practices across MySQL, PostgreSQL, SQL Server, or Oracle.
What do I get? / Deliverables
You get actionable findings on injection, permissions, data exposure, and anti-patterns mapped to secure examples you can apply in the same session.
- Prioritized review notes on security, access control, and maintainability
- Before/after SQL examples for injection-safe patterns
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Code review is the canonical ship-phase gate before production SQL goes live. Structured review of selected SQL or the whole project fits the review subphase rather than initial backend implementation.
Where it fits
Scan new migration files for dynamic SQL and overly broad GRANT statements before merging.
Run a pre-release review on all SQL touched in the release branch.
Audit production-hotfix SQL for injection regressions after a security alert.
How it compares
A review checker for SQL safety and standards, not a live database MCP or migration runner.
Common Questions / FAQ
Who is sql-code-review for?
Solo and indie developers shipping backend features with raw SQL, stored procedures, or mixed ORM SQL who want agent-guided review across common engines.
When should I use sql-code-review?
During Ship review before merge; during Build when drafting migrations or reporting queries; after incidents when auditing access patterns and dynamic SQL.
Is sql-code-review safe to install?
It guides review of code you already have in the workspace; check this page’s Security Audits panel and your org policy before enabling skills from third-party catalogs.
SKILL.md
READMESKILL.md - Sql Code Review
# SQL Code Review Perform a thorough SQL code review of ${selection} (or entire project if no selection) focusing on security, performance, maintainability, and database best practices. ## 🔒 Security Analysis ### SQL Injection Prevention ```sql -- ❌ CRITICAL: SQL Injection vulnerability query = "SELECT * FROM users WHERE id = " + userInput; query = f"DELETE FROM orders WHERE user_id = {user_id}"; -- ✅ SECURE: Parameterized queries -- PostgreSQL/MySQL PREPARE stmt FROM 'SELECT * FROM users WHERE id = ?'; EXECUTE stmt USING @user_id; -- SQL Server EXEC sp_executesql N'SELECT * FROM users WHERE id = @id', N'@id INT', @id = @user_id; ``` ### Access Control & Permissions - **Principle of Least Privilege**: Grant minimum required permissions - **Role-Based Access**: Use database roles instead of direct user permissions - **Schema Security**: Proper schema ownership and access controls - **Function/Procedure Security**: Review DEFINER vs INVOKER rights ### Data Protection - **Sensitive Data Exposure**: Avoid SELECT * on tables with sensitive columns - **Audit Logging**: Ensure sensitive operations are logged - **Data Masking**: Use views or functions to mask sensitive data - **Encryption**: Verify encrypted storage for sensitive data ## ⚡ Performance Optimization ### Query Structure Analysis ```sql -- ❌ BAD: Inefficient query patterns SELECT DISTINCT u.* FROM users u, orders o, products p WHERE u.id = o.user_id AND o.product_id = p.id AND YEAR(o.order_date) = 2024; -- ✅ GOOD: Optimized structure SELECT u.id, u.name, u.email FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.order_date >= '2024-01-01' AND o.order_date < '2025-01-01'; ``` ### Index Strategy Review - **Missing Indexes**: Identify columns that need indexing - **Over-Indexing**: Find unused or redundant indexes - **Composite Indexes**: Multi-column indexes for complex queries - **Index Maintenance**: Check for fragmented or outdated indexes ### Join Optimization - **Join Types**: Verify appropriate join types (INNER vs LEFT vs EXISTS) - **Join Order**: Optimize for smaller result sets first - **Cartesian Products**: Identify and fix missing join conditions - **Subquery vs JOIN**: Choose the most efficient approach ### Aggregate and Window Functions ```sql -- ❌ BAD: Inefficient aggregation SELECT user_id, (SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) as order_count FROM orders o1 GROUP BY user_id; -- ✅ GOOD: Efficient aggregation SELECT user_id, COUNT(*) as order_count FROM orders GROUP BY user_id; ``` ## 🛠️ Code Quality & Maintainability ### SQL Style & Formatting ```sql -- ❌ BAD: Poor formatting and style select u.id,u.name,o.total from users u left join orders o on u.id=o.user_id where u.status='active' and o.order_date>='2024-01-01'; -- ✅ GOOD: Clean, readable formatting SELECT u.id, u.name, o.total FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.status = 'active' AND o.order_date >= '2024-01-01'; ``` ### Naming Conventions - **Consistent Naming**: Tables, columns, constraints follow consistent patterns - **Descriptive Names**: Clear, meaningful names for database objects - **Reserved Words**: Avoid using database reserved words as identifiers - **Case Sensitivity**: Consistent case usage across schema ### Schema Design Review - **Normalization**: Appropriate normalization level (avoid over/under-normalization) - **Data Types**: Optimal data type choices for storage and performance - **Constraints**: Proper use of PRIMARY KEY, FOREIGN KEY, CHECK, NOT NULL - **Default Values**: Appropriate defau