Menu
Four-gate quality model — build, lint, format, test — that must all pass before any commit.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.