agentleFS
ww-w-aiww-w-ai/bkit-codex/.agents/skills/phase-8-review/SKILL.md

phase-8-review

Skill69 starsChanged 8 months agoApache-2.0View on GitHub

Phase 8: Code Review & Architecture Review. Comprehensive review of code quality, architecture compliance, performance, and security. Triggers: code review, architecture review, review, quality check, 코드 리뷰, 아키텍처, コードレビュー, 代码审查, revisión de código, revue de code, Code-Review, revisione del codice Do NOT use for: initial design (use $phase-3-mockup), deployment (use $phase-9-deployment). Next: $phase-9-deployment

  • Reads credentials

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When all critical and high issues are resolved, proceed to $phase-9-deployment for production deployment and CI/CD setup.

    line 236

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Phase 8: Code Review & Architecture Review

Comprehensive review of code quality, architecture compliance, and production readiness.

Purpose

Phase 8 is the quality gate before deployment. Every line of code, every architectural decision, and every security measure is reviewed systematically. This phase catches issues that are exponentially more expensive to fix after deployment. No code should reach production without passing this review.

Actions

ActionDescriptionExample
startBegin Phase 8 review$phase-8-review start
codeRun code quality review$phase-8-review code
architectureRun architecture review$phase-8-review architecture
performanceRun performance review$phase-8-review performance
securityRun security review$phase-8-review security
a11yRun accessibility review$phase-8-review a11y
fullRun all reviews$phase-8-review full

Deliverables

  1. Code Quality Report - Linting results, type coverage, test coverage
  2. Architecture Compliance Report - Structure validation against conventions
  3. Performance Audit - Lighthouse scores, bundle analysis, query optimization
  4. Security Audit - OWASP compliance, dependency vulnerabilities, secret scan
  5. Accessibility Report - WCAG AA compliance, screen reader testing
  6. Review Summary - Consolidated findings with severity and remediation
docs/03-review/
├── code-quality-report.md     # Code quality findings
├── architecture-review.md     # Architecture compliance
├── performance-audit.md       # Performance analysis
├── security-audit.md          # Security findings
├── accessibility-report.md    # Accessibility compliance
└── review-summary.md          # Consolidated review summary

Process

Step 1: Code Quality Review

Naming Conventions Checklist

  • Components: PascalCase (UserCard, LoginForm)
  • Hooks: camelCase with 'use' prefix (useAuth, useUsers)
  • Utilities: camelCase (formatDate, parseQuery)
  • Constants: UPPER_SNAKE_CASE (API_BASE_URL, MAX_RETRIES)
  • Types/Interfaces: PascalCase (User, CreateUserDTO)
  • Files: kebab-case for utilities, PascalCase for components
  • API routes: kebab-case (/api/user-profiles)
  • Database: snake_case (user_profiles, created_at)

Code Structure Checklist

  • Feature-based folder organization
  • No circular dependencies
  • Single responsibility per file (< 200 lines ideal)
  • Proper barrel exports (index.ts)
  • No unused imports or dead code
  • Consistent import ordering (external -> internal -> relative)

TypeScript Quality Checklist

  • No 'any' types (use 'unknown' or proper types)
  • No type assertions (as) without justification
  • All function parameters typed
  • Return types on public functions
  • Zod schemas match TypeScript types
  • No non-null assertions (!) without safety check

Error Handling Checklist

  • All async operations wrapped in try/catch
  • API errors return appropriate HTTP status codes
  • Error messages are user-friendly (no stack traces in production)
  • Error boundaries at route segment level
  • Network errors handled with retry logic

Step 2: Architecture Compliance Review

  • Folder structure matches Phase 2 convention spec
  • Data flow follows defined patterns (server -> client)
  • State management follows guidelines (server state in TanStack Query, client state in Zustand)
  • API layer properly abstracted (services -> hooks -> components)
  • No business logic in UI components
  • Proper use of Server vs Client Components (Next.js)
  • Environment variables properly managed (.env.example exists)

Dependency Review

  • No unnecessary dependencies (check bundle impact)
  • No duplicate functionality (e.g., both axios and fetch wrappers)
  • All dependencies pinned to specific versions
  • No deprecated packages
  • License compatibility verified

Step 3: Performance Review

Frontend Performance Checklist

  • Lighthouse Performance score >= 90
  • Bundle size under budget (main < 200KB gzipped)
  • Images optimized (next/image, WebP/AVIF format)
  • Fonts preloaded and using font-display: swap
  • Code splitting on route boundaries
  • Dynamic imports for heavy components
  • No layout shifts (CLS < 0.1)
  • Memoization where appropriate (useMemo, useCallback)

Backend Performance Checklist

  • Database queries optimized (N+1 queries eliminated)
  • Proper indexing on frequently queried columns
  • API response times < 200ms for common operations
  • Pagination implemented for list endpoints
  • Caching strategy defined (Redis / in-memory / CDN)

Step 4: Security Review

  • All OWASP Top 10 mitigations verified (from Phase 7)
  • Security headers present and correct
  • No secrets in codebase (run secret scanner)
  • Authentication flow secure (token rotation, secure storage)
  • Authorization checks on every protected endpoint
  • Input validation on all API endpoints (server-side)
  • Dependency vulnerabilities patched (npm audit)
  • Error responses do not leak internal details

Step 5: Accessibility Review (WCAG AA)

  • All images have descriptive alt text
  • Color contrast ratio >= 4.5:1 (text), >= 3:1 (large text)
  • All interactive elements keyboard accessible
  • Focus order is logical and visible
  • Form inputs have associated labels
  • Error messages are announced to screen readers
  • Page structure uses semantic HTML (nav, main, article, aside)
  • Touch targets >= 44x44px on mobile

Step 6: Review Severity Classification

SeverityDefinitionAction Required
CriticalSecurity vulnerability or data loss riskMust fix before deployment
HighSignificant bug or performance issueMust fix before deployment
MediumCode quality or minor UX issueShould fix, may defer
LowStyle inconsistency or minor improvementNice to have
InfoSuggestion for future improvementDocument for backlog

Step 7: Review Summary Template

# Review Summary - [Project Name]
Date: YYYY-MM-DD
## Overall Assessment: [PASS / CONDITIONAL PASS / FAIL]

## Scores
| Category | Score | Status |
|----------|-------|--------|
| Code Quality | X/10 | Pass/Fail |
| Architecture | X/10 | Pass/Fail |
| Performance | X/10 | Pass/Fail |
| Security | X/10 | Pass/Fail |
| Accessibility | X/10 | Pass/Fail |

## Critical Issues (must fix)
1. [Issue description and remediation]

## Recommendations
1. [Future improvement suggestions]

Level-wise Application

LevelReview Scope
StarterCode quality basics: naming, structure, no dead code
DynamicFull review: code quality + performance + security + accessibility
EnterpriseFull review + load testing + penetration testing + compliance audit

Review Patterns

See references/review-checklist.md for detailed checklists:

  • Code quality review checklist
  • Architecture compliance matrix
  • Performance benchmarks
  • Security audit procedures

PDCA Application

  • Plan: Define review scope and criteria
  • Design: Prepare review checklists and tools
  • Do: Execute all review categories systematically
  • Check: Consolidate findings and assign severity
  • Act: Fix critical/high issues, document medium/low for backlog, proceed to Phase 9

Common Mistakes

MistakeSolution
Skipping review phaseBudget review time into every sprint
Only reviewing code styleReview architecture, performance, security, and accessibility too
No severity classificationUse Critical/High/Medium/Low/Info to prioritize fixes
Reviewing too lateReview incrementally throughout development
Ignoring accessibilityInclude a11y in every review; it is not optional
No automated checksSet up linting, type checking, and testing in CI

Output Location

docs/03-review/
├── code-quality-report.md
├── architecture-review.md
├── performance-audit.md
├── security-audit.md
├── accessibility-report.md
└── review-summary.md

Next Phase

When all critical and high issues are resolved, proceed to $phase-9-deployment for production deployment and CI/CD setup.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.