Awesome Swift macOS Apps Docs
Use this skill when the task is to maintain app entries in this repository's bilingual docs.
Use this skill for
- Adding a new app entry to
README.md and README.zh.md
- Updating an existing app entry in both files
- Fixing wrong links, duplicate entries, inconsistent descriptions, or mismatched category placement
- Moving an existing app entry to a better category while preserving local document structure
- Keeping reply format consistent for this repository
Do not use this skill for code changes in other projects.
For supported files and default scope boundaries, see references/supported-files.md.
For category-specific notes and placement heuristics, see references/category-notes.md.
Repository Targets
Always update both files together:
Core workflow
- Identify the most appropriate category by searching existing README files for similar apps or keywords.
- Read the local context around the target section in both languages before editing.
- Check whether the app already exists in either file.
- Add or update both entries together.
- Keep the description to one sentence in each language.
- Verify placement, wording, and formatting with
rg and git diff.
Entry Rules
For each new app entry:
- Use a single concise sentence to describe what the app is
- Prefer describing the core function, not a feature list
- Do not emphasize that it is a macOS app unless that is essential to understanding the app
- Keep English and Chinese descriptions aligned in meaning, but do not translate mechanically
- Preserve existing markdown format, badges, and ordering style used in the target section
- Keep naming consistent with the user's request; if the repo name differs from the display name, follow the user's requested display name unless there is a strong reason not to
Curation Rules
- Match the local section used by each document instead of assuming both files are structured identically.
- Preserve existing ordering within a section. In practice this is usually alphabetical by app name or grouped with similar nearby tools.
- Do not rewrite neighboring entries unless needed for the requested task.
- Keep edits narrowly scoped to the requested listing work.
Category Placement
Choose the closest existing category based on the app's main purpose.
Heuristics:
- AI clients, coding-agent dashboards, AI utilities:
AI
- Local model runtimes and model-serving tools:
Local LLM
- Terminal environments, multiplexers, SSH/native shell workspaces:
Terminal
- Docker-based local web/dev stack tools:
Web Development
- Git identity/config/dev helper tools:
Other Development
- Window tiling, snapping, positioning:
Window Management
- Clipboard tools:
Clipboard
- Audio/video players:
Player
- Keyboard layout/input overlays:
Keyboard
- Screenshot/OCR/capture tools: screenshot-related section already present in main list; place near similar entries
- If no category is clearly better, use
Other
When unsure, inspect nearby entries before editing.
Description Style
English:
- Short and direct
- Prefer noun-phrase or simple functional sentence fragments
- Avoid marketing words like "powerful", "beautiful", "premium", "ultimate" unless needed for meaning
- Avoid long feature enumerations
Chinese:
- Keep it natural and concise
- Prefer patterns like
用于…的工具 / …管理工具 / …客户端 / …工作台
- Do not force exact word order from English
Preferred patterns:
Git identity manager for switching profiles, emails, and SSH keys.
SSH workspace for Hermes with sessions, files, usage, skills, and a real terminal.
集截图、录屏、标注、OCR 和贴屏展示于一体的工具。
Validation
- Search for the app name in
README.md and README.zh.md
- Review
git diff for only the intended changes
- Confirm the entry appears once per intended file
- Confirm the wording remains one sentence in each language
- Confirm final line numbers with
rg -n
Reply Format
After finishing, reply briefly with:
- whether it was added or updated
- English file location
- Chinese file location
- final English description
- final Chinese description
- whether tests were run; for doc-only changes, say tests were not run
Notes
Common user preference for this repository:
- "描述简明扼要"
- "一句话说明是个什么应用"
- "不要强调 macOS 应用" unless the user explicitly asks otherwise
Scope Boundary
- This skill is for repository curation, not for rewriting repository structure or reformatting unrelated content.
- If the user asks for a broader taxonomy change, inspect the surrounding sections first and then make the smallest consistent change.
1---2name: awesome-swift-macos-apps-docs3description: Use when adding, updating, or validating app entries in the awesome-swift-macos-apps repository, especially when maintaining both README.md and README.zh.md with concise one-sentence descriptions, correct category placement, and consistent bilingual formatting.4---56# Awesome Swift macOS Apps Docs78Use this skill when the task is to maintain app entries in this repository's bilingual docs.910## Use this skill for1112- Adding a new app entry to `README.md` and `README.zh.md`13- Updating an existing app entry in both files14- Fixing wrong links, duplicate entries, inconsistent descriptions, or mismatched category placement15- Moving an existing app entry to a better category while preserving local document structure16- Keeping reply format consistent for this repository1718Do not use this skill for code changes in other projects.1920For supported files and default scope boundaries, see [references/supported-files.md](references/supported-files.md).21For category-specific notes and placement heuristics, see [references/category-notes.md](references/category-notes.md).2223## Repository Targets2425Always update both files together:26- `README.md`27- `README.zh.md`2829## Core workflow30311. Identify the most appropriate category by searching existing README files for similar apps or keywords.322. Read the local context around the target section in both languages before editing.333. Check whether the app already exists in either file.344. Add or update both entries together.355. Keep the description to one sentence in each language.366. Verify placement, wording, and formatting with `rg` and `git diff`.3738## Entry Rules3940For each new app entry:41- Use a single concise sentence to describe what the app is42- Prefer describing the core function, not a feature list43- Do not emphasize that it is a macOS app unless that is essential to understanding the app44- Keep English and Chinese descriptions aligned in meaning, but do not translate mechanically45- Preserve existing markdown format, badges, and ordering style used in the target section46- Keep naming consistent with the user's request; if the repo name differs from the display name, follow the user's requested display name unless there is a strong reason not to4748## Curation Rules4950- Match the local section used by each document instead of assuming both files are structured identically.51- Preserve existing ordering within a section. In practice this is usually alphabetical by app name or grouped with similar nearby tools.52- Do not rewrite neighboring entries unless needed for the requested task.53- Keep edits narrowly scoped to the requested listing work.5455## Category Placement5657Choose the closest existing category based on the app's main purpose.5859Heuristics:60- AI clients, coding-agent dashboards, AI utilities: `AI`61- Local model runtimes and model-serving tools: `Local LLM`62- Terminal environments, multiplexers, SSH/native shell workspaces: `Terminal`63- Docker-based local web/dev stack tools: `Web Development`64- Git identity/config/dev helper tools: `Other Development`65- Window tiling, snapping, positioning: `Window Management`66- Clipboard tools: `Clipboard`67- Audio/video players: `Player`68- Keyboard layout/input overlays: `Keyboard`69- Screenshot/OCR/capture tools: screenshot-related section already present in main list; place near similar entries70- If no category is clearly better, use `Other`7172When unsure, inspect nearby entries before editing.7374## Description Style7576English:77- Short and direct78- Prefer noun-phrase or simple functional sentence fragments79- Avoid marketing words like "powerful", "beautiful", "premium", "ultimate" unless needed for meaning80- Avoid long feature enumerations8182Chinese:83- Keep it natural and concise84- Prefer patterns like `用于…的工具` / `…管理工具` / `…客户端` / `…工作台`85- Do not force exact word order from English8687Preferred patterns:8889- `Git identity manager for switching profiles, emails, and SSH keys.`90- `SSH workspace for Hermes with sessions, files, usage, skills, and a real terminal.`91- `集截图、录屏、标注、OCR 和贴屏展示于一体的工具。`9293## Validation9495- Search for the app name in `README.md` and `README.zh.md`96- Review `git diff` for only the intended changes97- Confirm the entry appears once per intended file98- Confirm the wording remains one sentence in each language99- Confirm final line numbers with `rg -n`100101## Reply Format102103After finishing, reply briefly with:104- whether it was added or updated105- English file location106- Chinese file location107- final English description108- final Chinese description109- whether tests were run; for doc-only changes, say tests were not run110111## Notes112113Common user preference for this repository:114- "描述简明扼要"115- "一句话说明是个什么应用"116- "不要强调 macOS 应用" unless the user explicitly asks otherwise117118## Scope Boundary119120- This skill is for repository curation, not for rewriting repository structure or reformatting unrelated content.121- If the user asks for a broader taxonomy change, inspect the surrounding sections first and then make the smallest consistent change.