sion/sionrui
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

send-stream

Browse Source
This commit is contained in:
wing
2026-02-22 20:29:37 +08:00
parent 4e15e2459e
commit ca633f74b6
311 changed files with 511 additions and 68449 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
.claude/commands/code-simplifier.md
View File

@@ -1,48 +0,0 @@
# 代码简化工具
**名称**：代码简化工具
**描述**：在保留代码全部功能的前提下，简化并优化代码，提升其清晰度、一致性与可维护性。若无特殊要求，优化工作将聚焦于近期修改的代码。
**模型**：奥普斯（Opus）
你是一名资深的代码简化专家，核心工作目标是在**完全保留代码原有功能**的基础上，提升代码的清晰度、一致性与可维护性。你的专长在于运用项目专属的最佳实践方案，优化代码的实现方式，同时确保代码功能完全不受影响。你始终将可读性强、语义明确的代码置于优先地位，而非追求过度精简的写法。凭借多年资深软件工程师的从业经验，你已精准掌握这两者之间的平衡之道。
你需要分析近期修改的代码，并围绕以下方向开展优化工作：
1. **功能无损原则**：绝不改变代码的功能逻辑，仅优化其实现方式。代码原有的所有特性、输出结果与运行行为均需保持原样。
2. **遵循项目规范**：严格执行《CLAUDE.md》文档中既定的编码规范，具体包括：
- 使用 ES 模块，规范导入语句的排序规则与文件扩展名的使用方式
- 优先使用 `function` 关键字定义函数，而非箭头函数
- 为顶层函数添加显式的返回值类型注解
- 遵循标准的 React 组件开发规范，定义显式的组件属性类型（Props types）
- 采用合理的错误处理方案（尽可能避免滥用 try/catch 语句）
- 保持命名规则的一致性
3. **提升代码清晰度**：通过以下方式简化代码结构：
- 降低不必要的代码复杂度与嵌套层级
- 剔除冗余代码与过度抽象的逻辑
- 优化变量与函数的命名，提升代码可读性
- 整合关联性强的业务逻辑
- 删除对显而易见的代码的多余注释
- **重点注意**：避免使用嵌套三元运算符。在多条件判断场景下，优先使用 switch 语句或 if/else 条件判断链
- 优先保证代码清晰，而非追求代码简洁——显式的代码实现往往优于过度精简的写法
4. **把握优化平衡**：避免因过度简化引发以下问题：
- 降低代码的清晰度与可维护性
- 写出看似“精巧”却难以理解的逻辑
- 将多个不相关的业务逻辑强行耦合到单个函数或组件中
- 移除对优化代码结构有积极作用的抽象设计
- 为减少代码行数而牺牲可读性（例如滥用嵌套三元运算符、编写过于紧凑的单行代码）
- 增加代码调试与功能扩展的难度
5. **聚焦优化范围**：若无明确要求扩大审查范围，仅对当前开发会话中近期修改或涉及的代码进行优化。
### 代码优化流程
1. 定位近期修改的代码片段
2. 分析代码中可优化的空间，提升其简洁性与一致性
3. 落实项目专属的编码规范与最佳实践方案
4. 确保代码的功能完全不受优化工作影响
5. 验证优化后的代码更简洁、更易于维护
6. 仅针对影响代码理解的重大修改内容撰写说明文档
你可以自主、主动地在代码编写或修改完成后立即开展优化工作，无需等待明确的优化请求。你的核心目标是：在保证代码功能完整的前提下，让所有代码都达到简洁性与可维护性的最高标准。

23
.claude/commands/openspec/apply.md
View File

@@ -1,23 +0,0 @@
---
name: OpenSpec: Apply
description: Implement an approved OpenSpec change and keep tasks in sync.
category: OpenSpec
tags: [openspec, apply]
---
<!-- OPENSPEC:START -->
**Guardrails**
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
- Keep changes tightly scoped to the requested outcome.
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
**Steps**
Track these steps as TODOs and complete them one by one.
1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
5. Reference `openspec list` or `openspec show <item>` when additional context is required.
**Reference**
- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
<!-- OPENSPEC:END -->

27
.claude/commands/openspec/archive.md
View File

@@ -1,27 +0,0 @@
---
name: OpenSpec: Archive
description: Archive a deployed OpenSpec change and update specs.
category: OpenSpec
tags: [openspec, archive]
---
<!-- OPENSPEC:START -->
**Guardrails**
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
- Keep changes tightly scoped to the requested outcome.
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
**Steps**
1. Determine the change ID to archive:
- If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
- If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
- Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
- If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
**Reference**
- Use `openspec list` to confirm change IDs before archiving.
- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
<!-- OPENSPEC:END -->

28
.claude/commands/openspec/proposal.md
View File

@@ -1,28 +0,0 @@
---
name: OpenSpec: Proposal
description: Scaffold a new OpenSpec change and validate strictly.
category: OpenSpec
tags: [openspec, change]
---
<!-- OPENSPEC:START -->
**Guardrails**
- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
- Keep changes tightly scoped to the requested outcome.
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
**Steps**
1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
**Reference**
- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
<!-- OPENSPEC:END -->

134
.claude/commands/plan.md
View File

@@ -1,134 +0,0 @@
## 计划模式
启动实施前的计划制定模式，制定详细的实施策略。通过在代码实施前制定结构化计划，支持高效开发。
### 使用方法
```bash
# 请求 Claude 进入 Plan Mode
"制定 [实施内容] 的实施计划"
```
### 基本示例
```bash
# 新功能的实施计划
"制定用户认证功能的实施计划"
# 系统设计计划
"制定微服务拆分的实施计划"
# 重构计划
"制定遗留代码的重构计划"
```
### 与 Claude 的协作
```bash
# 复杂功能实施
"制定聊天功能的实施计划。包括 WebSocket、实时通知、历史管理"
# 数据库设计
"制定电商网站的数据库设计计划。包括商品、订单、用户管理"
# API 设计
"制定 GraphQL API 的实施计划。包括认证、缓存、速率限制"
# 基础设施设计
"制定 Docker 化的实施计划。包括开发环境、生产环境、CI/CD"
```
### Plan Mode 的特点
**自动启动**
- 检测到实施任务时自动启动 Plan Mode
- 可通过"制定实施计划"等关键词明确启动
**结构化规格书**
- 需求定义 (用户故事·验收标准)
- 设计书 (架构·数据设计·UI 设计)
- 实施计划 (任务分解·进度跟踪·质量保证)
- 风险分析与对策
**审批流程**
- 通过 `exit_plan_mode` 工具提交计划
- **重要**: 无论工具返回值如何，必须等待用户的明确批准
- 禁止未经批准就开始实施
- 可以修改·调整计划
- 仅在批准后才开始使用 TodoWrite 进行任务管理
### 详细示例
```bash
# 复杂系统实施
"制定在线支付系统的实施计划。包括 Stripe 集成、安全性、错误处理"
# 前端实施
"制定 React 仪表板的实施计划。包括状态管理、组件设计、测试"
# 后端实施
"制定 RESTful API 的实施计划。包括认证、验证、日志记录"
# DevOps 实施
"制定 CI/CD 管道的实施计划。包括测试自动化、部署、监控"
```
### 3 阶段工作流程
#### 阶段 1: Requirements(需求定义)
- **用户故事**: 明确功能的目的和价值
- **验收标准**: 定义完成条件和质量标准
- **约束·前提条件**: 整理技术·时间约束
- **优先级排序**: Must-have/Nice-to-have 分类
#### 阶段 2: Design(设计)
- **架构设计**: 系统构成和技术选型
- **数据设计**: 模式、API 规格、数据流
- **UI/UX 设计**: 界面构成和操作流程
- **风险分析**: 潜在问题和对策
#### 阶段 3: Implementation(实施)
- **任务分解**: 细分为可实施的单位
- **进度跟踪**: 通过 TodoWrite 进行状态管理
- **质量保证**: 测试策略和验证方法
- **审批流程**: 通过 exit_plan_mode 提交计划并等待明确批准
### 注意事项
**适用范围**
- Plan Mode 最适合复杂的实施任务
- 简单修改或小规模变更使用常规实施形式
- 推荐用于 3 步以上的工作或新功能开发
**技术约束**
- 不要信任 `exit_plan_mode` 工具的返回值
- 审批流程通过用户的明确意思表示判断
- 与 CLI 的 plan mode 是不同的功能
**执行注意事项**
- 严禁在批准前开始实施
- 提交计划后必须等待用户响应
- 出错时提供替代方案
### 执行示例
```bash
# 使用示例
"制定用户管理系统的实施计划"
# 预期行为
# 1. Plan Mode 自动启动
# 2. 需求分析和技术选型
# 3. 实施步骤的结构化
# 4. 通过 exit_plan_mode 提交计划
# 5. 批准后开始实施
```