feat: add keyword maintenance skill
This commit is contained in:
@@ -0,0 +1,33 @@
|
||||
# Alias Review Example
|
||||
|
||||
Use this as the default style reference when preparing a low-frequency alias review report.
|
||||
|
||||
## Suggested merges
|
||||
|
||||
- `Claude code -> Claude Code`
|
||||
- 理由:明显属于同一产品名,仅是大小写写法不一致。
|
||||
- 证据:`Claude Code` 在最近多日持续出现,而小写写法只是在少量上下文中作为变体出现。
|
||||
|
||||
- `Sub-Agent -> SubAgent`
|
||||
- 理由:更像词形差异,不构成新的独立概念。
|
||||
- 证据:两者都围绕同一 agent 架构语境出现,且没有稳定区分语义。
|
||||
|
||||
## Not recommended to merge
|
||||
|
||||
- `Skills ↔ Agent Skills`
|
||||
- 理由:前者过泛,后者更具体,当前强行归并会损失粒度。
|
||||
|
||||
- `Anthropic ↔ Claude`
|
||||
- 理由:公司名与产品名并不等价,不应直接视为一个关键词。
|
||||
|
||||
## Needs human judgment
|
||||
|
||||
- `AI助手 ↔ AI Agent`
|
||||
- 风险点:语义可能接近,但中文表述范围更宽,是否并入需要结合实际使用语境判断。
|
||||
|
||||
## Style notes
|
||||
|
||||
- Keep the report concise.
|
||||
- Give judgment first, then evidence.
|
||||
- Do not claim anything is already applied.
|
||||
- Prefer conservative proposals over broad semantic merging.
|
||||
@@ -0,0 +1,106 @@
|
||||
# Cleanup Policy
|
||||
|
||||
## Purpose
|
||||
|
||||
This reference defines how `reader-keyword-maintenance` should treat keyword governance artifacts.
|
||||
|
||||
The goal is to keep long-term assets small and stable while allowing review-time working files to exist when needed.
|
||||
|
||||
This policy is for low-frequency maintenance only.
|
||||
It does not replace the formal keyword review generation flow in reader.
|
||||
|
||||
## Artifact classes
|
||||
|
||||
### Long-term assets
|
||||
|
||||
Keep these by default:
|
||||
|
||||
- `data/term_index/daily/*.json`
|
||||
- `data/term_index/term_stats.json`
|
||||
- `configs/filter_context.personal.json`
|
||||
- `configs/term_watchlist.json`
|
||||
- `configs/term_aliases.json`
|
||||
- `configs/term_stopwords.json`
|
||||
- `configs/term_change_log.json`
|
||||
|
||||
These are facts or active state.
|
||||
|
||||
### Short-term decision artifacts
|
||||
|
||||
Keep selectively:
|
||||
|
||||
- `outputs/term_index/review/term-cleanup-suggestions-YYYY-MM-DD.json`
|
||||
|
||||
Recommended policy:
|
||||
|
||||
- keep only recent few files, or
|
||||
- keep only files that were actually used for apply decisions
|
||||
|
||||
### Temporary working/display files
|
||||
|
||||
Treat as disposable unless the user explicitly asks to archive them:
|
||||
|
||||
- `outputs/term_index/review/keyword-cleanup-bundle.json`
|
||||
- `outputs/term_index/review/term-cleanup-suggestions-YYYY-MM-DD.md`
|
||||
|
||||
Recommended policy:
|
||||
|
||||
- bundle: keep only latest current file
|
||||
- markdown: generate on demand, do not archive by default
|
||||
|
||||
## Default maintenance actions
|
||||
|
||||
### Safe checks
|
||||
|
||||
Before deleting anything:
|
||||
|
||||
1. confirm the target is not the current bundle under active review
|
||||
2. confirm the target suggestions JSON is not the one about to be applied
|
||||
3. never delete configs or facts during review cleanup
|
||||
|
||||
### Safe cleanup order
|
||||
|
||||
1. remove or overwrite old markdown display drafts
|
||||
2. keep only latest bundle file
|
||||
3. prune old suggestions JSON files conservatively
|
||||
|
||||
## Decision rules
|
||||
|
||||
### When user says "clean review artifacts"
|
||||
|
||||
Default action:
|
||||
|
||||
- keep facts/state untouched
|
||||
- keep current suggestions JSON
|
||||
- remove markdown drafts if they are old and clearly derived display files
|
||||
- keep bundle only as current working file
|
||||
|
||||
### When user says "prepare manual review"
|
||||
|
||||
Default action:
|
||||
|
||||
- ensure latest bundle exists
|
||||
- ensure latest suggestions JSON exists
|
||||
- do not generate formal suggestions or markdown here by default
|
||||
- if the user wants formal review material, route to reader-side `keyword-cleanup-review`
|
||||
|
||||
### When user says "review alias candidates" or "review stopword candidates"
|
||||
|
||||
Default action:
|
||||
|
||||
- explain that formal keyword review generation belongs to reader-side `keyword-cleanup-review`
|
||||
- keep this skill focused on maintenance, cleanup, display generation, and dry-run validation
|
||||
- only proceed here if the user explicitly wants a low-frequency maintenance view rather than the formal review flow
|
||||
|
||||
### When user says "what can be deleted"
|
||||
|
||||
Explain in three buckets:
|
||||
|
||||
- must keep
|
||||
- can keep temporarily
|
||||
- safe to regenerate/delete
|
||||
|
||||
## Non-goals
|
||||
|
||||
This policy does not change reader production logic.
|
||||
It only governs low-frequency maintenance and cleanup decisions in OpenClaw.
|
||||
@@ -0,0 +1,55 @@
|
||||
# Maintenance Checklist
|
||||
|
||||
Use this checklist before doing any cleanup or review-maintenance action for reader keyword artifacts.
|
||||
|
||||
## Pre-check
|
||||
|
||||
1. Confirm the current repo root is `/home/ubuntu/zhu/github/reader`
|
||||
2. Confirm the user asked for a maintenance / cleanup / review-prep action
|
||||
3. If the user actually wants formal keyword review generation, route to reader-side `keyword-cleanup-review` instead of using this maintenance skill
|
||||
4. Identify whether the action targets:
|
||||
- current bundle
|
||||
- suggestions JSON
|
||||
- markdown display draft
|
||||
- old review outputs
|
||||
|
||||
## Safety check
|
||||
|
||||
Before deleting or overwriting anything:
|
||||
|
||||
1. Do not touch:
|
||||
- `data/term_index/daily/*.json`
|
||||
- `data/term_index/term_stats.json`
|
||||
- `configs/filter_context.personal.json`
|
||||
- `configs/term_watchlist.json`
|
||||
- `configs/term_aliases.json`
|
||||
- `configs/term_stopwords.json`
|
||||
- `configs/term_change_log.json`
|
||||
2. Confirm the suggestions JSON to keep is not the one about to be applied
|
||||
3. Treat markdown drafts as disposable only after confirming they are display-only artifacts
|
||||
|
||||
## Review-prep flow
|
||||
|
||||
When preparing manual review:
|
||||
|
||||
1. Ensure the latest bundle exists
|
||||
2. Ensure the latest suggestions JSON exists
|
||||
3. Generate markdown only if the user explicitly wants human-readable review material
|
||||
4. Prefer showing conclusions in chat before creating more files
|
||||
|
||||
## Cleanup flow
|
||||
|
||||
Recommended order:
|
||||
|
||||
1. remove old markdown display drafts
|
||||
2. keep only the current/latest bundle
|
||||
3. prune old suggestions JSON conservatively
|
||||
4. leave facts/state/config untouched
|
||||
|
||||
## Post-check
|
||||
|
||||
After the action:
|
||||
|
||||
1. verify the expected kept files still exist
|
||||
2. verify no config file was accidentally changed
|
||||
3. summarize what was kept vs removed
|
||||
Reference in New Issue
Block a user