Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add patrickserrano/lacquer --skill macos-ci-recipesgit clone --depth 1 https://github.com/patrickserrano/lacquerWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/patrickserrano/lacquer/macos-ci-recipes)<a href="https://agentmods.dev/skills/patrickserrano/lacquer/macos-ci-recipes"><img src="https://agentmods.dev/badge/skills/patrickserrano/lacquer/macos-ci-recipes.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00150 | $0.03108 |
| Opus 5 | $0.00075 | $0.01554 |
| Sonnet 5 | $0.00030 | $0.00622 |
| Haiku 4.5 | $0.00015 | $0.00311 |
Grade C, and why
macos-ci-recipes scanned grade C with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
rm -rf {{COMPONENT_PREFIX}}DerivedData/Build How it starts
The opening of the file, as written. The whole thing — 281 lines — stays where its author put it; the contents beside it link to each section on GitHub.
macOS CI Recipes
Two shapes, depending on whether an iOS target coexists in the same project.
Both reuse the lacquer's existing iOS CI conventions (dedicated runner,
CODE_SIGNING_ALLOWED=NO for non-release jobs, the exit-65 spurious-failure
handling, the error-tail grep on real failures) — nothing here is a new
pattern, just the iOS pattern applied to -destination 'platform=macOS'.
Why the dedicated runner, not a GitHub-hosted macOS one: these jobs (and
any other Xcode-touching job you add) must run on
runs-on: [self-hosted, macOS, ARM64, dedicated] — never macos-latest or a
stray label like mac-mini. Release jobs hold App Store Connect keys and
unlock the login keychain, so signing must only ever happen on infrastructure
you control; the pinned Xcode + simulator runtime lives only on the dedicated
runner (GitHub-hosted macOS images drift); and GitHub-hosted macOS minutes are
billed while the dedicated runner isn't. A pure script/REST-call job with no
Xcode dependency uses ubuntu-latest instead.
Which recipe
- No iOS target at all (a macOS-only app on the
iosprofile): use "macOS-only app" below. It replaces the syncedios-ci.ymloutright —excludeit in.lacquer.tomland add this file to your project'sroot/tree instead (the lacquer already supports excluding a synced file; this is that mechanism, just pointed at CI instead of release/testflight). - An iOS target plus a separate macOS scheme sharing code (e.g. a shared
Core/+Shared/compiled into both an iOS app and aMenuBarExtra/full macOS app): use "Hybrid" below. It adds one job to your project's own copy of the syncedios-ci.yml— see "Living with a hand-edited managed file" for what that costs on future syncs.
macOS-only app
Lint, build, and test jobs mirroring the lacquer's iOS shape, with no simulator involved anywhere:
name: macOS CI
on:
workflow_dispatch:
pull_request:
branches: [main, develop, 'feat/*', 'fix/*']
push:
branches: [main]
permissions:
contents: read
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
jobs:
lint:
name: swiftformat + swiftlint (strict)
runs-on: [self-hosted, macOS, ARM64, dedicated]
steps:
- uses: actions/[email protected]
- name: swiftformat --lint
run: swiftformat --lint {{COMPONENT_PREFIX}}.
- name: swiftlint --strict
run: swiftlint --strict --config {{COMPONENT_PREFIX}}.swiftlint.yml {{COMPONENT_PREFIX}}.
build:
name: xcodebuild build (macOS)
runs-on: [self-hosted, macOS, ARM64, dedicated]
steps:
- uses: actions/[email protected]
# No actions/cache for SPM here: on a persistent dedicated runner,
# DerivedData/SourcePackages already survives between runs on local
# disk. actions/cache still tars+uploads+downloads on every run
# regardless of whether anything changed — one fleet project measured
# this at ~25 minutes of overhead against a 16-second compile. This is
# an open question for the lacquer's OWN iOS ci.yml too (it still uses
# actions/cache on the same runner class) — verify your runner is
# actually the same persistent box across runs before dropping the
# cache step; if it's ephemeral/rotating, keep it.
- name: xcodebuild build
run: |
set -o pipefail
xcodebuild build \
-project "{{XCODEPROJ}}" \
-scheme "{{SCHEME}}" \
-destination 'platform=macOS' \
-configuration Debug \
CODE_SIGNING_ALLOWED=NO \
| xcpretty --color || xcodebuild build \
-project "{{XCODEPROJ}}" \
-scheme "{{SCHEME}}" \
-destination 'platform=macOS' \
-configuration Debug \
CODE_SIGNING_ALLOWED=NO
- name: xcodebuild test
run: |
set -o pipefail
xcodebuild test \
-project "{{XCODEPROJ}}" \
-scheme "{{SCHEME}}" \
-destination 'platform=macOS' \
-configuration Debug \
CODE_SIGNING_ALLOWED=NO \
-only-testing:<YourTestTarget> \
| xcpretty --color || xcodebuild test \
-project "{{XCODEPROJ}}" \
-scheme "{{SCHEME}}" \
-destination 'platform=macOS' \
-configuration Debug \
CODE_SIGNING_ALLOWED=NO \
-only-testing:<YourTestTarget>
ci-ok:
name: CI OK
runs-on: ubuntu-latest
needs: [lint, build]
if: always()
timeout-minutes: 2
steps:
- name: Verify required jobs passed (or were skipped)
run: |
for r in "${{ needs.lint.result }}" "${{ needs.build.result }}"; do
if [ "$r" = "failure" ] || [ "$r" = "cancelled" ]; then
echo "::error::A required job did not pass (result=$r)"
exit 1
fi
done
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 281 lines · 150 tokens per session scan C 624ac2444ef6
macos-ci-recipes is a skill published in the GitHub repository patrickserrano/lacquer (3 stars, last pushed yesterday), licensed MIT. It adds 150 tokens to every session and 3,108 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
jk
Manage Jenkins controllers with jk, including jobs, runs, logs, artifacts, credentials, nodes, queues, and plugins.
verify
Pre-merge verification gate. Build, test, and lint must all pass before marking done or shipping.
audit-harness
Use when auditing HARNESS.md, pre-commit hooks, pre-push hooks, architecture gates, or CI workflows for tunacode-cli. This skill treats any mismatch, skipped gate, or failing check as a critical failure and requires manual one-by-one execution rather than make targets, batch wrappers, or summary-only audits.
github-actions
Use when adding CI/CD, creating workflows, auditing GitHub Actions, or fixing action pinning. Creates and audits workflows for SHA pinning and permissions.
verify
Verification before completion — no success claims without fresh evidence. Auto-triggered before any completion claim. Also available as /verify.
tune-repo
Audit and tighten the current repository so Claude Code works faster and more accurately in it — verify the existing CLAUDE.md still matches reality, tighten the build/test/lint verification loop, add only the missing static guardrails, and reduce permission friction. Use when the user wants to "tune", "audit"…