xcodebuild-xcsift
Skill3 starsChanged 2 months agoMITView on GitHub
Fallback workflow for Xcode/iOS/macOS builds and tests when Xcode MCP is unavailable or cannot perform the required operation. Runs shell xcodebuild through xcsift with reliable failure propagation and compact output.
In this repository17 other files it gives its agents.
- config/AGENTS.mdAGENTS.md
- analyzeSkill
- app-resizabilitySkill
- code-reviewSkill
- device-interactionSkill
- figmaSkill
- git-commitSkill
- gitlab-glabSkill
- git-redateSkill
- jira-task-contextSkill
- jira-updateSkill
- mr-comment-resolutionSkill
- pragmatic-testingSkill
- resolve-merge-conflictsSkill
- swift-concurrencySkill
- tddSkill
- verifySkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
17 rules. About 0 are common, 6 are distinctive, and 11 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
11
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Prefer the relevant Xcode MCP tool for builds, tests, diagnostics, SwiftUI previews, Apple documentation, and Swift snippets when it is …
- Distinctive: line 14
Use this shell workflow only when Xcode MCP is unavailable, its connection fails, or it does not expose the required operation.
- Very specific: line 15
Treat compilation errors and failing tests returned by Xcode MCP as real results.
- Distinctive: line 16
Use one route for a verification cycle.
- Very specific: line 22
Always pipe xcodebuild output to xcsift.
- Distinctive: line 23
Always redirect stderr to stdout before piping:
- Very specific: line 27
Prefer set -o pipefail so xcodebuild failures are not hidden by the pipe.
- Very specific: line 28
Do not call xcsift --help just to remember common syntax.
- Very specific: line 29
Only check command -v xcsift when availability is genuinely uncertain or a command fails because xcsift is missing.
- Distinctive: line 30
Use project-local instructions first for workspace/project, scheme, destination, and test plan names.
- Very specific: line 31
Prefer -workspace <Name>.xcworkspace whenever an .xcworkspace exists.
- Very specific: line 32
If multiple workspaces are available and project-local instructions do not identify the intended one, ask before running xcodebuild.
- Very specific: line 39
Use this whenever an .xcworkspace exists:
- Very specific: line 53
Use this only when no .xcworkspace exists or project-local instructions explicitly require the project:
- Very specific: line 67
Prefer the workspace form when an .xcworkspace exists:
- Very specific: line 79
Use -project <ProjectName>.xcodeproj instead only when no workspace is available or project-local instructions explicitly require it.
- Distinctive: line 104
After a command finishes, summarize:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Xcodebuild with xcsift
Fallback workflow for invoking shell xcodebuild when Xcode MCP cannot perform the required build or test operation.
Select the execution route
- Prefer the relevant Xcode MCP tool for builds, tests, diagnostics, SwiftUI previews, Apple documentation, and Swift snippets when it is available.
- Use this shell workflow only when Xcode MCP is unavailable, its connection fails, or it does not expose the required operation.
- Treat compilation errors and failing tests returned by Xcode MCP as real results. Diagnose them through Xcode MCP instead of repeating the same operation with shell
xcodebuild. - Use one route for a verification cycle. Never run Xcode MCP and shell builds/tests concurrently.
Once the shell fallback is necessary, apply the rules and templates below.
Core rules
- Always pipe
xcodebuildoutput toxcsift. - Always redirect stderr to stdout before piping:
xcodebuild ... 2>&1 | xcsift ... - Prefer
set -o pipefailsoxcodebuildfailures are not hidden by the pipe. - Do not call
xcsift --helpjust to remember common syntax; use the templates below. - Only check
command -v xcsiftwhen availability is genuinely uncertain or a command fails becausexcsiftis missing. - Use project-local instructions first for workspace/project, scheme, destination, and test plan names.
- Prefer
-workspace <Name>.xcworkspacewhenever an.xcworkspaceexists. Use-project <Name>.xcodeprojonly when no workspace is available or project-local instructions explicitly require it. - If multiple workspaces are available and project-local instructions do not identify the intended one, ask before running
xcodebuild. - Build/test verification may create derived artifacts, but must not edit source, schemes, project settings, or system permissions unless that change is authorized.
Common templates
Build an Xcode workspace preferred
Use this whenever an .xcworkspace exists:
set -o pipefail
xcodebuild \
-workspace <WorkspaceName>.xcworkspace \
-scheme "<Scheme Name>" \
-destination 'generic/platform=iOS Simulator' \
build \
2>&1 | xcsift --quietBuild an Xcode project fallback
Use this only when no .xcworkspace exists or project-local instructions explicitly require the project:
set -o pipefail
xcodebuild \
-project <ProjectName>.xcodeproj \
-scheme "<Scheme Name>" \
-destination 'generic/platform=iOS Simulator' \
build \
2>&1 | xcsift --quietRun tests
Prefer the workspace form when an .xcworkspace exists:
set -o pipefail
xcodebuild \
-workspace <WorkspaceName>.xcworkspace \
-scheme "<Scheme Name>" \
-destination 'platform=iOS Simulator,name=<Simulator Name>' \
test \
2>&1 | xcsift --quietUse -project <ProjectName>.xcodeproj instead only when no workspace is available or project-local instructions explicitly require it.
Include warning details
set -o pipefail
xcodebuild ... 2>&1 | xcsift --warningsTreat warnings as failures
set -o pipefail
xcodebuild ... 2>&1 | xcsift --WerrorTOON output for compact summaries
set -o pipefail
xcodebuild ... 2>&1 | xcsift --format toon --quietReporting results
After a command finishes, summarize:
- command purpose: build/test
- status: success/failure
- errors count
- failed tests count, if any
- warnings count, if present
- notable error messages or failing test names
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

