重要前提
安装AI Skills的关键前提是:必须科学上网,且开启TUN模式,这一点至关重要,直接决定安装能否顺利完成,在此郑重提醒三遍:科学上网,科学上网,科学上网。查看完整安装教程 →
engineer-expertise-extractor by jamesrochabrun/skills
npx skills add https://github.com/jamesrochabrun/skills --skill engineer-expertise-extractor通过分析工程师的 GitHub 贡献,提取并记录其编码专业技能,创建一个结构化的知识库,捕捉其编码风格、模式、最佳实践和架构决策。
通过以下方式研究工程师的工作,创建一个“数字导师”:
知识保留:
一致性:
学习:
使用 GitHub CLI (gh),该技能:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
将发现分类为:
创建结构化文件夹:
engineer_profiles/
└── [engineer_name]/
├── README.md (overview)
├── coding_style/
│ ├── languages/
│ ├── naming_conventions.md
│ ├── code_structure.md
│ └── formatting_preferences.md
├── patterns/
│ ├── common_solutions.md
│ ├── design_patterns.md
│ └── code_examples/
├── best_practices/
│ ├── code_quality.md
│ ├── testing_approach.md
│ ├── performance.md
│ └── security.md
├── architecture/
│ ├── design_decisions.md
│ ├── tech_choices.md
│ └── trade_offs.md
├── code_review/
│ ├── feedback_style.md
│ ├── common_suggestions.md
│ └── review_examples.md
└── examples/
├── by_language/
├── by_pattern/
└── notable_prs/
包含:
捕捉:
示例:
# 编码风格: [Engineer Name]
## 命名约定
### 变量
- 使用描述性名称:`userAuthentication` 而非 `ua`
- 布尔变量:`isActive`, `hasPermission`, `canEdit`
- 集合:复数名称 `users`, `items`, `transactions`
### 函数
- 动词优先:`getUserById`, `validateInput`, `calculateTotal`
- 优先使用纯函数
- 单一职责
### 类
- PascalCase:`UserService`, `PaymentProcessor`
- 接口前缀:`IUserRepository`
- 具体实现:`MongoUserRepository`
## 代码结构
### 文件组织
- 每个文件一个类
- 相关函数分组
- 测试与实现放在一起
- 清晰的关注点分离
### 函数长度
- 首选最多 20-30 行
- 提取辅助函数
- 单一抽象层次
捕捉:
示例:
# 常见模式: [Engineer Name]
## 依赖注入
在服务中一致使用:
```typescript
// Pattern: Constructor injection
class UserService {
constructor(
private readonly userRepo: IUserRepository,
private readonly logger: ILogger
) {}
}
原因: 可测试性、松耦合、清晰的依赖关系
一致的错误处理方法:
// Pattern: Custom error types + global handler
class ValidationError extends Error {
constructor(message: string) {
super(message);
this.name = 'ValidationError';
}
}
// Usage
if (!isValid(input)) {
throw new ValidationError('Invalid input format');
}
原因: 类型安全的错误、集中处理、清晰的调试
### 最佳实践文档
**捕捉:**
* 质量标准
* 测试方法
* 性能指南
* 安全实践
* 文档标准
**示例:**
describe('UserService', () => {
describe('createUser', () => {
it('should create user with valid data', async () => {
// Arrange
const userData = { email: 'test@example.com', name: 'Test' };
const mockRepo = createMockRepository();
// Act
const result = await userService.createUser(userData);
// Assert
expect(result.id).toBeDefined();
expect(result.email).toBe(userData.email);
});
});
});
### 架构文档
**捕捉:**
* 设计决策
* 技术选择
* 所做的权衡
* 系统设计方法
**示例:**
背景: 扩展用户服务 决策: 从单体开始,需要时提取服务 推理:
权衡:
背景: 移动应用的 API 设计 决策: 带版本控制的 REST 推理:
何时重新考虑: 如果前端需要复杂查询
### 代码审查文档
**捕捉:**
* 反馈模式
* 审查方法
* 常见建议
* 沟通风格
**示例:**
安全:
性能:
测试:
代码质量:
## 使用此技能
### 提取工程师个人资料
./scripts/extract_engineer.sh [github-username]
**交互式工作流:**
1. 输入 GitHub 用户名
2. 选择仓库范围(全部/特定组织)
3. 选择分析深度(最近 N 个 PR)
4. 指定关注领域(语言、主题)
5. 提取并组织发现
**输出:** `engineer_profiles/[username]/` 中的结构化个人资料
### 分析特定仓库
./scripts/analyze_repo.sh [repo-url] [engineer-username]
专注于分析特定仓库的贡献。
### 更新现有个人资料
./scripts/update_profile.sh [engineer-username]
添加新的 PR 并更新现有个人资料。
## 研究来源
### GitHub CLI 查询
**拉取请求:**
gh pr list --author [username] --limit 100 --state all gh pr view [pr-number] --json title,body,files,reviews,comments
**代码变更:**
gh pr diff [pr-number] gh api repos/{owner}/{repo}/pulls/{pr}/files
**审查:**
gh pr view [pr-number] --comments gh api repos/{owner}/{repo}/pulls/{pr}/reviews
**提交:**
gh api search/commits --author [username]
### 分析技术
**模式识别:**
* 识别重复出现的代码结构
* 提取常见解决方案
* 检测命名模式
* 发现架构选择
**风格提取:**
* 分析格式化一致性
* 提取命名约定
* 识别注释模式
* 检测结构偏好
**最佳实践识别:**
* 寻找测试模式
* 发现错误处理方法
* 识别安全实践
* 提取性能优化
## 使用案例
### 1. 新工程师入职
**问题:** 新工程师需要学习团队标准
**解决方案:** 提供高级工程师的个人资料作为参考
**好处:**
* 来自代码库的真实示例
* 理解团队约定
* 了解决策过程
* 学习最佳实践
### 2. 代码审查培训
**问题:** 教授良好的代码审查技能
**解决方案:** 研究经验丰富的审查者的反馈模式
**好处:**
* 学习需要关注什么
* 理解反馈风格
* 查看常见问题
* 提高审查质量
### 3. 知识转移
**问题:** 高级工程师离职,知识丢失
**解决方案:** 在其离职前提取其专业知识
**好处:**
* 保留团队内部知识
* 记录决策
* 保持代码质量
* 降低人员风险
### 4. 建立团队标准
**问题:** 团队间编码风格不一致
**解决方案:** 从优秀工程师中提取模式,创建标准
**好处:**
* 基于证据的标准
* 真实世界的示例
* 获得团队认同
* 一致的代码库
### 5. AI 代理训练
**问题:** 代理需要像特定工程师一样编码
**解决方案:** 向代理提供提取的个人资料
**好处:**
* 匹配专家的风格
* 遵循他们的模式
* 应用他们的最佳实践
* 保持一致性
## 代理对个人资料的使用
当代理可以访问工程师个人资料时,它可以:
**代码生成:**
* 遵循提取的命名约定
* 使用已识别的模式
* 应用已记录的最佳实践
* 匹配架构风格
**代码审查:**
* 以工程师的风格提供反馈
* 检查他们会发现的常见问题
* 应用他们的质量标准
* 匹配他们的优先级
**问题解决:**
* 使用他们的常见解决方案
* 遵循他们的架构方法
* 应用他们的设计模式
* 考虑他们的权衡
**示例代理提示:**
"Using the profile at engineer_profiles/senior_dev/, write a user service following their coding style, patterns, and best practices. Pay special attention to their error handling approach and testing standards."
## 最佳实践
### 研究伦理
**应做:**
* ✅ 提取前获得许可
* ✅ 专注于公开贡献
* ✅ 尊重隐私
* ✅ 用于学习和改进
**不应做:**
* ❌ 未经许可提取
* ❌ 在外部共享个人资料
* ❌ 包含敏感信息
* ❌ 用于绩效评估
### 个人资料维护
**定期更新:**
* 每季度刷新
* 添加新的重要 PR
* 使用最新模式更新
* 归档过时的实践
**质量控制:**
* 验证提取的模式
* 审查示例的相关性
* 更新文档
* 移除已弃用的实践
### 有效使用
**用于学习:**
* 结合上下文研究模式
* 理解选择背后的推理
* 练习应用技术
* 不清楚时提出问题
**用于复制:**
* 从风格指南开始
* 参考类似问题的模式
* 适应当前上下文
* 不要盲目复制
## 局限性
**此技能提取的内容:**
* ✅ 编码风格和约定
* ✅ 常见模式和方法
* ✅ 最佳实践和指南
* ✅ 架构决策
* ✅ 审查反馈模式
**此技能未捕捉的内容:**
* ❌ 实时问题解决过程
* ❌ 口头沟通风格
* ❌ 会议讨论
* ❌ 设计阶段思考
* ❌ 人际指导
## 未来增强
**潜在新增功能:**
* Slack 消息分析(沟通风格)
* 设计文档提取(设计思维)
* 会议记录分析(决策过程)
* 视频分析(结对编程会话)
* 代码指标跟踪(随时间演变)
## 示例输出
engineer_profiles/ └── senior_dev/ ├── README.md │ # Senior Dev - Staff Engineer │ Expertise: TypeScript, Node.js, System Design │ Focus: API design, performance optimization │ ├── coding_style/ │ ├── typescript_style.md │ ├── naming_conventions.md │ └── code_structure.md │ ├── patterns/ │ ├── dependency_injection.md │ ├── error_handling.md │ └── examples/ │ ├── service_pattern.ts │ └── repository_pattern.ts │ ├── best_practices/ │ ├── testing_strategy.md │ ├── code_quality.md │ └── performance.md │ ├── architecture/ │ ├── api_design.md │ ├── database_design.md │ └── scaling_approach.md │ ├── code_review/ │ ├── feedback_examples.md │ └── review_checklist.md │ └── examples/ └── notable_prs/ ├── pr_1234_auth_refactor.md └── pr_5678_performance_fix.md
## 总结
此技能将工程师的 GitHub 贡献转化为结构化、可重用的知识库。它以以下格式捕捉他们的专业知识:
* **人类可以学习** - 带有示例的清晰文档
* **代理可以复制** - 结构化的模式和指南
* **团队可以采用** - 基于证据的最佳实践
* **组织可以保留** - 在人员流动后仍能留存的知识
**目标:** 使专业知识可扩展、可学习、可复制。
---
**“最好的学习方式就是向已经掌握它的人学习。”**
每周安装次数
60
仓库
[jamesrochabrun/skills](https://github.com/jamesrochabrun/skills "jamesrochabrun/skills")
GitHub 星标数
103
首次出现
2026年1月22日
安全审计
[Gen Agent Trust HubPass](/jamesrochabrun/skills/engineer-expertise-extractor/security/agent-trust-hub)[SocketPass](/jamesrochabrun/skills/engineer-expertise-extractor/security/socket)[SnykWarn](/jamesrochabrun/skills/engineer-expertise-extractor/security/snyk)
安装于
claude-code44
opencode42
gemini-cli39
codex39
github-copilot38
cursor35
Extract and document an engineer's coding expertise by analyzing their GitHub contributions, creating a structured knowledge base that captures their coding style, patterns, best practices, and architectural decisions.
Researches an engineer's work to create a "digital mentor" by:
Knowledge Preservation:
Consistency:
Learning:
Using GitHub CLI (gh), the skill:
Categorizes findings into:
Creates structured folders:
engineer_profiles/
└── [engineer_name]/
├── README.md (overview)
├── coding_style/
│ ├── languages/
│ ├── naming_conventions.md
│ ├── code_structure.md
│ └── formatting_preferences.md
├── patterns/
│ ├── common_solutions.md
│ ├── design_patterns.md
│ └── code_examples/
├── best_practices/
│ ├── code_quality.md
│ ├── testing_approach.md
│ ├── performance.md
│ └── security.md
├── architecture/
│ ├── design_decisions.md
│ ├── tech_choices.md
│ └── trade_offs.md
├── code_review/
│ ├── feedback_style.md
│ ├── common_suggestions.md
│ └── review_examples.md
└── examples/
├── by_language/
├── by_pattern/
└── notable_prs/
Contains:
Captures:
Example:
# Coding Style: [Engineer Name]
## Naming Conventions
### Variables
- Use descriptive names: `userAuthentication` not `ua`
- Boolean variables: `isActive`, `hasPermission`, `canEdit`
- Collections: plural names `users`, `items`, `transactions`
### Functions
- Verb-first: `getUserById`, `validateInput`, `calculateTotal`
- Pure functions preferred
- Single responsibility
### Classes
- PascalCase: `UserService`, `PaymentProcessor`
- Interface prefix: `IUserRepository`
- Concrete implementations: `MongoUserRepository`
## Code Structure
### File Organization
- One class per file
- Related functions grouped together
- Tests alongside implementation
- Clear separation of concerns
### Function Length
- Max 20-30 lines preferred
- Extract helper functions
- Single level of abstraction
Captures:
Example:
# Common Patterns: [Engineer Name]
## Dependency Injection
Used consistently across services:
\`\`\`typescript
// Pattern: Constructor injection
class UserService {
constructor(
private readonly userRepo: IUserRepository,
private readonly logger: ILogger
) {}
}
\`\`\`
**Why:** Testability, loose coupling, clear dependencies
## Error Handling
Consistent error handling approach:
\`\`\`typescript
// Pattern: Custom error types + global handler
class ValidationError extends Error {
constructor(message: string) {
super(message);
this.name = 'ValidationError';
}
}
// Usage
if (!isValid(input)) {
throw new ValidationError('Invalid input format');
}
\`\`\`
**Why:** Type-safe errors, centralized handling, clear debugging
Captures:
Example:
# Best Practices: [Engineer Name]
## Testing
### Unit Test Structure
- AAA pattern (Arrange, Act, Assert)
- One assertion per test preferred
- Test names describe behavior
- Mock external dependencies
\`\`\`typescript
describe('UserService', () => {
describe('createUser', () => {
it('should create user with valid data', async () => {
// Arrange
const userData = { email: 'test@example.com', name: 'Test' };
const mockRepo = createMockRepository();
// Act
const result = await userService.createUser(userData);
// Assert
expect(result.id).toBeDefined();
expect(result.email).toBe(userData.email);
});
});
});
\`\`\`
### Test Coverage
- Aim for 80%+ coverage
- 100% coverage for critical paths
- Integration tests for APIs
- E2E tests for user flows
## Code Review Standards
### What to Check
- [ ] Tests included and passing
- [ ] No console.logs remaining
- [ ] Error handling present
- [ ] Comments explain "why" not "what"
- [ ] No hardcoded values
- [ ] Security considerations addressed
Captures:
Example:
# Architectural Decisions: [Engineer Name]
## Decision: Microservices vs Monolith
**Context:** Scaling user service
**Decision:** Start monolith, extract services when needed
**Reasoning:**
- Team size: 5 engineers
- Product stage: MVP
- Premature optimization risk
- Easier debugging and deployment
**Trade-offs:**
- Monolith pros: Simpler, faster development
- Monolith cons: Harder to scale later
- Decision: Optimize for current needs, refactor when hitting limits
## Decision: REST vs GraphQL
**Context:** API design for mobile app
**Decision:** REST with versioning
**Reasoning:**
- Team familiar with REST
- Simple use cases
- Caching easier
- Over-fetching not a problem yet
**When to reconsider:** If frontend needs complex queries
Captures:
Example:
# Code Review Style: [Engineer Name]
## Review Approach
### Priority Order
1. Security vulnerabilities
2. Logic errors
3. Test coverage
4. Code structure
5. Naming and style
### Feedback Style
- Specific and constructive
- Explains "why" behind suggestions
- Provides examples
- Asks questions to understand reasoning
### Common Suggestions
**Security:**
- "Consider input validation here"
- "This query is vulnerable to SQL injection"
- "Should we rate-limit this endpoint?"
**Performance:**
- "This N+1 query could be optimized with a join"
- "Consider caching this expensive operation"
- "Memoize this pure function"
**Testing:**
- "Can we add a test for the error case?"
- "What happens if the API returns null?"
- "Let's test the boundary conditions"
**Code Quality:**
- "Can we extract this into a helper function?"
- "This function is doing too many things"
- "Consider a more descriptive variable name"
./scripts/extract_engineer.sh [github-username]
Interactive workflow:
Output: Structured profile in engineer_profiles/[username]/
./scripts/analyze_repo.sh [repo-url] [engineer-username]
Focuses analysis on specific repository contributions.
./scripts/update_profile.sh [engineer-username]
Adds new PRs and updates existing profile.
Pull Requests:
gh pr list --author [username] --limit 100 --state all
gh pr view [pr-number] --json title,body,files,reviews,comments
Code Changes:
gh pr diff [pr-number]
gh api repos/{owner}/{repo}/pulls/{pr}/files
Reviews:
gh pr view [pr-number] --comments
gh api repos/{owner}/{repo}/pulls/{pr}/reviews
Commits:
gh api search/commits --author [username]
Pattern Recognition:
Style Extraction:
Best Practice Identification:
Problem: New engineer needs to learn team standards Solution: Provide senior engineer's profile as reference
Benefits:
Problem: Teaching good code review skills Solution: Study experienced reviewer's feedback patterns
Benefits:
Problem: Senior engineer leaving, knowledge lost Solution: Extract their expertise before departure
Benefits:
Problem: Inconsistent coding styles across team Solution: Extract patterns from best engineers, create standards
Benefits:
Problem: Agent needs to code like specific engineer Solution: Provide extracted profile to agent
Benefits:
When an agent has access to an engineer profile, it can:
Code Generation:
Code Review:
Problem Solving:
Example Agent Prompt:
"Using the profile at engineer_profiles/senior_dev/, write a user service
following their coding style, patterns, and best practices. Pay special
attention to their error handling approach and testing standards."
DO:
DON'T:
Regular Updates:
Quality Control:
For Learning:
For Replication:
What This Extracts:
What This Doesn't Capture:
Potential additions:
engineer_profiles/
└── senior_dev/
├── README.md
│ # Senior Dev - Staff Engineer
│ Expertise: TypeScript, Node.js, System Design
│ Focus: API design, performance optimization
│
├── coding_style/
│ ├── typescript_style.md
│ ├── naming_conventions.md
│ └── code_structure.md
│
├── patterns/
│ ├── dependency_injection.md
│ ├── error_handling.md
│ └── examples/
│ ├── service_pattern.ts
│ └── repository_pattern.ts
│
├── best_practices/
│ ├── testing_strategy.md
│ ├── code_quality.md
│ └── performance.md
│
├── architecture/
│ ├── api_design.md
│ ├── database_design.md
│ └── scaling_approach.md
│
├── code_review/
│ ├── feedback_examples.md
│ └── review_checklist.md
│
└── examples/
└── notable_prs/
├── pr_1234_auth_refactor.md
└── pr_5678_performance_fix.md
This skill transforms an engineer's GitHub contributions into a structured, reusable knowledge base. It captures their expertise in a format that:
The goal: Make expertise scalable, learnable, and replicable.
"The best way to learn is from those who have already mastered it."
Weekly Installs
60
Repository
GitHub Stars
103
First Seen
Jan 22, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
claude-code44
opencode42
gemini-cli39
codex39
github-copilot38
cursor35
Caveman-Review:AI代码审查工具,提升PR评论效率与代码质量
7,700 周安装