🗑️ remove(skills): retire unsupported skill entries
This commit is contained in:
@@ -89,7 +89,6 @@ Layer 1: rulesets/ (≤50 行/语言，模板源)
|
||||
|
||||
Layer 2: skills/ (按需加载，$skill-name 触发)
|
||||
├─ commit-message: 提交信息规范
|
||||
├─ style-cleanup: 代码风格整理
|
||||
├─ tsl-syntax-reference: TSL 语法条目、写法验证和错误边界
|
||||
├─ tsl-api-reference: TSL API 名称、签名、参数和返回值
|
||||
└─ thirdparty/: 第三方同步 skills
|
||||
|
||||
@@ -65,7 +65,7 @@ python scripts/playbook.py -config playbook.toml
|
||||
```toml
|
||||
[install_skills]
|
||||
mode = “list”
|
||||
skills = [“style-cleanup”, “commit-message”]
|
||||
skills = [“commit-message”]
|
||||
agents_home = “~/.claude” # 或 ~/.agents
|
||||
```
|
||||
|
||||
@@ -88,7 +88,7 @@ python <playbook_root>/scripts/playbook.py -config playbook.toml
|
||||
|
||||
### 3. 使用方式
|
||||
|
||||
- 在对话中通过 `$<skill-name>` 直接点名触发（例如：`$style-cleanup`）
|
||||
- 在对话中通过 `$<skill-name>` 直接点名触发（例如：`$commit-message`）
|
||||
- Codex TUI：可用 `/skills` 浏览与插入
|
||||
- Claude Code：通过 `/skills` 命令或直接在对话中触发
|
||||
|
||||
|
||||
+1
-3
@@ -11,10 +11,8 @@
|
||||
|
||||
| Skill | 作用 | 典型场景 |
|
||||
| ------------------------ | ----------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
|
||||
| `bulk-refactor-workflow` | 大规模重构工作流：符号重命名、API 迁移、安全机械变更 | 跨多文件重命名、API 替换、批量代码转换 |
|
||||
| `commit-message` | 根据 staged diff 生成符合仓库规范的提交信息，并判断是否应拆分提交 | 写 commit message、检查 staged 改动是否适合一个提交 |
|
||||
| `gitea-fix-ci` | 基于 Gitea Actions run/job/log 诊断失败 CI，先形成修复计划再改代码 | Gitea PR checks 失败、远端 CI 红但本地需要定位 |
|
||||
| `style-cleanup` | 使用仓库既有 formatter/linter 做格式和 lint 收尾，不改变语义 | 格式化、lint cleanup、代码改完后的风格整理 |
|
||||
| `gitea-fix-ci` | 基于 Gitea Actions run/job/log 诊断失败 CI，先形成修复计划再改代码；含 `fetch_ci_logs.py` 取证脚本 | Gitea PR checks 失败、远端 CI 红但本地需要定位 |
|
||||
| `tsl-syntax-reference` | 查询 TSL 语法条目，验证具体写法和错误边界；不负责 API、命名、风格、工具链或模块集成 | 写/改/审 TSL 时确认语言结构、表达式、控制流、对象模型和语法限制 |
|
||||
| `tsl-api-reference` | 查询随 skill 分发的 TSL API 参考：按名精确查条目，或按中文关键词发现候选 | 写/审 TSL 时确认 builtin、dotnet、模块 API 的签名、参数、返回值和示例 |
|
||||
|
||||
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
name: style-cleanup
|
||||
description: Use when the user asks to format code, fix lint issues, or align style with the repository's existing toolchain without changing behavior.
|
||||
---
|
||||
|
||||
# Style Cleanup
|
||||
|
||||
## Overview
|
||||
|
||||
Use the repository's own formatter and lint contracts without changing behavior.
|
||||
Keep the requested scope, preserve Git state, and prove the resulting diff is
|
||||
style-only.
|
||||
|
||||
## Use Boundary
|
||||
|
||||
Use for requested formatting, lint cleanup, or a final style pass. Do not use for
|
||||
semantic refactors, new tool configuration, or full-repo reformatting without
|
||||
explicit scope.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Fix the scope and preserve Git state**
|
||||
|
||||
Record `git status --short`. Resolve targets, then inspect
|
||||
`git diff --cached -- <targets>` and `git diff -- <targets>` separately.
|
||||
Default to changed files. If a staged-only target is partially staged, stop and
|
||||
ask because formatters edit the whole working-tree file. Never stage, unstage,
|
||||
commit, or discard changes unless requested.
|
||||
|
||||
2. **Resolve authority in this order**
|
||||
|
||||
User instructions and agreed scope → nearest project instructions and canonical
|
||||
repo/CI commands → checked-in tool config → vendored Playbook defaults. A higher
|
||||
source wins; report conflicts instead of combining rules.
|
||||
|
||||
3. **Choose commands from repository evidence**
|
||||
|
||||
Use a canonical repo entrypoint as one unit. Otherwise select only configured
|
||||
tools for target languages; there is no universal formatter/linter order. Run a
|
||||
non-mutating check first when available, then scoped configured fixers. If a tool
|
||||
is missing, report and stop—do not install tools or invent config.
|
||||
|
||||
4. **Apply and control the blast radius**
|
||||
|
||||
Record the initial diff summary and run the chosen commands. If files outside
|
||||
scope change, stop and report them; do not widen scope or silently revert.
|
||||
|
||||
5. **Verify**
|
||||
|
||||
Inspect final cached and working-tree diffs and confirm the index is unchanged.
|
||||
Run `git diff --check`; rerun the formatter/check for idempotence. If a fixer
|
||||
changes tokens, imports, structure, or any non-style hunk, run relevant behavior
|
||||
tests. Without tests, report behavior preservation as unverified.
|
||||
|
||||
## Playbook as Authority
|
||||
|
||||
Use these only when no higher-priority project rule conflicts:
|
||||
|
||||
- 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
|
||||
|
||||
Report `Scope`, `Authority`, `Commands`, `Git State`, `Changes`, `Verification`,
|
||||
and `Remaining`. Include before/after staged state, diff size, idempotence, checks,
|
||||
behavior tests, and anything unverified.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Situation | Action |
|
||||
| --- | --- |
|
||||
| Canonical command exists | Use it; do not build a parallel pipeline |
|
||||
| Staged-only target is partial | Stop and ask |
|
||||
| Tool expands scope | Stop and report; do not silently revert |
|
||||
| Non-style hunk appears | Test behavior or report it unverified |
|
||||
| Tool is missing | Report and stop |
|
||||
|
||||
Example: if `package.json` defines `lint:fix`, use that canonical entrypoint for
|
||||
the requested JS files; do not add a separate Prettier pass unless project
|
||||
instructions require it.
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
- Running familiar tools instead of the repository-selected entrypoint
|
||||
- Giving Playbook defaults priority over project instructions or config
|
||||
- Staging changes, widening scope, or claiming success without final diff review
|
||||
@@ -91,7 +91,6 @@
|
||||
| `brooks-review` | 代码类 Plan 完成后，归档前需要审查 | diff / PR 级代码审查 |
|
||||
| `brooks-test` | 测试改动复杂，或需要确认测试质量 | 测试有效性、覆盖边界、断言质量审查 |
|
||||
| `gitea-fix-ci` | Gitea Actions 失败 | 拉取 CI 日志、定位失败、形成修复计划 |
|
||||
| `style-cleanup` | 代码实现后需要格式或 lint 收尾 | 格式化、lint cleanup，不改变语义 |
|
||||
| `commit-message` | 需要提交或归档当前 Plan 改动 | commit message 生成与 staged diff 检查 |
|
||||
|
||||
### Plan 要求
|
||||
|
||||
Reference in New Issue
Block a user