LICENSE.txt
MIT License
Copyright (c) 2026 mrsknetwork
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
SKILL.md
---
name: review
description: >-
Performs the final Gate 3 audit — the production-readiness pass. Audits the
complete feature for security baselines, dependency hygiene, observability,
configuration safety, and performance baselines. Use this skill right before
concluding a major task, when the user says "ship", "deploy", "release",
"merge", "production ready", or when verifying that a feature branch is safe
to merge into main.
license: MIT
metadata:
evals: ./evals/evals.json
author: mrsknetwork
version: "1.0"
---
# Audit and Review Skill
## Purpose
The reviewer conducts a Gate 3 audit on an entire feature branch or completed task. Unlike the `validate` skill, which cares about functional requirements and basic unit/lint validation, this skill answers the critical engineering question: **"Is this feature truly safe to deploy to production?"**
## Gate 3: Production Readiness Audit
### 1. The Configuration Check
- Have new environment variables been introduced?
- Are they documented in a `.env.example` or equivalent config schema?
- Are environment configurations checked at service startup (fail-fast principle)?
### 2. The Dependency Lock Check
- Has the feature introduced new libraries?
- If so, did it write them permanently to the respective dependency lockfile (e.g. `requirements.txt`, `package.json`, `go.mod`)?
- Are they broadly accepted and actively maintained libraries, or arbitrary/fringe packages?
### 3. The Observability Check
- Do critical pathways (like authentication, payment failures, integrations) emit structured logs?
- Are error handlers catching raw Exceptions, or are they wrapping errors with domain-specific context before surfacing them to the user?
### 4. The Data and Security Audit
- Has the application inadvertently surfaced PII (Personally Identifiable Information) in logging outputs?
- If interacting with a database, are ORMs parameterized to prevent injection?
- If writing APIs, are CORS and Rate Limiting constraints present (if applicable)?
- **Secret Scanning:** Ensure no hardcoded tokens (JWT secrets, API keys, Connection strings) leaked into code. All secrets MUST be in `.env`.
### 5. The Performance Baseline
- Are there obvious N+1 query patterns? (e.g., fetching related records in a loop instead of a single JOIN or eager load)
- Are database queries using indexes for frequently-filtered columns?
- Are large lists paginated? Unbounded `SELECT *` queries are a production incident waiting to happen.
- Are expensive operations (API calls, file processing) running in background jobs rather than blocking the request cycle?
### 6. The Dependency Audit
- Are all new dependencies actively maintained? Check the last commit date and issue activity.
- Are there duplicate libraries solving the same problem? (e.g., both `axios` and `node-fetch`, both `moment` and `dayjs`)
- Are dependency versions pinned or using appropriate range specifiers?
- Do any new dependencies have known CVEs? Run `npm audit` / `pip-audit` / `govulncheck` if available.
## SOP: Review Workflow
### Step 1 - Holistic Project Scan
Scan the git diff of the current working changes, or review the comprehensive set of files generated during the latest sequence of tasks. Do not merely execute linters; read the architectural flow.
### Step 2 - Formulating the Audit
List out the components checked against the Gate 3 criteria. Identify specific architectural smells that might hinder scale.
### Step 3 - Generating the Audit Report
Output a formal Markdown report assessing production readiness.
**Format:**
```markdown
## Gate 3 Production Audit: [Feature Name]
### Configuration & Dependencies
- [ ] PASS/WARN/FAIL: `.env.example` mapping.
- [ ] PASS/WARN/FAIL: Packages securely pinned.
- [ ] PASS/WARN/FAIL: No duplicate or abandoned dependencies.
### Security & Observability
- [ ] PASS/WARN/FAIL: No raw error leakage.
- [ ] PASS/WARN/FAIL: No hardcoded secrets.
- [ ] PASS/WARN/FAIL: Structured logging on critical paths.
### Performance
- [ ] PASS/WARN/FAIL: No N+1 query patterns.
- [ ] PASS/WARN/FAIL: Lists paginated with bounded queries.
### Audit Summary
**Status:** [Production Ready / Requires Remediation]
**Findings:**
1. (Finding 1)
2. (Finding 2)
**Final Verdict:**
[Explain whether the human should merge the code, or loop back to `generate` to fix the findings.]
```
## Handoff
If the Verdict requires remediation, instruct the agent/user to invoke the `generate` skill against the remediation list. Otherwise, execute **Branch Resolution**: ask the user if they want to merge the current Git worktree into `main`, submit a PR, or discard the sandbox.