메뉴
Use when analyzing unfamiliar code modules, understanding system architecture, or preparing for refactoring
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/Dqz00116/skill-lib --skill code-analysis명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Use when the current Agent LLM cannot process images directly and visual analysis is needed — bridges images through KimiCode CLI print mode to a multimodal Kimi model for text description
Use when building HUDs, menus, inventory screens, settings panels, or any widget-based interface in Unreal Engine 5. Also use when connecting C++ logic to UMG Blueprint visuals, handling gamepad or keyboard focus navigation, managing UI state, creating widget animations, or troubleshooting UMG performance issues like frame drops, hitches, or widget memory leaks.
Use when working in a DevFlow project with .devflow/ directory and gate-based step-by-step workflows
SKILL.md 표시 중
SOC 직업 분류 기준
| name | code-analysis |
| description | Use when analyzing unfamiliar code modules, understanding system architecture, or preparing for refactoring |
| version | 1.2 |
Standardized workflow for reading, analyzing, and documenting codebases with attention-driven focus.
Use this skill when you need to:
Identify core components in code using heuristic rules, optimizing analysis focus.
# Use the attention_focus.py module
from attention_focus import CodeAttentionScorer
scorer = CodeAttentionScorer()
components = scorer.analyze_code_structure(file_content, file_name)
focus = scorer.get_analysis_focus(components)
| Factor | Weight | Description |
|---|---|---|
| Core Keywords | +3 | Manager, Controller, Handler, System, Core |
| Important Keywords | +2 |
| Helper, Util, Factory, Provider |
| Lines of Code | +2 (>100 lines) / +1 (50-100 lines) | Scale metric |
| Reference Count | +2 (>5 refs) / +1 (2-5 refs) | Dependency metric |
| Complexity | +1 | Methods>10 or Conditional statements>5 |
| Level | Score | Analysis Depth |
|---|---|---|
| High | 8-10 | Detailed analysis + Full code + Design principles |
| Medium | 5-7 | Focused analysis + Key code snippets |
| Low | 0-4 | Brief mention + Function description |
1. Read code file
↓
2. Run attention_focus.py analysis
↓
3. Get prioritized component list
↓
4. Analyze HIGH attention components in detail
5. Analyze MEDIUM attention components briefly
6. Reference LOW attention components as needed
↓
7. Generate focused documentation
Every code analysis task MUST follow this 4-step structure:
Definition: Clear statement of what needs to be understood
Format:
Objective: [What specifically needs to be understood]
Scope: [Boundaries of the analysis]
Depth: [Overview/Core logic/Detailed implementation]
Examples:
Definition: Concrete outputs that will be produced
Format:
Documentation:
- [Doc name 1] - [Path] - [Content description]
- [Doc name 2] - [Path] - [Content description]
Additional outputs:
- [Code examples/Flowcharts/Architecture diagrams]
Documentation Standards:
repository/projects/[Project]/docs/ or docs/[Topic]-[Type].mdDefinition: What will be covered in the analysis
Format:
Analysis content:
1. [Module A] - [Point 1, Point 2, Point 3]
2. [Module B] - [Point 1, Point 2, Point 3]
3. [Inter-module relationships] - [Interaction flow]
Include elements:
□ Core class/interface design
□ Data flow/Control flow
□ Key algorithms/Logic
□ Design patterns
□ Dependencies
Definition: Estimated token consumption for the analysis
Format:
Token estimation:
- Code reading: ~[X,000] tokens
- Documentation: ~[X,000] tokens
- Total: ~[X,000]-[Y,000] tokens
- Estimated time: [X]-[Y] minutes
Estimation Guidelines:
| Complexity | Code reading | Documentation | Total | Time |
|---|---|---|---|---|
| Simple (1-2 files) | 3K-5K | 2K-3K | 5K-8K | 15-20min |
| Medium (module-level) | 10K-20K | 5K-10K | 15K-30K | 30-50min |
| Complex (system-level) | 30K-50K | 15K-25K | 45K-75K | 60-90min |
1. User Request
│
▼
2. Clarify Requirements (if needed)
│
├── Confirm analysis scope boundaries
├── Confirm key class definition locations (file paths)
└── ⚠️ If definition locations are unclear, must ask the requester to explicitly specify
│
▼
3. Output Analysis Plan (4-step structure)
│
├── 1. Objective
├── 2. Deliverables
├── 3. Content
└── 4. Token Estimation
│
▼
4. Wait for "Plan Approval" Confirmation
│
▼
5. Execute Analysis
│
├── Read relevant code
├── Understand logic
└── Extract key points
│
▼
6. Produce Documentation
│
├── Write technical doc
├── Include code examples
└── Create diagrams if needed
│
▼
7. Report Completion
└── Summary of findings
User: "Analyze PlayerQuest's progress update mechanism"
Plan Output:
## Code Analysis Plan
### 1. Objective
Understand PlayerQuest's progress update mechanism, including:
- How progress is stored and updated
- Task completion determination logic
- Interaction with the medal system
### 2. Deliverables
- `PlayerQuest-Progress-Analysis.md`
- Path: `repository/projects/BattleCore/docs/`
- Contains: Flowchart + Core code + Data flow
### 3. Content
1. PlayerQuest class structure
2. updateProgress() / accumulateProgress() implementation
3. Task completion determination logic
4. Coupling relationship with PlayerMedal
### 4. Token Estimation
- Code reading: ~5,000 tokens
- Documentation: ~3,000 tokens
- Total: ~8,000 tokens
- Estimated time: 15-20 minutes
User: "Understand the overall skill system architecture"
Plan Output:
## Code Analysis Plan
### 1. Objective
Fully understand the FAbility skill system architecture:
- Core class hierarchy
- State machine implementation
- Skill lifecycle
- Integration with the battle core
### 2. Deliverables
- `FAbility-Architecture.md`
- Path: `repository/projects/BattleCore/docs/`
- Contains: Architecture diagram + Class diagram + Real-world examples
- `Skill-Lifecycle-Flow.md`
- Complete skill lifecycle flow
### 3. Content
1. FAbility base class design
2. State machine (EAbilityState)
3. Concrete skill implementation examples
4. CD/Cost system
5. Event system
### 4. Token Estimation
- Code reading: ~30,000 tokens
- Documentation: ~15,000 tokens
- Total: ~45,000 tokens
- Estimated time: 60-80 minutes
Rule: When definition locations are unclear during code analysis, must ask the requester to explicitly specify the location in advance
Execution Steps:
Example:
❌ Incorrect approach:
User: "Analyze NetMessage implementation"
AI: (Blindly search, can't find correct location, analyze based on assumptions)
✅ Correct approach:
User: "Analyze NetMessage implementation"
AI: "Please provide the definition file path for NetMessage,
Search found possible locations:
- Server/Network/NetMessage.h
- Server/Common/NetMessage.h
Please confirm which file?"
User: "In Server/Network/NetMessage.h"
AI: (Start analysis based on explicit path)
✅ Define clear scope boundaries, avoid over-analysis ✅ Provide specific file paths and line numbers ✅ Include actual code snippets ✅ Use diagrams to aid understanding (text descriptions) ✅ Estimates should be conservative, leave buffer
❌ Don't use vague scopes ("analyze the entire project") ❌ Don't omit key deliverable information ❌ Don't underestimate token consumption for complex systems ❌ Don't mix multiple unrelated objectives ❌ Don't blindly guess when definition locations are unclear (must ask the requester to explicitly specify file paths)
## Code Analysis Plan
### 1. Objective
[Specific objective description]
Scope: [Scope boundaries]
Depth: [Overview/Core/Detailed]
### 2. Deliverables
- [Doc name] - [Path] - [Description]
### 3. Content
1. [Module A] - [Key points]
2. [Module B] - [Key points]
3. [Relationships] - [Flow]
### 4. Token Estimation
- Code reading: ~[X,000] tokens
- Documentation: ~[X,000] tokens
- Total: ~[X,000]-[Y,000] tokens
- Estimated time: [X]-[Y] minutes
v1.2 (2026-02-12) - Added Attention-Driven Analysis
v1.1 (2026-02-10) - Added critical rule
v1.0 (2026-02-10) - Initial release