菜单
Four-gate quality model — build, lint, format, test — that must all pass before any commit.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Copy processed MP3s and WAVs to NAS storage. Use after Apple Music import or when re-archiving corrected files.
Move processed ZIPs to archive and clean up extraction folders. Use after album processing is complete.
Copy finished MP3s into Apple Music via the auto-import folder and verify the album lands correctly. Use once metadata is finalized and the user wants tracks added to their library — e.g. "add this to Apple Music" or "import these tracks" — even if they don't say "auto-import" explicitly. Also use to diagnose a bad import, e.g. "it showed up as separate tracks instead of one album."
Inspect and update MP3 tags: genre, artist, album, track count, compilation flag. Use when checking or fixing music file metadata — including diagnostic questions like "why do these show up as separate tracks" or "is this folder's metadata consistent," not just explicit tag-editing requests.
End-to-end processing of downloaded music purchases: extract ZIPs, verify metadata, import to Apple Music, archive to NAS, clean up. Use when processing new music downloads.
Reclaim local disk by offloading cloud-backed Apple Music downloads. Audit iCloud status, build an offload playlist that protects your DJ crates and lossless files, then Remove Download. Use when the Mac is low on disk.
| name | quality-gate |
| description | Four-gate quality model — build, lint, format, test — that must all pass before any commit. |
All four gates must pass before any code is committed:
| Gate | What it checks | Requirement |
|---|---|---|
| Build | Compiles without errors | Zero errors, zero warnings |
| Lint | Static analysis | Zero violations — linter must exit 0 |
| Format | Code style consistency | Clean — run your formatter to fix |
| Tests | Automated test suite | All tests pass |
Run all four at once using your project's combined check target. For projects using Make:
make check
The output must be clean. Any warning: or error: lines in the output are failures.
Projects configure what each gate runs. The skill enforces the policy: zero tolerance on all four.
Never proceed to commit with build errors, lint errors, formatting violations, or failing tests.
If the check passes locally but CI fails, that is a bug — investigate and file an issue rather than pushing again.
Always run the full check command on a clean build before declaring the gate passed. Incremental compilation caches object files — repeat check runs will not regenerate warnings for already-compiled files. Only a clean build guarantees the full warning picture.
For Swift/Make projects:
swift package clean && make check
Never declare success from an incremental build. Test targets compile separately from the main target — warnings in test files only surface when tests are compiled.
Do not add lint suppression annotations (e.g. // swiftlint:disable, // nolint, #pragma warning disable) to silence violations. Disabling rules file-wide or project-wide is also forbidden. Every violation must be fixed at the source.
When both a linter and a formatter enforce line length, they must be configured to the same limit. Neither tool auto-breaks long string literals — those require manual splitting. Do not disable line length rules; fix the code.
Each project defines its gate commands. Examples:
| Project type | Typical check target |
|---|---|
| Make-based | make check |
| Go | go build ./... && golangci-lint run && gofmt -l . && go test ./... |
| Node | npm run build && npm run lint && npm run format:check && npm test |
| Swift/Xcode | make build && make lint && make format-check && make test |
Document your project's gate commands in your CLAUDE.md or README so every contributor runs the same checks.