zhongwei/gh-junjiangao-ccode-plugins-ccode-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:29:56 +08:00
commit c6caa36a85
10 changed files with 2117 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,13 @@
{
"name": "ccode-skills",
"description": "ccode 的skills集合",
"version": "0.0.0-2025.11.28",
"author": {
"name": "junjiangao",
"email": "junjiangao@gmail.com"
},
"skills": [
"./codex-mcp",
"./git-commit"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# ccode-skills
ccode 的skills集合

259
codex-mcp/HANDOFF_CHECKLIST.md Normal file
View File

@@ -0,0 +1,259 @@
# Codex 任务交接检查清单
使用此检查清单确保向 Codex 提供所有必要信息。
## 任务评估
**复杂度**: ⬜ 简单 ⬜ 中等 ⬜ 复杂 ⬜ 非常复杂
**核心逻辑行数**: ________
**主要目标**: ⬜ 算法设计 ⬜ 架构评审 ⬜ 性能优化 ⬜ 代码审查
**紧急度**: ⬜ 低 ⬜ 中等 ⬜ 高 ⬜ 关键
---
## 核心检查清单
### 1. 问题定义 ✓
- [ ] 清晰的问题陈述
- [ ] 定义成功标准
- [ ] 建立范围边界
- [ ] 记录已知限制
### 2. 上下文信息 ✓
- [ ] 提供项目概览
- [ ] 共享相关背景
- [ ] 识别相关系统/组件
- [ ] 提供历史背景
```markdown
**项目**: [名称和用途]
**组件**: [正在处理的部分]
**用户**: [谁使用此功能/规模]
**历史**: [当前实现存在的原因]
```
### 3. 技术约束 ✓
- [ ] 性能要求（延迟、吞吐量）
- [ ] 资源限制（内存、CPU、存储）
- [ ] 兼容性要求（版本、平台）
- [ ] 依赖约束
```markdown
⬜ 时间复杂度: 最大 O(?)
⬜ 空间复杂度: 最大 O(?)
⬜ 延迟目标: __ms
⬜ 吞吐量目标: __req/sec
⬜ 内存限制: __MB/GB
⬜ 平台: [Linux/Windows/macOS/跨平台]
⬜ 语言版本: [例如：Rust 1.70+, Python 3.11+]
```
### 4. 代码上下文 ✓
- [ ] 共享相关现有代码
- [ ] 记录代码风格/约定
- [ ] 提供依赖列表
- [ ] 包含项目结构概览
### 5. 数据上下文 ✓
- [ ] 指定输入数据格式
- [ ] 提供输入大小/规模
- [ ] 定义预期输出格式
- [ ] 识别边界情况
```markdown
**输入**:
- 格式: [JSON/CSV/Binary/其他]
- 大小: [典型和最大]
- 模式: [结构定义]
- 示例: [示例数据]
**输出**:
- 格式: [预期结构]
- 约束: [验证规则]
```
### 6. 测试用例 ✓
- [ ] 提供正常情况（3-5 个示例）
- [ ] 识别边界情况
- [ ] 指定错误情况
- [ ] 性能基准（如果适用）
```markdown
**正常情况**:
1. 输入: [...] → 期望: [...]
2. 输入: [...] → 期望: [...]
**边界情况**:
1. 空输入 → 期望: [...]
2. 单元素 → 期望: [...]
3. 最大大小 → 期望: [...]
**错误情况**:
1. 无效格式 → 期望: [错误处理]
2. 空值 → 期望: [错误处理]
```
### 7. 性能基线 ✓
（适用于优化任务）
- [ ] 当前性能指标
- [ ] 包含分析数据
- [ ] 识别瓶颈
- [ ] 指定目标改进
```markdown
**当前性能**:
- 延迟: p50: __ms, p95: __ms, p99: __ms
- 吞吐量: __ops/sec
- 内存: __MB 峰值
- CPU: __%
**瓶颈** (来自分析):
1. 函数 X: __% 时间
2. 函数 Y: __% 时间
**目标**:
- 延迟减少 __%
- 吞吐量增加到 __ops/sec
```
### 8. 安全考虑 ✓
- [ ] 敏感数据处理要求
- [ ] 认证/授权需求
- [ ] 合规要求（GDPR、HIPAA 等）
- [ ] 已知安全关注点
### 9. 具体问题 ✓
- [ ] 准备至少 2 个具体问题
- [ ] 问题集中且可回答
- [ ] 如果有多个问题则优先排序
### 10. 预期交付物 ✓
- [ ] 明确界定您需要 Codex 做什么
- [ ] 指定格式（伪代码、完整代码、设计文档）
- [ ] 指示详细程度
```markdown
⬜ 高级架构图
⬜ 详细设计文档
⬜ 伪代码/算法
⬜ 实现代码
⬜ 测试用例
⬜ 性能分析
⬜ 权衡比较
⬜ 迁移策略
```
---
## 任务特定检查清单
### 算法设计任务
- [ ] 问题约束形式化
- [ ] 提供输入/输出示例
- [ ] 量化性能要求
- [ ] 定义正确性标准
- [ ] 列举边界情况
### 架构评审任务
- [ ] 包含系统图
- [ ] 记录组件交互
- [ ] 列出当前痛点
- [ ] 指定扩展要求
- [ ] 记录技术栈
### 性能优化任务
- [ ] 附加分析数据
- [ ] 识别瓶颈
- [ ] 提供当前指标
- [ ] 定义目标指标
- [ ] 记录约束
### 代码审查任务
- [ ] 提供完整代码上下文
- [ ] 指定审查关注领域
- [ ] 识别关键路径
- [ ] 列出已知问题
- [ ] 定义审查标准
---
## MCP 工具检查清单
- [ ] MCP 服务器运行并可访问
- [ ] 所需工具可用（验证 `tools/list`）
- [ ] 配置工具权限
- [ ] 审查 inputSchema 要求
- [ ] 了解工具超时限制
- [ ] 准备错误处理策略
- [ ] 记录安全约束
---
## 发送前验证
发送前询问自己：
1. **Codex 能否在不澄清的情况下理解问题？**
- [ ] 是 → 继续
- [ ] 否 → 添加缺失的上下文
2. **约束是否完整且具体？**
- [ ] 是 → 继续
- [ ] 否 → 定义约束
3. **成功能否客观衡量？**
- [ ] 是 → 继续
- [ ] 否 → 添加成功标准
4. **范围对于一次交互是否合理？**
- [ ] 是 → 继续
- [ ] 否 → 拆分为更小的任务
5. **是否包含了示例？**
- [ ] 是 → 继续
- [ ] 否 → 添加示例
---
## 快速模板
### 快速算法请求
```markdown
**问题**: [一行描述]
**输入**: [格式和约束]
**输出**: [预期结果]
**约束**: 时间: O(?), 空间: O(?)
**测试用例**: [一个示例]
```
### 快速性能评审
```markdown
**函数**: [名称]
**当前**: [延迟/吞吐量]
**目标**: [目标]
**分析**: [热点]
**代码**: [实现]
```
### 快速架构问题
```markdown
**系统**: [描述]
**规模**: [当前和目标]
**挑战**: [具体问题]
**问题**: [集中问题]
```
---
## 交接质量评分
**总评分**: ___/25
- **20-25**: 优秀 - 准备交接
- **15-19**: 良好 - 考虑添加更多细节
- **10-14**: 需要改进 - 填补关键空白
- **<10**: 未准备 - 缺少主要信息
---
返回 [SKILL.md](SKILL.md) 获取主要文档。

168
codex-mcp/README.md Normal file
View File

@@ -0,0 +1,168 @@
# Codex MCP Skill
一个通过标准 MCP 工具调用接口，协作 Codex 处理复杂技术任务的 Claude Code 技能。
## 快速入门
### 何时使用
当您遇到以下场景时，此技能会自动激活：
| 场景 | 示例触发词 |
|------|-----------|
| **复杂算法设计** | "设计一个并发数据处理算法..." |
| **性能优化** | "优化这个状态机，p99 延迟需要 < 100ms" |
| **架构评审** | "分析系统架构，支持 10x 扩展" |
| **代码审查** | "审查这段代码的线程安全问题" |
### 核心触发词
- "深度分析"、"复杂逻辑"、"算法设计"
- ">10行核心代码"、"状态机"
- "架构优化"、"性能瓶颈"
### 典型示例
#### 算法设计
```markdown
我需要设计一个限流算法：
- 处理 10K requests/sec
- 每用户限制：100 req/min
- 全局限制：10K req/sec
- 延迟：<1ms 开销
当前滑动窗口方案在大规模下太慢。
推荐什么算法？
```
#### 架构评审
```markdown
请评审我们的微服务架构，从 1K 扩展到 10K req/sec：
当前：API Gateway → 5个服务 → PostgreSQL + Redis
挑战：
- 数据库在 p99 成为瓶颈
- 服务紧耦合
- 缺乏明确的缓存策略
建议哪些改进？
```
#### 代码审查
```markdown
审查这个并发数据处理器，关注：
- 线程安全问题
- 性能瓶颈
- 内存泄漏
- 更好的设计模式
[代码]
担心热路径中的互斥锁使用。
```
## 使用流程
### 1. 描述您的任务
直接用自然语言描述复杂技术问题，包含：
- 问题的背景和上下文
- 具体的约束（性能、规模、安全等）
- 您已经尝试过的方法
### 2. 提供必要信息
确保包含：
- **约束条件**：时间/空间复杂度、性能要求
- **测试用例**：边界情况、预期行为
- **现有代码**：相关实现（如果有）
- **上下文**：使用场景、依赖关系
### 3. 接收 Codex 分析
Claude 会将您的请求格式化并传递给 Codex，Codex 将提供：
- 设计文档或伪代码
- 实现策略和最佳实践
- 测试用例建议
- 性能分析和优化建议
### 4. 验证和实施
使用 [REFERENCE.md](REFERENCE.md) 中的集成指南验证建议：
- 检查逻辑正确性
- 验证性能声明
- 测试与现有代码的兼容性
## 关键特性
### ✅ MCP 工具调用
- **工具名称**：
- 开启会话：`mcp__codex-mcp-tool__codex`
- 继续对话：`mcp__codex-mcp-tool__codex-reply`
- **会话管理**：返回的 `conversationId` 用于后续对话
- **灵活配置**：支持模型选择、沙盒模式、审批策略等参数
- **详细说明**：查看 [SKILL.md](SKILL.md) 获取完整的工具调用示例
### ✅ 协作模板
内置标准模板：
- 标准任务交接
- 算法设计请求
- 架构评审请求
### ✅ 最佳实践指导
- 完整的上下文准备
- 有效的问题提问
- 安全的集成策略
## 文件结构
```
codex-mcp/
├── SKILL.md # 主要技能定义
├── README.md # 快速入门（本文件）
├── REFERENCE.md # 完整参考指南
└── HANDOFF_CHECKLIST.md # 交接检查清单
```
## 成功技巧
### 快速激活
使用明确的触发词：
- "需要深度分析..."
- "设计复杂算法..."
- "审查这段代码..."
- "架构优化建议..."
### 提供上下文
- ✅ 具体约束（"p99 < 100ms"）
- ✅ 现有代码示例
- ✅ 测试用例
- ❌ 模糊描述（"代码很慢"）
### 有效提问
- 问具体问题，避免"怎么优化？"这类宽泛问题
- 提供成功标准（"如何达到 <500ms？"）
- 说明优先级（"准确性 > 性能"）
## 故障排除
**技能未激活？**
- 添加触发词："深度分析"、"算法设计"
- 明确规模：">10 行逻辑"、"复杂状态机"
- 直接说明："我需要 Codex 的帮助..."
**响应不适用？**
- 检查是否传达了所有约束
- 验证上下文假设
- 请求替代方案或澄清
**集成问题？**
- 遵循 REFERENCE.md 中的集成指南
- 先在隔离环境测试
- 准备回滚计划
## 版本历史
- **v2.0** (2025-11-05): 精简重构
- 大幅减少文档冗余
- 明确 MCP 工具调用方法
- 优化使用体验
- **v1.0** (2025-11-05): 初始发布
## 许可证
CCode 技能插件的一部分。

584
codex-mcp/REFERENCE.md Normal file
View File

@@ -0,0 +1,584 @@
# Codex MCP 参考指南
完整的技术参考文档，包含集成指南、协作模式和 MCP 工具规范。
---
## 第一部分：集成指南
### 集成流程
```
接收建议 → 验证逻辑 → 计划集成 → 分阶段实施 → 测试验证 → 监控测量
```
### 阶段 1: 验证
#### 1.1 逻辑验证
检查清单：
- [ ] 算法正确性已验证（手动追踪或证明）
- [ ] 覆盖边界情况
- [ ] 确认复杂度分析
- [ ] 记录所有假设
#### 1.2 兼容性检查
- [ ] 语言版本兼容性
- [ ] 库依赖可用性
- [ ] 平台兼容性（OS、架构）
- [ ] 识别现有代码集成点
- [ ] 评估破坏性变更
兼容性矩阵：
| 方面 | Codex 假设 | 你的环境 | 兼容？ | 所需操作 |
|------|-----------|----------|--------|----------|
| 语言 | Rust 1.75 | Rust 1.70 | ✗ | 升级或适配 |
| 库 | tokio 1.35 | tokio 1.28 | ⚠️ | 测试兼容性 |
| 平台 | Unix | 跨平台 | ✗ | 添加 Windows 支持 |
#### 1.3 性能验证
```rust
#[cfg(test)]
mod codex_validation {
use super::*;
use std::time::Instant;
#[test]
fn validate_codex_performance() {
let input = generate_test_data(10_000);
let start = Instant::now();
let result = codex_suggested_function(&input);
let duration = start.elapsed();
// 验证声称的性能
assert!(duration.as_millis() < 100, "应 <100ms 完成");
assert!(result.is_correct(), "结果必须正确");
}
}
```
### 阶段 2: 集成策略
#### 风险评估
| 风险级别 | 标准 | 缓解策略 |
|----------|------|----------|
| **低** | 非关键代码，易回滚 | 直接实施 |
| **中** | 影响多个组件 | 功能标志 + 分阶段推出 |
| **高** | 关键路径，难回滚 | 影子模式 + 广泛测试 |
| **关键** | 财务/安全影响 | 完全审计 + 渐进迁移 |
#### 策略选择
**直接集成**（低风险）：
```rust
fn old_implementation() -> Result<Output> {
// Codex 的改进实现
new_implementation()
}
```
**并行实现**（中等风险）：
```rust
fn process_data(input: &Input) -> Result<Output> {
if feature_flag_enabled() {
new_implementation(input)
} else {
old_implementation(input)
}
}
```
**影子模式**（高风险）：
```rust
fn process_data(input: &Input) -> Result<Output> {
let result = old_implementation(input);
tokio::spawn(async move {
match new_implementation(input).await {
Ok(shadow_result) => {
if result != shadow_result {
log::warn!("影子实现不同: {:?}", shadow_result);
}
metrics::record_shadow_latency();
}
Err(e) => {
log::error!("影子实现失败: {}", e);
}
}
});
result
}
```
### 阶段 3: 测试策略
**测试金字塔**：
```
┌─────────────┐
│ 手动 │ ← 复杂场景
│ 测试 │
├─────────────┤
│ 集成 │ ← API/组件测试
│ 测试 │
├─────────────┤
│ 单元 │ ← 算法正确性
│ 测试 │
└─────────────┘
```
**必须测试**：
- [ ] 单元测试（所有绿色）
- [ ] 集成测试
- [ ] 性能基准（满足目标）
- [ ] 延迟改进 __%
- [ ] 吞吐量增加 __%
- [ ] 内存使用在限制内
- [ ] 负载测试（30+ 分钟）
- [ ] 错误处理验证
### 阶段 4: 监控
**关键指标**：
```markdown
- **延迟**: p50, p95, p99, max
- **吞吐量**: requests/second
- **错误率**: errors/total requests
- **资源使用**: CPU, memory, disk I/O
```
**警报配置**：
```yaml
alerts:
- name: LatencyIncrease
condition: p99_latency > baseline * 1.5
action: notify_team
- name: ErrorRateSpike
condition: error_rate > baseline * 2
action: auto_rollback
```
---
## 第二部分：协作模式
### 常用模式速查
| 任务类型 | 最佳模式 | 关键成功因素 |
|----------|----------|--------------|
| 新算法 | 迭代优化 | 明确约束 |
| 系统扩展 | 扩展规划 | 当前指标 |
| 性能问题 | 度量-分析-优化 | 分析数据 |
| 代码审查 | 重构提案 | 质量目标 |
| 架构选择 | 权衡矩阵 | 评估标准 |
### 核心模式
#### 1. 迭代优化
**场景**：设计多约束的复杂算法
```markdown
阶段1: "这里是朴素解决方案。请分析其复杂度。"
阶段2: "O(n²) 太慢，建议 O(n log n) 的优化。"
阶段3: "能否将空间复杂度从 O(n) 降至 O(1)？"
```
#### 2. 瓶颈分析
**场景**：系统性能在负载下退化
```markdown
**当前架构**: [图表]
**指标**:
- 95th 百分位延迟: 2s
- CPU 利用率: 80%
- 内存: 4GB/8GB
**问题**: 瓶颈在哪里？如何优化？
```
#### 3. 权衡矩阵
**场景**：存在多种架构选项
```markdown
**选项**:
1. 微服务
2. 模块化单体
3. 事件驱动
**标准**: 性能、可维护性、团队规模、时间线
**问题**: 为我们的约束创建权衡矩阵。
```
### 反模式
❌ **模糊问题陈述**
```markdown
错误: "我的代码很慢。怎么修复？"
正确: "processData() 函数处理 10K 记录需要 5s。
分析显示 80% 时间在嵌套循环中。
目标: <500ms。这是代码..."
```
❌ **缺少上下文**
```markdown
错误: "审查这个函数的 bug。" [仅函数代码]
正确: "审查这个认证函数：
- 用于公共 API
- 处理 1K req/min
- 对安全性至关重要
- 必须使用 JWT 令牌"
```
---
## 第三部分：MCP 工具规范
### Codex MCP 工具
#### 开启 Codex 会话
**工具名称**：`mcp__codex-mcp-tool__codex`
**完整调用示例**：
```json
{
"name": "mcp__codex-mcp-tool__codex",
"parameters": {
"model": "gpt-5.1-codex",
"sandbox": "danger-full-access",
"approval-policy": "on-failure",
"prompt": "<任务描述>",
"cwd": "<可选：工作目录>"
}
}
```
**参数说明**：
- `model`（必需）：模型选择，推荐 `"gpt-5.1-codex"` 或 `"gpt-5.1"`
- `sandbox`（必需）：沙盒模式
- `"read-only"` - 仅读取
- `"workspace-write"` - 可写入工作区
- `"danger-full-access"` - 完全访问
- `approval-policy`（必需）：审批策略
- `"untrusted"` - 无需审批
- `"on-failure"` - 失败时审批
- `"on-request"` - 按需审批
- `"never"` - 从不审批
- `prompt`（必需）：任务描述
- `cwd`（可选）：工作目录路径
**返回值**：
```json
{
"conversationId": "<字符串>",
...
}
```
⚠️ **重要**：保存返回的 `conversationId` 用于后续对话。
#### 继续 Codex 会话
**工具名称**：`mcp__codex-mcp-tool__codex-reply`
**完整调用示例**：
```json
{
"name": "mcp__codex-mcp-tool__codex-reply",
"parameters": {
"conversationId": "<上步返回的 conversationId>",
"prompt": "<补充问题或新指令>"
}
}
```
**参数说明**：
- `conversationId`（必需）：会话标识符
- `prompt`（必需）：新的提示或问题
---
### MCP 标准结构
```json
{
"name": "tool_name",
"description": "此工具的功能和使用时机",
"inputSchema": {
"type": "object",
"properties": {
"param1": {
"type": "string",
"description": "参数描述"
}
},
"required": ["param1"]
}
}
```
### 字段要求
**name**（必需）：
- 格式：snake_case 或 kebab-case
- 在服务器内必须唯一
- 示例：`"analyze_code"`, `"run-benchmark"`
**description**（推荐）：
- 包括：功能、时机、返回值
- 示例：`"在分析指标时使用。执行 SQL 查询。返回 JSON。"`
**inputSchema**（必需）：
- JSON Schema（Draft 7+）
- 必须指定：type、properties、required 字段
### 端点
#### 1. 列出工具 (`tools/list`)
```json
请求: {"method": "tools/list"}
响应:
{
"tools": [
{"name": "tool1", "description": "...", "inputSchema": {...}},
{"name": "tool2", "description": "...", "inputSchema": {...}}
]
}
```
#### 2. 调用工具 (`tools/call`)
```json
请求:
{
"method": "tools/call",
"params": {
"name": "tool_name",
"arguments": {"param1": "value1"}
}
}
响应:
{
"content": [{"type": "text", "text": "结果..."}],
"isError": false
}
```
### 工具类别
#### 代码分析
```json
{
"name": "analyze_code",
"description": "执行静态分析。识别 bug、性能问题、安全漏洞。",
"inputSchema": {
"type": "object",
"properties": {
"code": {"type": "string"},
"language": {"type": "string", "enum": ["rust", "python"]},
"checks": {"type": "array", "items": {"type": "string"}}
},
"required": ["code", "language"]
}
}
```
#### 性能测试
```json
{
"name": "run_benchmark",
"description": "执行性能基准测试。Codex 建议优化时使用。",
"inputSchema": {
"type": "object",
"properties": {
"function_name": {"type": "string"},
"iterations": {"type": "integer", "minimum": 1}
},
"required": ["function_name", "iterations"]
}
}
```
#### 测试执行
```json
{
"name": "run_tests",
"description": "执行测试套件。验证实现时使用。",
"inputSchema": {
"type": "object",
"properties": {
"test_path": {"type": "string"},
"coverage": {"type": "boolean"}
},
"required": ["test_path"]
}
}
```
### 最佳实践
#### 1. 工具发现
当 Codex 推荐工具时：
1. 列出可用工具：`tools/list`
2. 验证工具存在
3. 检查 inputSchema 要求
4. 准备参数
#### 2. 参数准备
**错误**：缺少必需参数
```json
{"name": "analyze_code", "arguments": {"code": "..."}}
```
**正确**：所有必需参数
```json
{
"name": "analyze_code",
"arguments": {
"code": "fn main() {...}",
"language": "rust"
}
}
```
#### 3. 错误处理
```rust
match call_mcp_tool("analyze_code", args) {
Ok(result) => send_to_codex(result),
Err(e) if e.is_invalid_args() => {
let fixed = fix_arguments(args);
call_mcp_tool("analyze_code", fixed)?
}
Err(e) => report_tool_failure(e)
}
```
### 安全与权限
#### 权限配置
在交接中指定允许的工具：
```markdown
## 可用 MCP 工具
**允许**:
- code_analyzer: 是（只读）
- run_benchmark: 是（安全测试）
**不允许**:
- execute_query: 否（不需要数据访问）
- system_command: 否（安全限制）
```
#### 安全约束
```json
{
"tool_constraints": {
"code_analyzer": {
"max_code_size": 10000,
"allowed_languages": ["rust", "python"]
}
}
}
```
---
## 快速参考
### MCP 工具调用检查表
```
□ 工具存在 (tools/list)
□ inputSchema 已审查
□ 必需参数已准备
□ 权限已确认
□ 错误处理已就绪
□ 结果解释计划
```
### 集成检查清单
```
验证:
□ 算法正确性
□ 兼容性
□ 性能声明
规划:
□ 风险评估
□ 集成策略
□ 回滚计划
实施:
□ 功能分支
□ 隔离测试
□ 分阶段集成
□ 文档更新
```
### 常用模板
#### 标准任务交接
```markdown
## 任务给 Codex
**背景**: [项目/系统简要描述]
**目标**: [清晰的目标陈述]
**约束**: [性能/安全/兼容性要求]
**当前状态**: [现有实现或尝试]
### 具体问题:
1. [第一个问题]
2. [第二个问题]
### 期望交付:
- [ ] 设计文档/伪代码
- [ ] 实现策略
- [ ] 测试用例
- [ ] 性能分析
```
#### 算法设计
```markdown
**问题陈述**: [描述问题]
**输入格式**: [数据结构与约束]
**输出要求**: [期望结果格式]
**性能约束**:
- 时间复杂度: O(?)
- 空间复杂度: O(?)
**测试用例**:
1. 输入: [...] → 期望: [...]
2. 边界情况: [...] → 期望: [...]
```
#### 架构评审
```markdown
**系统概览**: [高层描述]
**组件**:
- 组件 A: [用途和交互]
- 组件 B: [用途和交互]
**当前挑战**:
1. [挑战 1]
2. [挑战 2]
**扩展要求**:
- 当前负载: [指标]
- 预期增长: [预测]
**分析问题**:
1. [具体架构关注点]
2. [性能优化机会]
```
---
## 版本信息
**版本**: 2.0 | **更新**: 2025-11-05
合并了以下文档：
- INTEGRATION_GUIDE.md (v1.0)
- CODEX_PATTERNS.md (v1.0)
- MCP_TOOLS_SPEC.md (v1.0)
---
返回 [SKILL.md](SKILL.md) 以获取主要文档。

190
codex-mcp/SKILL.md Normal file
View File

@@ -0,0 +1,190 @@
---
name: codex-mcp
description: 调用 Codex 进行深度分析、复杂逻辑设计和代码审查。使用场景：>10行核心逻辑、架构设计、性能优化、关键代码审查。提供标准的 MCP 工具调用接口和协作模板。
---
# Codex MCP 协作
本技能通过标准 MCP（Model Context Protocol）工具调用接口，协作 Codex 处理复杂技术任务。
## 使用场景
### 触发条件
满足以下任一条件时激活：
- 需要设计或优化 >10 行核心逻辑的算法
- 请求架构评审、性能优化或安全审计
- 涉及数学证明、复杂问题求解
- 描述包含 "深度分析"、"复杂逻辑"、"算法设计"、"架构审查" 等关键词
### 典型应用
```markdown
"设计一个并发数据处理算法处理 1000 events/sec"
"优化这个状态机实现，需要代码审查"
"请分析系统架构，支持从 1K 扩展到 10K req/sec"
```
## MCP 工具调用方法
### 工具初始化
**MCP 工具名称**：`mcp__codex-mcp-tool__codex`
**开启会话**（必须设置固定参数）：
#### 默认模型：gpt-5.1-codex
适用于大多数复杂技术任务和分析工作：
**完整工具调用示例**：
```json
{
"name": "mcp__codex-mcp-tool__codex",
"parameters": {
"model": "gpt-5.1-codex",
"sandbox": "danger-full-access",
"approval-policy": "on-failure",
"prompt": "<需求描述或任务说明>",
"cwd": "<可选：工程路径>"
}
}
```
#### 高级模型：gpt-5.1
适用于特别复杂的任务或特殊指定场景：
**完整工具调用示例**：
```json
{
"name": "mcp__codex-mcp-tool__codex",
"parameters": {
"model": "gpt-5.1",
"sandbox": "danger-full-access",
"approval-policy": "on-failure",
"prompt": "<需求描述或任务说明>",
"cwd": "<可选：工程路径>"
}
}
```
**返回值**：`{ conversationId: "<string>", ... }`
### 工具调用参数
#### 必选参数
- `model`: 模型选择，支持以下选项：
- **"gpt-5.1-codex"**（默认）- 适用于大多数复杂技术任务、算法设计、架构分析
- **"gpt-5.1"** - 适用于特别复杂的任务或用户特殊指定，需要更强的推理能力
- `prompt`: 任务描述，支持中英文
**模型选择指南**：
- 使用 **gpt-5.1-codex**：>90% 的协作场景（默认推荐）
- 使用 **gpt-5.1**：遇到高度复杂的多约束优化、超大规模系统设计、或用户明确指定时
- `sandbox`: 沙盒模式
- `"read-only"` - 仅读取权限
- `"workspace-write"` - 可写入工作区
- `"danger-full-access"` - 完全访问权限
- `approval-policy`: 命令审批策略
- `"untrusted"` - 无需审批
- `"on-failure"` - 失败时审批
- `"on-request"` - 按需审批
- `"never"` - 从不审批
#### 可选参数
- `cwd`: 工作目录
- `base-instructions`: 基础指令
- `compact-prompt`: 紧凑提示模式
- `developer-instructions`: 开发者指令
- `config`: 配置对象覆盖
### 继续对话
**MCP 工具名称**：`mcp__codex-mcp-tool__codex-reply`
**完整工具调用示例**：
```json
{
"name": "mcp__codex-mcp-tool__codex-reply",
"parameters": {
"conversationId": "<上步返回的 conversationId>",
"prompt": "<补充问题或新指令>"
}
}
```
⚠️ **会话管理**：保存返回的 `conversationId`，会话失效时需重新初始化。
## 协作模板
### 标准任务模板
```markdown
## 任务给 Codex
**背景**: [项目/系统简要描述]
**目标**: [清晰的目标陈述]
**约束**: [性能/安全/兼容性要求]
**当前状态**: [现有实现或尝试]
### 具体问题:
1. [第一个问题]
2. [第二个问题]
### 期望交付:
- [ ] 设计文档/伪代码
- [ ] 实现策略
- [ ] 测试用例
- [ ] 性能分析
```
### 算法设计请求
```markdown
## 算法设计
**问题描述**: [问题陈述]
**输入格式**: [数据结构与约束]
**输出要求**: [期望结果格式]
**性能约束**:
- 时间复杂度: O(?)
- 空间复杂度: O(?)
**测试用例**:
1. 输入: [...] → 期望: [...]
2. 边界情况: [...] → 期望: [...]
```
### 架构评审请求
```markdown
## 架构评审
**系统概览**: [高层描述]
**组件**:
- 组件A: [用途和交互]
- 组件B: [用途和交互]
**当前挑战**:
1. [挑战1]
2. [挑战2]
**扩展要求**:
- 当前负载: [指标]
- 预期增长: [预测]
**分析问题**:
1. [具体架构关注点]
2. [性能优化机会]
```
## 最佳实践
### ✅ 推荐做法
- 提供完整的上下文（包括约束和边界情况）
- 共享现有代码模式和约定
- 明确性能要求
- 询问具体、有针对性的问题
- 在实施前验证 Codex 的建议
### ❌ 避免事项
- 假设 Codex 了解你的项目结构
- 跳过测试 Codex 提出的解决方案
- 不理解推理过程就实施
- 忘记检查与现有系统的兼容性
## 参考文档
- [REFERENCE.md](REFERENCE.md) - 完整集成指南、模式速查和 MCP 工具规范
- [HANDOFF_CHECKLIST.md](HANDOFF_CHECKLIST.md) - 任务交接检查清单

196
git-commit/README.md Normal file
View File

@@ -0,0 +1,196 @@
# Git Commit 技能
智能化的 Git 提交助手，帮助你快速完成代码审查、生成规范的提交信息并执行提交。
## 🚀 快速开始
### 基本使用
```
你: "帮我提交这些代码"
```
技能会自动：
1. ✅ 检查暂存区状态
2. 🔍 简单代码审查
3. 📊 分析提交历史
4. 📝 生成提交信息
5. ✋ 等待你确认
6. 🎉 执行提交
### 使用场景
#### 场景 1：暂存区已有文件
```bash
# 你已经执行了 git add
git add src/main.rs src/config.rs
# 直接请求提交
你: "提交代码"
```
技能会直接使用暂存区的文件进行提交。
#### 场景 2：暂存区为空
```
你: "提交我的修改"
```
技能会：
1. 列出所有修改的文件
2. 询问你要提交哪些文件
3. 自动执行 `git add`
4. 继续提交流程
#### 场景 3：审查并提交
```
你: "审查代码并提交"
```
技能会进行简单的代码审查，检查：
- 语法错误
- 调试代码残留
- 敏感信息泄露
## 📝 提交信息格式
### 自动识别项目规范
技能会从以下来源识别项目的提交规范：
1. **Memory 中的项目规范**（优先级最高）
2. **提交历史中的风格模式**
3. **通用简洁格式**（默认）
### 配置项目规范
如果你的项目有特定的提交规范，可以在 Memory 中记录：
```
你: "记录项目提交规范：使用 Conventional Commits 格式，type 包括 feat、fix、docs、refactor、test、chore"
```
技能会自动保存到 Memory，后续提交时遵循该规范。
## 🎯 典型工作流
### 完整示例
```
你: "提交代码"
技能:
📊 检查到暂存区为空，发现以下修改：
1. src/main.rs (修改)
2. src/config.rs (修改)
3. tests/test_config.rs (新增)
4. README.md (修改)
请选择要提交的文件：
[ ] 提交所有文件
[ ] 选择特定文件
[ ] 取消
你: "提交所有文件"
技能:
✅ 已添加 4 个文件到暂存区
🔍 代码审查中...
✅ 未发现明显问题
📊 变更摘要：
- 修改文件：4 个
- 新增行：+127
- 删除行：-23
📝 提交信息：
feat(config): 添加 TOML 配置支持
- 实现 TOML 配置读取
- 添加配置文件解析
- 更新测试用例
- 完善文档说明
是否确认提交？
你: "确认"
技能:
✅ 提交成功！
commit: a1b2c3d feat(config): 添加 TOML 配置支持
```
## ⚙️ 高级功能
### 历史分析
技能会分析最近 20 条提交记录，学习项目的提交风格：
- 常用的 type 类型
- scope 的命名习惯
- 提交信息的语言（中文/英文）
- 描述的详细程度
### 智能暂存区处理
- **暂存区非空**：直接使用，快速提交
- **暂存区为空**：智能询问，避免误操作
### 提交前确认
每次提交前都会展示：
- 变更文件列表和统计
- 生成的提交信息
- 代码审查结果
你可以：
- 确认提交
- 修改提交信息
- 取消提交
## 🛠️ 配置示例
### Conventional Commits 规范
```
你: "配置提交规范"
技能: "请描述你的提交规范"
你: "使用 Conventional Commits：
- type: feat, fix, docs, refactor, test, chore
- 格式: type(scope): subject
- subject 使用中文
- 可选的详细正文"
技能: "✅ 已保存到项目 Memory"
```
### 自定义规范
```
你: "我们团队的提交格式是：[模块名] 简短描述"
技能: "✅ 已记录，后续提交将遵循该格式"
```
## 💡 最佳实践
### ✅ 推荐做法
1. **原子提交**：每次只提交一个逻辑变更
2. **及时提交**：完成功能点后立即提交
3. **清晰描述**：让他人快速理解变更目的
4. **遵循规范**：保持项目风格一致
### ❌ 避免事项
1. **混合变更**：不要在一次提交中包含多个不相关修改
2. **模糊描述**：避免 "update code"、"fix bug" 等无意义信息
3. **跳过审查**：即使小改动也应快速检查
4. **提交敏感信息**：检查是否包含密钥、令牌
## 🔗 相关资源
- 详细工作流程：查看 `SKILL.md`
- 提交规范参考：查看 `REFERENCE.md`
- [Conventional Commits 规范](https://www.conventionalcommits.org/)

321
git-commit/REFERENCE.md Normal file
View File

@@ -0,0 +1,321 @@
# Git Commit 规范参考
本文档提供常见的提交信息规范、Memory 配置模板和常见问题解答。
## 📋 提交信息规范
### Conventional Commits
最流行的提交信息规范，广泛应用于开源项目。
#### 格式
```
<type>(<scope>): <subject>
<body>
<footer>
```
#### Type 类型
| Type | 说明 | 示例 |
|------|------|------|
| `feat` | 新功能 | feat(auth): 添加用户登录功能 |
| `fix` | 修复 bug | fix(api): 修复用户查询接口错误 |
| `docs` | 文档更新 | docs(readme): 更新安装说明 |
| `style` | 代码格式（不影响功能） | style(main): 统一代码缩进 |
| `refactor` | 重构（不改变功能） | refactor(config): 简化配置加载逻辑 |
| `perf` | 性能优化 | perf(query): 优化数据库查询性能 |
| `test` | 测试相关 | test(user): 添加用户模块单元测试 |
| `build` | 构建系统或依赖 | build(deps): 升级 tokio 到 1.35 |
| `ci` | CI 配置 | ci(github): 添加自动发布工作流 |
| `chore` | 其他杂项 | chore(release): 发布 v1.2.0 |
| `revert` | 回滚提交 | revert: 回滚 feat(auth) 提交 |
#### Scope（可选）
表示影响的模块或范围：
- `api` - API 接口
- `config` - 配置系统
- `cli` - 命令行界面
- `core` - 核心逻辑
- `docs` - 文档
- `test` - 测试
#### Subject
- 使用祈使句，现在时态："添加"而非"添加了"
- 首字母小写
- 结尾不加句号
- 简洁明了，不超过 50 字符
#### Body（可选）
- 详细说明变更的原因和影响
- 每行不超过 72 字符
- 可以包含多个段落
#### Footer（可选）
- Breaking Changes：`BREAKING CHANGE: 描述`
- 关闭 Issue：`Closes #123, #456`
- 引用相关 PR：`Refs #789`
#### 完整示例
```
feat(config): 添加 TOML 配置支持
实现了基于 TOML 格式的配置文件读取功能，替代原有的 JSON 格式。
主要改进：
- 更友好的配置语法
- 支持注释
- 更好的类型安全
BREAKING CHANGE: 配置文件格式从 JSON 改为 TOML
Closes #42
```
### Angular 规范
Angular 团队使用的提交规范，与 Conventional Commits 类似。
#### 格式
```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```
#### Type 类型
- `feat`: 新功能
- `fix`: 修复
- `docs`: 文档
- `style`: 格式
- `refactor`: 重构
- `test`: 测试
- `chore`: 构建/工具
#### 示例
```
fix(compiler): 修复模板解析错误
当模板包含特殊字符时，解析器会抛出异常。
现在正确处理所有 Unicode 字符。
Fixes #1234
```
### 简洁描述格式
适合小型项目或个人项目的简单格式。
#### 格式
```
简短描述（不超过 50 字符）
可选的详细说明
```
#### 示例
```
添加用户认证功能
实现了基于 JWT 的用户认证系统
```
### Gitmoji 规范
使用 emoji 表示提交类型，视觉化更强。
#### 常用 Emoji
| Emoji | 代码 | 说明 |
|-------|------|------|
| ✨ | `:sparkles:` | 新功能 |
| 🐛 | `:bug:` | 修复 bug |
| 📝 | `:memo:` | 文档 |
| 🎨 | `:art:` | 代码格式/结构 |
| ⚡️ | `:zap:` | 性能优化 |
| 🔥 | `:fire:` | 删除代码/文件 |
| ✅ | `:white_check_mark:` | 测试 |
| 🔒 | `:lock:` | 安全修复 |
| ⬆️ | `:arrow_up:` | 升级依赖 |
| ⬇️ | `:arrow_down:` | 降级依赖 |
#### 示例
```
✨ 添加用户登录功能
🐛 修复配置文件解析错误
📝 更新 API 文档
```
## 🔧 Memory 配置模板
### Conventional Commits 配置
```json
{
"name": "mcp__memory__create_entities",
"parameters": {
"entities": [{
"name": "project:ccode:commit-convention",
"entityType": "convention",
"observations": [
"使用 Conventional Commits 格式",
"格式：<type>(<scope>): <subject>",
"type 包括：feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert",
"scope 为可选，表示影响的模块",
"subject 使用中文，祈使句，首字母小写",
"body 可选，详细说明变更原因",
"footer 可选，包含 BREAKING CHANGE 或关闭的 Issue"
]
}]
}
}
```
### 自定义规范配置
```json
{
"name": "mcp__memory__create_entities",
"parameters": {
"entities": [{
"name": "project:myproject:commit-convention",
"entityType": "convention",
"observations": [
"格式：[模块名] 简短描述",
"模块名使用大写，如：[API]、[UI]、[DB]",
"描述使用中文，简洁明了",
"示例：[API] 添加用户查询接口"
]
}]
}
}
```
### 团队规范配置
```json
{
"name": "mcp__memory__create_entities",
"parameters": {
"entities": [{
"name": "project:teamproject:commit-convention",
"entityType": "convention",
"observations": [
"使用 Jira 工单号开头",
"格式：[PROJ-123] 描述",
"描述使用英文，动词开头",
"示例：[PROJ-123] Add user authentication",
"必须关联 Jira 工单"
]
}]
}
}
```
## ❓ 常见问题
### Q1: 如何修改已生成的提交信息？
**A**: 在技能展示提交信息并询问确认时，你可以：
```
你: "修改提交信息为：fix(api): 修复用户查询接口超时问题"
```
技能会使用你提供的信息进行提交。
### Q2: 如何跳过代码审查？
**A**: 技能默认进行简单审查。如果你确定代码没问题，可以：
```
你: "跳过审查，直接提交"
```
### Q3: 如何提交部分文件？
**A**: 当暂存区为空时，技能会询问你选择文件。你也可以提前使用 `git add`：
```bash
git add src/main.rs src/config.rs
```
然后请求提交，技能会只提交这些文件。
### Q4: 提交信息太长怎么办？
**A**: 技能会自动将详细内容放到 body 部分：
```
feat(config): 添加 TOML 配置支持
- 实现 TOML 配置读取
- 添加 .env 文件支持
- 更新配置迁移逻辑
- 完善测试用例
```
### Q5: 如何处理 Breaking Changes？
**A**: 在 Memory 配置中说明，技能会识别重大变更并添加 footer：
```
feat(api): 重构用户认证接口
BREAKING CHANGE: 认证接口从 /auth 改为 /api/v2/auth
```
### Q6: 提交失败怎么办？
**A**: 技能会显示错误信息。常见原因：
- pre-commit hook 失败 → 修复代码质量问题
- 提交信息格式不符 → 检查项目的 commitlint 配置
- Git 配置问题 → 检查 user.name 和 user.email
### Q7: 如何查看提交历史？
**A**: 技能会自动分析最近 20 条提交。你也可以手动查看：
```bash
git log --oneline -20
```
### Q8: 支持多语言提交信息吗？
**A**: 支持。技能会根据项目历史识别语言习惯：
- 中文项目 → 生成中文提交信息
- 英文项目 → 生成英文提交信息
- 混合项目 → 遵循 Memory 中的配置
### Q9: 如何更新项目规范？
**A**: 使用 Memory 工具更新：
```
你: "更新提交规范：subject 改用英文"
```
技能会更新 Memory 中的配置。
### Q10: 提交后发现错误怎么办？
**A**: 可以使用 `git commit --amend` 修改最后一次提交：
```bash
# 修改文件
git add .
git commit --amend
```
或者创建新的修复提交：
```
你: "提交修复"
```
## 📚 参考资源
### 官方文档
- [Conventional Commits](https://www.conventionalcommits.org/)
- [Angular Commit Guidelines](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)
- [Gitmoji](https://gitmoji.dev/)
### 工具推荐
- [commitlint](https://commitlint.js.org/) - 提交信息校验
- [husky](https://typicode.github.io/husky/) - Git hooks 管理
- [commitizen](https://commitizen-tools.github.io/commitizen/) - 交互式提交
### 最佳实践
- [How to Write a Git Commit Message](https://cbea.ms/git-commit/)
- [Git Commit Best Practices](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project)
- [Semantic Versioning](https://semver.org/)

314
git-commit/SKILL.md Normal file
View File

@@ -0,0 +1,314 @@
---
name: git-commit
description: 智能 Git 提交助手：审查代码变更、分析提交历史、生成符合项目规范的提交信息并执行提交。支持自定义规范、提交前确认和智能暂存区处理。
---
# Git Commit 技能
智能化的 Git 提交工作流，集成代码审查、历史分析和规范化提交信息生成。
## 🎯 使用场景
### 触发条件
- 用户明确请求创建 Git 提交
- 关键词：`提交`、`commit`、`git commit`、`提交代码`
- 用户完成代码修改后需要提交变更
### 典型示例
```
用户: "帮我提交这些代码"
用户: "审查并提交当前的修改"
用户: "创建一个 commit"
用户: "把这些改动提交到 git"
```
## 📋 工作流程
### 1. 检查暂存区状态
```bash
# 检查暂存区
git status --porcelain
git diff --cached --stat
# 如果暂存区为空，列出工作区文件
git status --short
git diff --name-status
```
**决策逻辑**：
- **暂存区非空** → 直接使用暂存区文件
- **暂存区为空** → 列出工作区修改文件，询问用户确认提交范围
### 2. 用户确认（暂存区为空时）
**列出工作区文件**：
```bash
# 获取所有修改、新增、删除的文件
git status --short
# 输出格式：
# M src/main.rs (修改)
# A src/config.rs (新增)
# D old/legacy.rs (删除)
# ?? untracked.txt (未跟踪)
```
使用 `AskUserQuestion` 工具询问：
- 提交所有修改的文件？
- 提交特定文件？（展示上述文件清单供选择）
- 取消提交？
根据用户选择执行 `git add` 操作。
### 3. 简单代码审查
检查项：
- 语法错误（通过 `cargo check`、`npm run lint` 等）
- 明显的逻辑问题
- 调试代码残留（console.log、println!、TODO 等）
- 敏感信息泄露（密钥、令牌、凭证）
**不执行深度审查**（不调用 Codex MCP），保持快速反馈。
### 4. 分析提交历史
```bash
git log --oneline -10
git log --format="%s" -20
```
**分析目标**：
- 识别项目的提交信息风格
- 提取常用的 type 和 scope
- 保持提交风格一致性
### 5. 读取项目提交规范
从 Memory 中查找项目级提交规范：
```
# 使用项目级精确查询，避免跨项目污染
mcp__memory__search_nodes(query: "project:<repo>:commit-convention")
mcp__memory__open_nodes(names: ["project:<repo>:commit-convention"])
```
**命名空间说明**：
- `<repo>` 应替换为实际的仓库名称（如 `ccode`、`myproject`）
- 使用 `project:` 前缀确保查询范围限定在当前项目
- 避免使用模糊查询（如 `"commit convention"`），防止匹配到其他项目的规范
**规范来源优先级**：
1. Memory 中的项目规范
2. 提交历史中的风格模式
3. 通用的简洁描述格式
### 6. 生成提交信息
使用 `mcp__sequential-thinking__sequentialthinking` 分析变更并生成提交信息：
**思考步骤**（6-8 步）：
1. 分析 `git diff --cached` 的变更内容
2. 识别变更的主要目的（新功能、修复、重构等）
3. 提取关键的文件和模块
4. 匹配项目提交规范格式
5. 生成简洁准确的提交信息
6. 验证提交信息是否符合规范
**提交信息格式**（根据项目规范）：
- 自定义规范：遵循 Memory 中的定义
- 无规范时：`<type>: <简洁描述>`
### 7. 展示变更摘要和提交信息
向用户展示：
```
📊 变更摘要：
- 修改文件：3 个
- 新增行：+45
- 删除行：-12
📝 提交信息：
feat(config): 添加 TOML 配置支持
- 实现 TOML 配置读取
- 添加 .env 文件支持
- 更新配置迁移逻辑
✅ 代码审查：通过（无明显问题）
是否确认提交？
```
### 8. 执行提交
用户确认后执行：
```bash
git commit -m "$(cat <<'EOF'
<提交信息>
EOF
)"
```
验证提交成功：
```bash
git log -1 --oneline
```
## 🔧 MCP 工具调用
### Memory 工具
```json
{
"name": "mcp__memory__search_nodes",
"parameters": {
"query": "project:<repo>:commit-convention"
}
}
```
```json
{
"name": "mcp__memory__open_nodes",
"parameters": {
"names": ["project:<repo>:commit-convention"]
}
}
```
**注意**：`<repo>` 应替换为实际仓库名，如 `project:ccode:commit-convention`
### Sequential Thinking 工具
```json
{
"name": "mcp__sequential-thinking__sequentialthinking",
"parameters": {
"thought": "分析 git diff 变更内容...",
"thoughtNumber": 1,
"totalThoughts": 6,
"nextThoughtNeeded": true
}
}
```
## 📝 协作模板
### 标准提交流程
```markdown
1. 检查暂存区状态（git status --porcelain, git diff --cached --stat）
2. 如果暂存区为空：
- 使用 git status --short 列出所有工作区修改文件
- 询问用户选择提交范围（全部/特定文件/取消）
- 根据选择执行 git add
3. 简单代码审查（语法、明显问题）
4. 分析最近 20 条提交历史（git log --format="%s" -20）
5. 从 Memory 读取项目提交规范（使用 project:<repo>:commit-convention 精确查询）
6. 使用 Sequential Thinking 生成提交信息
7. 展示变更摘要和提交信息
8. 等待用户确认
9. 执行 git commit
10. 验证提交成功（git log -1 --oneline）
```
### 提交信息生成模板
```markdown
根据以下信息生成提交信息：
**变更内容**：
<git diff --cached 输出>
**项目规范**：
<Memory 中的规范或历史风格>
**要求**：
- 简洁准确，一行概括主要变更
- 如有多个变更，在正文中分点说明
- 遵循项目规范格式
- 避免技术细节，关注变更目的
```
## ⚙️ 配置项目提交规范
### 在 Memory 中记录规范
```json
{
"name": "mcp__memory__create_entities",
"parameters": {
"entities": [{
"name": "project:<repo>:commit-convention",
"entityType": "convention",
"observations": [
"使用 Conventional Commits 格式：<type>(<scope>): <subject>",
"常用 type：feat, fix, docs, refactor, test, chore",
"scope 为可选，表示影响的模块",
"subject 使用中文，简洁描述变更",
"正文可选，详细说明变更原因和影响"
]
}]
}
}
```
**命名规范**：
- 实体名称格式：`project:<repo>:commit-convention`
- `<repo>` 替换为实际仓库名（如 `ccode`、`myproject`）
- 使用 kebab-case 命名风格
- 确保命名空间隔离，避免跨项目污染
### 示例规范
```
type(scope): subject
body (可选)
footer (可选)
```
**type 类型**：
- `feat`: 新功能
- `fix`: 修复 bug
- `docs`: 文档更新
- `refactor`: 重构
- `test`: 测试相关
- `chore`: 构建/工具/依赖更新
## ✅ 最佳实践
### 推荐做法
1. **提交前审查**：始终检查 `git diff` 确认变更内容
2. **原子提交**：每次提交只包含一个逻辑变更
3. **清晰描述**：提交信息应让他人快速理解变更目的
4. **遵循规范**：保持项目提交风格一致
5. **及时提交**：完成一个功能点后立即提交
### 避免事项
1. **混合变更**：不要在一次提交中包含多个不相关的修改
2. **模糊描述**：避免 "update code"、"fix bug" 等无意义信息
3. **提交敏感信息**：检查是否包含密钥、令牌等
4. **跳过审查**：即使是小改动也应快速检查
5. **忽略规范**：不要随意偏离项目约定的格式
## 🚨 错误处理
### 暂存区为空且用户取消
```
暂存区为空，需要先添加文件。
已取消提交操作。
```
### 代码审查发现问题
```
⚠️ 代码审查发现以下问题：
- src/main.rs:42: 包含 println! 调试代码
- config/.env: 可能包含敏感信息
建议修复后再提交。是否继续？
```
### 提交失败
```
❌ 提交失败：<错误信息>
可能原因：
- pre-commit hook 失败
- 提交信息格式不符合要求
- Git 配置问题
请检查错误信息并重试。
```
## 📚 相关资源
- [Conventional Commits 规范](https://www.conventionalcommits.org/)
- [Git 提交最佳实践](https://git-scm.com/book/zh/v2)
- [如何编写 Git 提交信息](https://cbea.ms/git-commit/)

69
plugin.lock.json Normal file
View File

@@ -0,0 +1,69 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:junjiangao/ccode:plugins/ccode-skills",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "dbc1423b6f9dbf8437970dd02bbd686d3a5a0b1b",
"treeHash": "a2afb7c1ad99dbe763d9ce9509c5ce701de5d7dbcbee678a6742d37760bfce2e",
"generatedAt": "2025-11-28T10:19:22.507235Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "ccode-skills",
"description": "ccode 的skills集合",
"version": null
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "5877162d4686156ee5819eb16da41aac407a63e73672f205d8a4cb5087dc779b"
},
{
"path": "git-commit/REFERENCE.md",
"sha256": "70bc258e0d109f98a679b52eb6936af818e619b47dab2114681a6aa327e1f08e"
},
{
"path": "git-commit/README.md",
"sha256": "35dee92d6442a442bcf44da722e61a37b1282732db6666b2d1c71191360f2999"
},
{
"path": "git-commit/SKILL.md",
"sha256": "c0f2132f566749bc8585fa3ceeb34ef67896f06e7399e102192c9d5f731f6e62"
},
{
"path": "codex-mcp/REFERENCE.md",
"sha256": "3f13cb94aef0cd9ce718dd629a5df16766b764270d57c5583a14e1299a553a82"
},
{
"path": "codex-mcp/HANDOFF_CHECKLIST.md",
"sha256": "5ad241dc4aa345e8287b63726c7c9e3c04f57eca08f0d48295bc1ca6aa0e612b"
},
{
"path": "codex-mcp/README.md",
"sha256": "36fb9ed56a9ac544221768bff292a60a622f02ce432ead64e0b6f56316eed521"
},
{
"path": "codex-mcp/SKILL.md",
"sha256": "a37f3242acde2eee9ccacb2798e0b3f880068edd8f6618e450e41578b16e1e9c"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "945054765975e3b80a84c3dfb7ac4928ffc4f7eedb3fa908a9ba83345133a6a6"
}
],
"dirSha256": "a2afb7c1ad99dbe763d9ce9509c5ce701de5d7dbcbee678a6742d37760bfce2e"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}