Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
□ Are glossary.md terms consistently used in code?
- Business terms → Code naming matching
- Global standard terms → API response field names matching
□ Do entity definitions match actual types?
□ Do relationship definitions match actual implementation?
□ Are design tokens defined? (CSS Variables / ThemeData)
□ Do components use tokens? (no hardcoded colors)
□ Are component variants consistent?
□ Dark mode support (if defined)
Phase 6 → Verify: UI-API Integration Consistency
□ API client layer structure compliance
- Components → hooks → services → apiClient
- No direct fetch calls
□ Type consistency
- Phase 4 API spec types = Phase 6 client types
□ Error handling consistency
- Global error handler usage
- Error code-specific handling logic
□ State management pattern consistency
Phase 7 → Verify: Security/SEO Application
□ Authentication/authorization middleware applied
□ Input validation (server-side)
□ XSS, CSRF defense
□ No sensitive info exposed to client
□ SEO meta tags applied
□ Is there business logic in components?
□ Are there direct API calls? (should go through hooks)
□ Is state management properly separated?
□ Do components have single responsibility?
Application Layer (Services)
□ Are domain logic and infrastructure logic separated?
□ Are external dependencies abstracted?
□ Is the structure testable?
□ Are use cases clearly defined?
Domain Layer (Types/Entities)
□ Are there no external library dependencies?
□ Does it contain only pure business rules?
□ Do types match Phase 1 schema?
Infrastructure Layer (API Client)
□ Are external service calls abstracted?
□ Is error handling consistent?
□ Is configuration managed via environment variables?
Architecture Review Checklist
Structure
Does folder structure match conventions
Is separation of concerns well done
Is dependency direction correct (outside → inside)
Patterns
Are consistent patterns used
Is there unnecessary abstraction
Is proper encapsulation done
Convention Review Checklist
Naming
Does it follow Phase 2 defined rules
Are meaningful names used
Is there consistency
Code Style
Unified indentation, quotes, etc.
Is file length appropriate
Is function length appropriate
Code Quality Checklist
Is there duplicate code
Are there highly complex functions
Is error handling appropriate
Is type safety ensured
AI-Assisted Review
Request code review from Claude:
"Review this project's code.
- Does it follow CONVENTIONS.md rules
- Is there architecture consistency
- Are there potential bugs or improvements"
Template
See templates/pipeline/phase-8-review.template.md
Next Phase
Phase 9: Deployment → After review completion, deploy to production
6. In-Depth Code Quality Review
6.1 Duplicate Code Detection
Detection Methods
# 1. Search for similar function names
grep -r "function.*format" src/
grep -r "function.*calculate" src/
grep -r "function.*get.*By" src/
# 2. Search for similar patterns
grep -rn "reduce.*sum" src/
grep -rn "filter.*map" src/
grep -rn "useState.*useEffect" src/
Handling by Duplication Type
Type
Example
Solution
Exact duplicate
Same code copy-paste
Extract to function
Structural similarity
Same logic, different data
Parameterize
Conceptual similarity
Different implementations for similar purpose
Integrate or interface
Duplicate Code Checklist
□ Is the same logic in 2+ places?
□ Are there multiple functions with similar names?
□ Is the same data transformation repeated?
□ Are similar UI patterns repeated?
□ Is the same API call pattern repeated?
□ Is similar error handling repeated?
6.2 Reusability Assessment
Assessment Criteria
Score
Criteria
Description
⭐⭐⭐
High
Can be used in other projects
⭐⭐
Medium
Can be used in multiple places within same project
⭐
Low
Used only for specific feature
Reusability Checklist
Check for each function/component:
□ Is it tied to a specific domain?
□ Does it depend on external state?
□ Are parameters generic?
□ Is the return value predictable?
□ Are there side effects?
6.3 Extensibility Assessment
Extensibility Check
When new requirements come:
□ Can it be added without modifying existing code?
□ Can behavior be changed by configuration only?
□ Is adding new types/cases easy?
□ Can it be extended without adding conditionals?
Extensibility Anti-patterns
// ❌ Requires modification for each extensionfunctionprocess(type: string) {
if (type === 'a') { /* ... */ }
elseif (type === 'b') { /* ... */ }
// Add else if for each new type...
}
// ❌ Hardcoded listconstALLOWED_TYPES = ['a', 'b', 'c']
// ❌ Enumerated switch statementsswitch (action.type) {
case'ADD': // ...case'REMOVE': // ...// Add case for each new action...
}
□ Does the class/function change for only one reason?
□ Does the name clearly explain the role?
□ Is "and" in the name? → Needs separation
O - Open/Closed (OCP)
□ Is it open for extension? (new features can be added)
□ Is it closed for modification? (no existing code changes needed)
□ Are interfaces/abstractions used?
L - Liskov Substitution (LSP)
□ Can subtypes replace parent types?
□ Do overridden methods keep the contract?
I - Interface Segregation (ISP)
□ Is the interface too large?
□ Must unused methods be implemented?
□ Can the interface be split smaller?
D - Dependency Inversion (DIP)
□ Does it depend on abstractions instead of concrete classes?
□ Are dependencies injected? (DI)
□ Is the structure testable?
6.5 Refactoring Priority
Urgent (Required before deployment):
1. Duplication that can cause bugs
2. Security vulnerabilities
3. Performance bottlenecks
High (As soon as possible):
4. Same logic duplicated in 3+ places
5. Files over 200 lines
6. Nesting deeper than 5 levels
Medium (Next sprint):
7. Structure lacking extensibility
8. Naming inconsistencies
9. Structure difficult to test
Low (Backlog):
10. Style inconsistencies
11. Excessive comments
12. Unused code
7. AI Code Review Request Template
Please review the code from these perspectives:
1. Duplicate Code
- Are there similar functions/components?
- Is there common logic that can be extracted?
2. Reusability
- Can it be used generically?
- Is it tied to a specific domain?
3. Extensibility
- Can it flexibly respond to new requirements?
- Are there hardcoded parts?
4. SOLID Principles
- Does it follow single responsibility?
- Is it open for extension and closed for modification?
5. Convention Compliance
- Does it follow CONVENTIONS.md rules?
- Is naming consistent?
Please identify parts that need refactoring and their priority.
8. Gap Analysis (Design vs Implementation)
Gap Analysis Report Template
# Gap Analysis Report## Analysis Target- Design document: docs/02-design/{feature}.design.md
- Implementation path: src/features/{feature}/
## Results by Category### API Endpoints
| Design | Implementation | Status |
|--------|----------------|--------|
| POST /api/users | POST /api/users | ✅ Match |
| GET /api/users/:id | - | ❌ Not implemented |
| - | DELETE /api/users/:id | ⚠️ Missing from design |
### Data Model
| Design Entity | Implementation | Status |
|---------------|----------------|--------|
| User | types/user.ts | ✅ Match |
| UserRole | - | ❌ Not implemented |
### Match Rate- Total items: 10
- Matches: 7
- Not implemented: 2
- Missing from design: 1
-**Match Rate: 70%**
