# Super Code

> 常驻编程风格规范，在所有编码任务中强制执行紧凑、正确、惯用的代码。最小化代码膨胀和智能体操作开销。

- Skill: `kscz0000/super-code` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kscz0000/super-code`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/super-code/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/super-code

---


# Super Code Skill

## 概述

产出短小、正确、惯用且可维护的代码——按此优先级排序。
本技能解决两种必须独立修复的低效问题：

1. **代码 token 低效** — 产出物本身臃肿（多余的行、样板代码、过度抽象）
2. **生成 token 低效** — 智能体在会话中的操作方式（全文件重写、未经请求的文件、代码变更前后的冗余说明）

两者都很重要。只修其中一个是不够的。

## 何时使用本技能

- 在 IDE 中的每个编码任务上自动应用本技能。
- 当用户要求用任何语言编写、编辑、重构、生成或审查代码时使用。
- 这是常驻编程风格规范，而非按需启用——始终应用。

---

## 优先级顺序（不得违反此排序）

```
正确性 → 可读性 → 必要的健壮性 → 简洁性 → 微性能
```

简洁性**绝不**优先于正确性或可读性。如果某次压缩会丢弃实际可能发生的错误处理，或产出让人类六个月后无法阅读的代码，就撤销该压缩。短而错误的代码比长而正确的代码更糟。

---

## 工作流——应用于每个编码任务

### 步骤 1：在动手之前确定最小正确形态

在接触文件之前，先决定：
- 正确解决此问题的最小表面积是什么？
- 调用方实际需要从这个函数/类/模块获得什么？
- 是否已有标准库/框架原生功能做到了这一点？

在脑中记下（不要以文字块形式输出给用户）。这就是目标形态。

### 步骤 2：使用语言惯用模式编写

阅读所用语言的相关参考文件：
- Bash/Shell → `bash/SKILL.md`
- C → `c/SKILL.md`
- C++ → `cpp/SKILL.md`
- C# → `csharp/SKILL.md`
- Dart/Flutter → `dart/SKILL.md`
- Elixir/Erlang → `elixir/SKILL.md`
- Go → `go/SKILL.md`
- Java → `java/SKILL.md`
- Kotlin/Compose → `kotlin/SKILL.md`
- PHP → `php/SKILL.md`
- Python → `python/SKILL.md`
- Ruby → `ruby/SKILL.md`
- Rust → `rust/SKILL.md`
- Scala → `scala/SKILL.md`
- Swift → `swift/SKILL.md`
- TypeScript/JavaScript → `typescript/SKILL.md`

应用该文件中的惯用模式。它们用正确、紧凑且仍可读的等价写法替代冗长的命令式代码。

### 步骤 3：对自己的草稿做压缩检查

在展示任何代码之前，扫描以下内容：

| 反模式 | 修复方式 |
|---|---|
| 注释复述了代码做的事 | 删除注释，或改写为说明*为什么* |
| 只用一次的辅助函数/类 | 内联它 |
| 标准库/框架已有此功能 | 替换为原生功能 |
| 对不可能发生的情况做防御性处理 | 删除 |
| 冗长循环可用惯用表达式替代 | 替换 |
| 没人要求的日志/print | 删除 |
| 未请求的额外配置/文件/参数 | 删除 |
| 未使用的 import 或变量 | 删除 |

### 步骤 4：护栏检查——展示前运行此检查

自问（静默地）：
- [ ] 我是否移除了对**实际可能发生**的情况的处理？
- [ ] 我是否让人类六个月后更难阅读？
- [ ] 我是否为了省行数而牺牲了正确性或安全性？

如果任一项为是：撤销该特定压缩，保留其余。

### 步骤 5：展示输出——生成 token 规则

**始终：**
- 通过针对性补丁/差异编辑文件，而非全文件重写，除非文件是新的或变更涉及 >70% 的行
- 只展示被请求的内容

**绝不：**
- 生成未经请求的文件（测试、README、配置、类型），除非用户要求
- 在代码前后添加文字块解释你即将做什么或刚做了什么——直接做
- 向用户重述其自身需求后再编写
- 在展示差异后用段落复述变更了什么——差异本身已不言自明

---

## 通用反模式清单

以下适用于每种语言。语言特定文件会扩展此列表。

### 注释
- ❌ `// Loop through the list and add each item` → ❌ 删除
- ✅ `// Order matters: process refunds before charges` → ✅ 保留（说明了*为什么*）
- 规则：如果注释可以通过阅读代码机械地生成，它就不增加价值

### 防御性编码
- 只处理在调用点实际可能发生的错误情况
- 如果调用方保证非空，函数内就不要做空值检查
- 如果 catch 块只能日志记录并重新抛出，考虑移除 try/catch

### 抽象
- 不要为仅在一处使用一次的逻辑提取函数
- 不要为仅使用一次的原始类型创建包装类
- 阈值：抽象在被使用 2 次以上时，或拥有真正阐明领域逻辑的有意义名称时，才算物有所值

### 脚手架
- 除非用户要求搭建骨架，否则不留占位 TODO
- 不写 `// TODO: add error handling`——要么加上，要么不加
- 不留"以防万一"的空 catch 块
- 不加当前调用方不使用的参数

---

## 生成 Token 规则（智能体 IDE 特定）

这些规定你在会话内的操作方式，不只是产出物：

### 文件编辑
- 优先精准补丁：只展示变更行 + 最少上下文
- 全文件重写仅适用于：新文件、少于 ~30 行的文件、或变更涉及 >70% 行的文件
- 永远不要为了"展示完整上下文"而重复文件的未变更部分

### 未经请求的产出物
- 不要创建测试文件、README 更新、类型定义文件、配置文件或 CI 脚本，除非明确请求
- 如果你认为测试文件有价值，在主要输出后用一句话提议——不要未经请求就生成

### 文字开销
- 不要"这是我即将做的："前导语
- 不要"我做了以下变更："后缀语（差异已经展示了）
- 不要"如果你需要我……"收尾语
- 如果需求确实有歧义，一行澄清是可以接受的；否则，做出合理选择并在代码内以注释标注假设（如果重要的话）

---

## 语言参考文件

| 语言 / 技术栈 | 文件 |
|---|---|
| Bash / Shell | `bash/SKILL.md` |
| C | `c/SKILL.md` |
| C++ | `cpp/SKILL.md` |
| C# / .NET | `csharp/SKILL.md` |
| Dart / Flutter | `dart/SKILL.md` |
| Elixir / Erlang | `elixir/SKILL.md` |
| Go | `go/SKILL.md` |
| Java | `java/SKILL.md` |
| Kotlin + Compose (Android) | `kotlin/SKILL.md` |
| PHP | `php/SKILL.md` |
| Python | `python/SKILL.md` |
| Ruby | `ruby/SKILL.md` |
| Rust | `rust/SKILL.md` |
| Scala | `scala/SKILL.md` |
| Swift (iOS/macOS) | `swift/SKILL.md` |
| TypeScript / JavaScript | `typescript/SKILL.md` |

在步骤 2 中阅读相关文件。如果语言未列出，应用上述通用清单并使用该语言自身的惯用写法处理循环、错误处理和数据转换。

## 示例

### 示例 1：重构冗长的循环
```java
// Anti-pattern
List<String> names = new ArrayList<>();
for (User u : users) {
    if (u.isActive()) {
        names.add(u.getName());
    }
}
// Super-code idiomatic (Java)
List<String> names = users.stream().filter(User::isActive).map(User::getName).toList();
```

## 故障排除

### 问题：代码过于紧凑难以阅读
**症状：** 审查者抱怨或逻辑不可读。
**解决方案：** 回退过度压缩的部分。可读性和正确性始终优先于简洁性。

## 相关技能

- `@karpathy-guidelines` - 关于精准变更和简洁性的行为准则。

## 局限性

- **语言支持：** 语言特定惯用写法需要参考文件。
- **可读性权衡：** 极端压缩如果不注意，有时会损害可读性。