🗑️ remove(skills): drop duplicate workflows
This commit is contained in:
@@ -1,69 +0,0 @@
|
||||
---
|
||||
name: code-review-workflow
|
||||
description:
|
||||
"Structured expert code review for TSL/C++/Python diffs or patches. Triggers:
|
||||
code review, review PR, diff, 评审, 审查, 安全评审, 性能评审."
|
||||
---
|
||||
|
||||
# Code Review Workflow
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
- Review a PR / `git diff` / patch
|
||||
- Pre-merge quality gate (correctness/security/perf/tests)
|
||||
- Risky refactor, behavior change, auth/data path changes
|
||||
|
||||
## Inputs (required)
|
||||
|
||||
- Change set: PR link or `git diff ...` output (must include context)
|
||||
- Goal: expected behavior / acceptance criteria (1–3 sentences)
|
||||
- Risk level: low|med|high (default: med)
|
||||
- Verification: test commands / repro steps (if unknown, ask first)
|
||||
|
||||
## Procedure
|
||||
|
||||
1. **Triage**
|
||||
|
||||
- Identify touched areas, public APIs, behavior changes, data/auth paths
|
||||
- Classify risk (blast radius, rollback difficulty)
|
||||
|
||||
2. **Correctness**
|
||||
|
||||
- Invariants, edge cases, error handling, null/empty, concurrency
|
||||
- Backward compatibility (inputs/outputs, wire formats, config)
|
||||
|
||||
3. **Security**
|
||||
|
||||
- AuthZ/AuthN boundaries, least privilege
|
||||
- Input validation, injection surfaces, secrets/log redaction
|
||||
|
||||
4. **Maintainability**
|
||||
|
||||
- Naming/structure/style aligned with Playbook docs
|
||||
- Complexity hotspots, duplication, clarity of intent
|
||||
|
||||
5. **Performance**
|
||||
|
||||
- Hot paths, algorithmic complexity, allocations/IO, N+1 patterns
|
||||
|
||||
6. **Tests & Verification**
|
||||
- Map changes → tests; identify missing coverage
|
||||
- Provide minimal verification plan (commands + expected signals)
|
||||
|
||||
## Review Standards (Playbook as authority)
|
||||
|
||||
- Commit message: `docs/common/commit_message.md`
|
||||
- TSL: `docs/tsl/code_style.md`, `docs/tsl/naming.md`, `docs/tsl/toolchain.md`
|
||||
- C++: `docs/cpp/code_style.md`, `docs/cpp/naming.md`, `docs/cpp/toolchain.md`
|
||||
- Python: `docs/python/style_guide.md`, `docs/python/tooling.md`,
|
||||
`docs/python/configuration.md`
|
||||
|
||||
## Output Contract (stable)
|
||||
|
||||
- Summary: what changed & why
|
||||
- Risk: low|med|high + reasoning
|
||||
- Blockers: must-fix before merge (with file/line references when possible)
|
||||
- Non-blocking: Major / Minor / Nit
|
||||
- Questions: missing context / assumptions
|
||||
- Suggested verification: exact commands + what success looks like
|
||||
- Optional patch: minimal diff-style suggestions (only when unambiguous)
|
||||
@@ -1,90 +0,0 @@
|
||||
---
|
||||
name: create-plan
|
||||
description:
|
||||
Create a concise plan. Use when a user explicitly asks for a plan related to a
|
||||
coding task.
|
||||
metadata:
|
||||
short-description: Create a plan
|
||||
---
|
||||
|
||||
# Create Plan
|
||||
|
||||
## Goal
|
||||
|
||||
Turn a user prompt into a **single, actionable plan** delivered in the final
|
||||
assistant message.
|
||||
|
||||
## Minimal workflow
|
||||
|
||||
Throughout the entire workflow, operate in read-only mode. Do not write or
|
||||
update files.
|
||||
|
||||
1. **Scan context quickly**
|
||||
|
||||
- Read `README.md` and any obvious docs (`docs/`, `CONTRIBUTING.md`,
|
||||
`ARCHITECTURE.md`).
|
||||
- Skim relevant files (the ones most likely touched).
|
||||
- Identify constraints (language, frameworks, CI/test commands, deployment
|
||||
shape).
|
||||
|
||||
2. **Ask follow-ups only if blocking**
|
||||
|
||||
- Ask **at most 1–2 questions**.
|
||||
- Only ask if you cannot responsibly plan without the answer; prefer
|
||||
multiple-choice.
|
||||
- If unsure but not blocked, make a reasonable assumption and proceed.
|
||||
|
||||
3. **Create a plan using the template below**
|
||||
|
||||
- Start with **1 short paragraph** describing the intent and approach.
|
||||
- Clearly call out what is **in scope** and what is **not in scope** in
|
||||
short.
|
||||
- Then provide a **small checklist** of action items (default 6–10 items).
|
||||
- Each checklist item should be a concrete action and, when helpful,
|
||||
mention files/commands.
|
||||
- **Make items atomic and ordered**: discovery → changes → tests → rollout.
|
||||
- **Verb-first**: “Add…”, “Refactor…”, “Verify…”, “Ship…”.
|
||||
- Include at least one item for **tests/validation** and one for **edge
|
||||
cases/risk** when applicable.
|
||||
- If there are unknowns, include a tiny **Open questions** section (max 3).
|
||||
|
||||
4. **Do not preface the plan with meta explanations; output only the plan as per
|
||||
template**
|
||||
|
||||
## Plan template (follow exactly)
|
||||
|
||||
```markdown
|
||||
# Plan
|
||||
|
||||
<1–3 sentences: what we’re doing, why, and the high-level approach.>
|
||||
|
||||
## Scope
|
||||
|
||||
- In:
|
||||
- Out:
|
||||
|
||||
## Action items
|
||||
|
||||
[ ] <Step 1> [ ] <Step 2> [ ] <Step 3> [ ] <Step 4> [ ] <Step 5> [ ] <Step 6>
|
||||
|
||||
## Open questions
|
||||
|
||||
- <Question 1>
|
||||
- <Question 2>
|
||||
- <Question 3>
|
||||
```
|
||||
|
||||
## Checklist item guidance
|
||||
|
||||
Good checklist items:
|
||||
|
||||
- Point to likely files/modules: src/..., app/..., services/...
|
||||
- Name concrete validation: “Run npm test”, “Add unit tests for X”
|
||||
- Include safe rollout when relevant: feature flag, migration plan, rollback
|
||||
note
|
||||
|
||||
Avoid:
|
||||
|
||||
- Vague steps (“handle backend”, “do auth”)
|
||||
- Too many micro-steps
|
||||
- Writing code snippets (keep the plan implementation-agnostic)
|
||||
@@ -1,109 +0,0 @@
|
||||
---
|
||||
name: testing-workflow
|
||||
description: "测试策略与最佳实践（TSL/Python/C++）：单元测试→集成测试→回归测试。Triggers: 写测试, 测试策略, 单元测试, 集成测试, testing, unit test, how to test"
|
||||
---
|
||||
|
||||
# 测试工作流
|
||||
|
||||
> 适用语言：TSL / Python / C++
|
||||
> 核心原则：新功能与 bug 修复必须有可复现的测试。
|
||||
|
||||
## 使用时机
|
||||
|
||||
- 新功能开发
|
||||
- Bug 修复
|
||||
- 重构或行为变更
|
||||
|
||||
## 测试层级
|
||||
|
||||
### 1. 单元测试（Unit Tests）
|
||||
|
||||
**目标**：验证单个函数/类的行为
|
||||
|
||||
- 测试纯函数（无副作用）
|
||||
- Mock 外部依赖（文件/网络/数据库）
|
||||
- 一个测试只验证一个行为点
|
||||
|
||||
**命名示例**：
|
||||
|
||||
- `test_add_positive_numbers_returns_sum`
|
||||
- `test_add_with_zero_returns_other_number`
|
||||
|
||||
### 2. 集成测试（Integration Tests）
|
||||
|
||||
**目标**：验证模块间交互
|
||||
|
||||
- 关键流程的 end-to-end 测试
|
||||
- 使用真实依赖或测试环境
|
||||
- 验证数据流与状态转换
|
||||
|
||||
### 3. 回归测试（Regression Tests）
|
||||
|
||||
**目标**：防止已修复的 bug 复发
|
||||
|
||||
- 修 bug 先写失败测试
|
||||
- 修复后测试通过
|
||||
|
||||
## 何时补测试
|
||||
|
||||
| 场景 | 是否需要测试 | 测试类型 |
|
||||
| --------- | ------------ | ------------ |
|
||||
| 新功能 | ✅ 必须 | 单元 + 集成 |
|
||||
| Bug 修复 | ✅ 必须 | 回归 |
|
||||
| 重构 | ✅ 必须 | 运行现有测试 |
|
||||
| 文档/注释 | ❌ 不需要 | - |
|
||||
| 格式调整 | ❌ 不需要 | - |
|
||||
|
||||
## 测试可维护性原则
|
||||
|
||||
1. 一个测试一个断言（或一组相关断言）
|
||||
2. 测试名称自解释
|
||||
3. 避免依赖外部资源（用 Mock/Stub）
|
||||
4. 测试代码也要可读
|
||||
|
||||
## 反模式
|
||||
|
||||
- 依赖执行顺序、随机数、系统时间
|
||||
- 单元测试过慢（>1s）
|
||||
- Magic number 过多
|
||||
- 重复测试相同行为
|
||||
|
||||
## 运行测试
|
||||
|
||||
### TSL
|
||||
|
||||
- 若项目已有测试命令，优先使用项目标准命令
|
||||
- 否则建议添加最小可运行脚本并在 README 说明
|
||||
|
||||
### Python
|
||||
|
||||
```bash
|
||||
pytest tests/
|
||||
pytest tests/test_module.py::test_function
|
||||
```
|
||||
|
||||
### C++
|
||||
|
||||
```bash
|
||||
ctest
|
||||
./build/test_runner --gtest_filter=TestSuite.TestName
|
||||
```
|
||||
|
||||
## 测试失败处理
|
||||
|
||||
1. 定位：哪个测试失败、失败条件是什么
|
||||
2. 复现：单独运行失败用例
|
||||
3. 调试：优先检查本次改动
|
||||
4. 无关失败：记录并告知用户
|
||||
|
||||
## 可选：测试驱动开发（TDD）
|
||||
|
||||
1. Red：先写失败测试
|
||||
2. Green：写最少代码让测试通过
|
||||
3. Refactor：重构保持测试绿色
|
||||
|
||||
## 权威参考
|
||||
|
||||
- TSL：`docs/tsl/` 测试相关文档（如有）
|
||||
- Python：`docs/python/tooling.md`
|
||||
- C++：`docs/cpp/toolchain.md`
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
name: todo-plan
|
||||
description: "Create and append plan blocks to TODO.md when the user asks for a plan or mentions plan/计划/TODO/待办; auto-merge or split related tasks."
|
||||
---
|
||||
|
||||
# TODO Plan Writer
|
||||
|
||||
## Trigger guard
|
||||
|
||||
- Only run if the user message explicitly contains one of: `plan`, `计划`, `TODO`, `待办`.
|
||||
|
||||
## Output target
|
||||
|
||||
- Append plan blocks to `TODO.md` (at file end).
|
||||
- Do not modify other files.
|
||||
|
||||
## Planning rules
|
||||
|
||||
- Use create-plan style reasoning: intent -> scope -> action items; include validation/risks when relevant.
|
||||
- Title: concise "module + action" (2-6 words or 6-12 chars).
|
||||
- Multiple tasks:
|
||||
- Merge into one Plan if same module/goal.
|
||||
- Split if different modules/goals.
|
||||
|
||||
## Formatting rules
|
||||
|
||||
- Use the template below verbatim.
|
||||
- Always keep a blank line after the `## Plan: ...` header.
|
||||
- Keep existing TODO.md English structure and indentation.
|
||||
- Use `[ ]` for each action item line.
|
||||
- If notes are not obvious, use `- TBD`.
|
||||
- Line endings: LF.
|
||||
|
||||
## Plan template
|
||||
|
||||
```md
|
||||
## Plan: <title>
|
||||
|
||||
- Goal: <one-line objective>
|
||||
- Scope:
|
||||
- In: <what is included>
|
||||
- Out: <what is excluded>
|
||||
- Actions:
|
||||
[ ] <action item>
|
||||
[ ] <action item>
|
||||
- Notes:
|
||||
- <tests / observations / constraints>
|
||||
```
|
||||
Reference in New Issue
Block a user