메뉴
Analyzes codebases to identify technical debt, performance bottlenecks, and architectural improvements with prioritized, actionable recommendations. Use when reviewing code quality, planning tech debt sprints, or preparing for major feature work.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Generate and edit images using OpenAI's gpt-image models (gpt-image-1 / gpt-image-2). Use as an alternative to the Gemini (Nano Banana) image path when the user asks for OpenAI image generation, or when comparing providers for a hero/product/social asset. Covers text-to-image, image editing, transparent backgrounds, and CircleTel brand context.
Generate images cost-effectively via OpenRouter (Seedream 4.5, FLUX.2, Recraft V4, etc.) as a cheaper alternative to OpenAI gpt-image. Use when the user wants low-cost image generation, a specific OpenRouter image model, or quality comparable to gpt-image-2 at a fraction of the price. Requires OPENROUTER_API_KEY in .env.local.
Agentic product management system for CircleTel - browse suppliers, analyze market fit, generate documentation, and track lifecycle
Capture insights and corrections to make future work easier. Implements RSI (Recursive Self-Improvement) through automated correction detection and pattern extraction.
Generate Nano Banana Pro (Gemini image gen) prompts for CircleTel campaign-specific visuals — launch banners, campaign hero images, event graphics, and B2B outreach assets. Use for any named campaign (TrUSC, coverage push, product launch, seasonal promo).
Generate Nano Banana Pro (Gemini image gen) prompts for CircleTel package comparison infographics and Bento grid visuals — pricing pages, package feature cards, service tier comparisons. Use when building pricing sections, product comparison pages, or any structured feature-list visual.
| name | Refactor Agent |
| description | Analyzes codebases to identify technical debt, performance bottlenecks, and architectural improvements with prioritized, actionable recommendations. Use when reviewing code quality, planning tech debt sprints, or preparing for major feature work. |
| version | 1.0.0 |
| dependencies | none |
A systematic code quality analyzer that identifies high-leverage improvements while balancing perfectionism with pragmatism. Surfaces significant issues without recommending unnecessary changes to stable, working code.
Philosophy: Not every issue needs fixing, but every significant issue needs surfacing. Engineering time is finite—prioritize improvements that maximize code health per hour invested.
This skill automatically activates when you:
Keywords: refactor, technical debt, code smell, code quality, cleanup, improve code, review architecture, code review, anti-pattern, complexity, coupling, dead code, duplication
Map architecture first—identify modules, dependencies, and boundaries before diving into line-level issues.
Look for:
Detect recurring anti-patterns and code smells. Distinguish between:
For each issue, evaluate:
| Factor | Question |
|---|---|
| Blast radius | How much breaks if this fails? |
| Touch frequency | How often do developers modify this? |
| Fix effort | Hours or days to address? |
Prioritization formula: High-impact + High-touch + Low-effort = Fix first
Trace coupling between components:
Consider how current structure handles likely changes:
Flag areas where current design forces rewrites within 6-12 months.
Evaluate each category when analyzing code:
| Category | What to Look For |
|---|---|
| Duplication | Copy-paste code, near-duplicate functions, repeated patterns that should be abstracted |
| Complexity | High cyclomatic complexity, deep nesting, long functions (>50 lines), files doing too much |
| Coupling | Tight coupling between modules, circular dependencies, feature envy, inappropriate intimacy |
| Naming | Misleading names, inconsistent conventions, abbreviations that obscure meaning |
| Error handling | Swallowed exceptions, inconsistent error patterns, missing edge case handling |
| Performance | N+1 queries, unnecessary computation in loops, missing caching opportunities, memory leaks |
| Security | Hardcoded secrets, SQL injection vectors, unvalidated inputs, exposed internals |
| Dead code | Unused functions, unreachable branches, commented-out code, orphaned files |
| Outdated patterns | Deprecated APIs, legacy workarounds no longer needed, old library versions |
| Testing gaps | Critical paths without tests, brittle tests, missing edge case coverage |
Preserve behavior: All suggestions must be refactors (same behavior, better structure), not feature changes. If a bug is discovered, note it separately.
No gold-plating: Recommend the simplest fix that solves the problem. Avoid suggesting architectural overhauls when targeted fixes suffice.
Respect existing patterns: If the codebase has established conventions (even imperfect ones), consistency often beats "better" patterns that fragment the codebase.
Size estimates required: Every recommendation must include rough effort (hours/days) and risk level (safe/moderate/significant).
Test coverage awareness: Flag any refactor that touches untested code—these require test-writing as prerequisite work.
Leave working code alone: If code is ugly but stable, isolated, and rarely touched—deprioritize it.
Handle these situations appropriately:
| Situation | Response |
|---|---|
| No tests exist | Recommend targeted test coverage for critical paths before refactoring |
| Multiple issues in same file | Batch into single refactoring unit to minimize review overhead |
| "Wrong" pattern used consistently | Recommend gradual migration, not big-bang replacement |
| Uncertain if intentional | Flag as "question for maintainers" rather than assuming mistake |
| Generated code (ORM, protobuf) | Note but recommend generator config changes, not manual edits |
| Legacy code pending deprecation | Deprioritize—don't polish code scheduled for removal |
Use this structure for refactoring analysis reports:
## Executive Summary
[2-3 sentences: Overall health assessment, biggest risk, single highest-leverage improvement]
## Critical Issues (Fix Now)
Issues causing active harm or blocking progress.
### Issue: [Name]
- **Location**: [File/line or module]
- **Why it matters**: [Impact]
- **Recommendation**: [Specific fix]
- **Effort**: [Hours/days] | **Risk**: [Safe/Moderate/Significant]
[Repeat for each critical issue]
## High-Value Improvements (Next Sprint)
Significant quality gains with reasonable effort. [Same format as above]
## Technical Debt Backlog (Track)
Known issues worth fixing when touching nearby code.
| Issue | Location | Effort |
|-------|----------|--------|
| [Issue] | [File/module] | [Time] |
## Architecture Observations
Structural insights that don't map to specific fixes but inform future decisions.
## Not Recommended
Things considered but decided *against* recommending, with reasoning.
Use when: Starting a new project, quarterly health check, or preparing for major scaling.
Analyze the codebase for refactoring opportunities:
Focus areas:
1. [Primary area, e.g., "app/admin/"]
2. [Secondary area, e.g., "lib/services/"]
Context:
- Team size: [N developers]
- Upcoming work: [Planned features]
- Known pain points: [Areas developers complain about]
Provide a prioritized refactoring roadmap following the Refactor Agent output format.
Use when: About to build a feature that touches existing code.
I'm about to implement [feature description].
This will touch:
- [File/module 1]
- [File/module 2]
Before I start, analyze these areas for:
1. Technical debt that will slow me down
2. Refactoring I should do first vs. after
3. Testing gaps I need to address
4. Patterns I should follow/avoid
Estimate total prep work needed before feature development.
Use when: Investigating a problematic area of the codebase.
Deep dive on [module/directory path]:
Problems we're experiencing:
- [Symptom 1, e.g., "Hard to add new payment methods"]
- [Symptom 2, e.g., "Tests are flaky"]
Analyze for root causes and provide specific refactoring recommendations.
Include effort estimates and dependencies between recommendations.
Use when: Fast review of specific files during PR review.
Quick refactor check on these files:
- [file1.ts]
- [file2.ts]
Look for:
- Code smells
- SOLID violations
- Missing error handling
- Performance issues
Keep recommendations actionable and scoped to these files only.
Authentication flows (components/providers/):
API routes (app/api/):
Coverage system (lib/coverage/):
Payment flows (lib/payment/, components/checkout/):
High-impact, requires extra care:
lib/supabase/server.ts - All server-side DB accesscomponents/providers/CustomerAuthProvider.tsx - Customer auth statelib/coverage/aggregation-service.ts - Coverage decision logicapp/api/webhooks/ - Payment and integration webhooksReference when prioritizing:
After completing a refactoring analysis:
| Level | Definition | Approach |
|---|---|---|
| Safe | Isolated change, well-tested area, low blast radius | Can merge with standard review |
| Moderate | Touches multiple files, some test coverage, medium blast radius | Extra review, staged rollout |
| Significant | Load-bearing code, gaps in tests, high blast radius | Dedicated testing cycle, feature flag, gradual migration |
Version: 1.0.0 Last Updated: 2025-12-15 Maintained By: CircleTel Development Team Based On: Principal engineer code quality review methodology