
Debug Generated Project
- 460 installs
- 34 repo stars
- Updated March 27, 2026
- tuist/agent-skills
debug-generated-project is a Tuist agent skill that reproduces, triages, and fixes failures in Tuist-generated Xcode projects through release testing and source builds.
About
debug-generated-project is a Tuist agent skill for diagnosing issues in Tuist-generated iOS and Apple platform projects. It gathers Project.swift, Tuist.swift, targets, and dependency context, then reproduces failures in a minimal temp directory using mise exec tuist@latest -- tuist generate and tuist install when needed. If the latest release still fails, it clones tuist/tuist, builds tuist and ProjectDescription from source with swift build, and retests against main. Triage classifies outcomes as Tuist bugs requiring PRs with zipped reproduction fixtures, user misconfigurations such as missing tuist install or wrong product types, or unclear cases needing GitHub issues. Runtime issues add xcrun simctl install and launch --console-pty steps plus DiagnosticReports crash log review. Developers reach for debug-generated-project when users report generation failures, compile errors after tuist generate, or unexpected runtime behavior in Tuist-managed workspaces.
- debug-generated-project
- Debugging
- AI-coding skill
Debug Generated Project by the numbers
- 460 all-time installs (skills.sh)
- +8 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #93 of 596 Debugging skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/tuist/agent-skills --skill debug-generated-projectAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 460 |
|---|---|
| repo stars | ★ 34 |
| Last updated | March 27, 2026 |
| Repository | tuist/agent-skills ↗ |
How do you debug Tuist project generation failures?
Helps with debugging tasks.
Who is it for?
Tuist maintainers or iOS developers investigating generation, compile, or simulator runtime failures in Tuist-managed Xcode workspaces.
Skip if: Non-Tuist Xcode projects or Android builds—this skill assumes Project.swift manifests and tuist generate workflows.
When should I use this skill?
Users report tuist generate errors, build failures after generation, runtime crashes on simulator launch, or unexpected behavior in Tuist-generated projects.
What you get
Minimal reproduction project, triage classification, optional Tuist source fix PR, corrected Project.swift snippets, or GitHub issue summary with zipped repro.
- Reproduction project
- Triage report
- Tuist PR or corrected manifest
By the numbers
- Four-step workflow: gather context, reproduce on latest, build from source, triage outcome
Files
Debug Tuist Project Issue
Quick Start
1. Ask the user to describe the issue and the project setup (targets, dependencies, configurations, platform). 2. Confirm the issue exists with the latest release by running mise exec tuist@latest -- tuist generate against a reproduction project. 3. If confirmed, clone the Tuist repository and build from source to test against main. 4. Triage: fix the bug and open a PR, advise on misconfiguration, or recommend the user files an issue with a reproduction.
Step 1: Gather Context
Ask the user for:
- What command they ran (e.g.
tuist generate) - The error message or unexpected behavior
- When the issue happens: generation time, compile time, or runtime (app launch or later)
- Their project structure: targets, platforms, dependencies (SwiftPM, XCFrameworks, local packages)
- Their
Project.swiftandTuist.swiftcontent (or relevant excerpts) - Their Tuist version (
tuist version)
The answer to "when" determines the verification strategy:
- Generation time: the issue might be a Tuist bug or a project misconfiguration. Reproduce with
tuist generate. - Compile time: the generated project has incorrect build settings, missing sources, or wrong dependency wiring. Reproduce with
xcodebuild buildafter generation. - Runtime: the app builds but crashes or misbehaves on launch or during use. Reproduce by installing and launching on a simulator.
Step 2: Reproduce with the latest release
Before investigating the source code, confirm the issue is not already fixed in the latest release.
Set up a temporary reproduction project
REPRO_DIR=$(mktemp -d)
cd "$REPRO_DIR"Create minimal Tuist.swift, Project.swift, and source files that reproduce the user's scenario. Keep it as small as possible while still triggering the issue.
Run generation with the latest Tuist release
mise exec tuist@latest -- tuist generate --no-open --path "$REPRO_DIR"If the issue involves dependencies, install them first:
mise exec tuist@latest -- tuist install --path "$REPRO_DIR"Check the result
- If generation succeeds and the issue is gone, tell the user to update to the latest version.
- If the issue persists, continue to Step 3.
Step 3: Build Tuist from Source
Clone the repository and build the tuist executable and ProjectDescription library from source to test against the latest code on main.
TUIST_SRC=$(mktemp -d)
git clone --depth 1 https://github.com/tuist/tuist.git "$TUIST_SRC"
cd "$TUIST_SRC"
swift build --product tuist --product ProjectDescription --replace-scm-with-registryThe built binary will be at .build/debug/tuist. Use it to test the reproduction project:
"$TUIST_SRC/.build/debug/tuist" generate --no-open --path "$REPRO_DIR"If the issue is fixed on main
Tell the user the fix is already on main, and it hasn't been released, tell them it'll be in the nest release and point them to the relevant commit if you can identify it.
If the issue persists on main
Continue to Step 4.
Step 4: Triage the Issue
Investigate the Tuist source code to understand why the issue occurs.
Outcome A: It is a bug
1. Identify the root cause in the source code. 2. Apply the fix. 3. Verify by rebuilding and running against the reproduction project:
cd "$TUIST_SRC"
swift build --product tuist --product ProjectDescription --replace-scm-with-registry
"$TUIST_SRC/.build/debug/tuist" generate --no-open --path "$REPRO_DIR"4. Zip the reproduction project and include it in the PR:
cd "$REPRO_DIR" && cd ..
zip -r reproduction.zip "$(basename "$REPRO_DIR")" -x '*.xcodeproj/*' -x '*.xcworkspace/*' -x 'Derived/*' -x '.build/*'5. Open a PR on the Tuist repository with:
- The fix
- The zipped reproduction project attached or committed as a fixture
- A clear description of the root cause and how to verify the fix
Outcome B: It is a misconfiguration
Tell the user what is wrong and how to fix it. Common misconfigurations:
- Missing
tuist installbeforetuist generatewhen using external dependencies - Incorrect source or resource globs that exclude or double-include files
- Mismatched build configurations between the project and external dependencies
- Wrong product types for dependencies (static vs dynamic)
- Missing
-ObjClinker flag for Objective-C dependencies - Using
sourcesandresourcesglobs together withbuildableFolders
Provide the corrected manifest snippet so the user can apply the fix directly.
Outcome C: Unclear or needs team input
If you cannot determine whether it is a bug or misconfiguration, recommend the user:
1. Open a GitHub issue at https://github.com/tuist/tuist/issues with:
- The reproduction project (zipped)
- The error output
- Their Tuist version and environment details
Provide a summary of what you investigated and what you ruled out, so the user does not have to repeat the triage.
Build Verification
When testing a fix, always verify the full cycle:
# Build the patched tuist
cd "$TUIST_SRC"
swift build --product tuist --product ProjectDescription --replace-scm-with-registry
# Install dependencies if needed
"$TUIST_SRC/.build/debug/tuist" install --path "$REPRO_DIR"
# Generate the project
"$TUIST_SRC/.build/debug/tuist" generate --no-open --path "$REPRO_DIR"
# Build the generated project
xcodebuild build \
-workspace "$REPRO_DIR"/*.xcworkspace \
-scheme <scheme> \
-destination "platform=iOS Simulator,name=iPhone 16 Pro"Runtime Verification
When the user reports a runtime issue (crash on launch, missing resources at runtime, wrong bundle structure, or unexpected behavior), you must go beyond building and actually launch the app on a simulator.
Launch and monitor for crashes
# Boot a simulator
xcrun simctl boot "iPhone 16 Pro" 2>/dev/null || true
# Build for the simulator
xcodebuild build \
-workspace "$REPRO_DIR"/*.xcworkspace \
-scheme <scheme> \
-destination "platform=iOS Simulator,name=iPhone 16 Pro" \
-derivedDataPath "$REPRO_DIR/DerivedData"
# Install the app
xcrun simctl install booted "$REPRO_DIR/DerivedData/Build/Products/Debug-iphonesimulator/<AppName>.app"
# Launch and monitor — this will print crash info if the app terminates abnormally
xcrun simctl launch --console-pty booted <bundle-identifier>The --console-pty flag streams the app's stdout/stderr so you can observe logs and crash output directly. Watch for:
- Immediate crash on launch: usually a missing framework, wrong bundle ID, missing entitlements, or stripped ObjC categories (
-ObjClinker flag missing) - Crash after a few seconds: often missing resources (images, storyboards, XIBs, asset catalogs) or a bundle structure mismatch
- Runtime misbehavior without crash: wrong resource paths, missing localization files, or incorrect Info.plist values
Check crash logs
If the app crashes without useful console output, pull the crash log:
# List recent crash logs for the app
find ~/Library/Logs/DiagnosticReports -name "<AppName>*" -newer "$REPRO_DIR" -printRead the crash log to identify the crashing thread and the faulting symbol.
Done Checklist
- Gathered enough context from the user to reproduce the issue
- Determined whether the issue is at generation time, compile time, or runtime
- Confirmed whether the issue exists in the latest release
- Tested against Tuist built from source (main branch)
- If runtime issue: launched the app on a simulator and verified the crash or misbehavior
- Triaged the issue as a bug, misconfiguration, or unclear
- If bug: applied fix, verified it, and opened a PR with reproduction project
- If misconfiguration: provided corrected manifest to the user
- If unclear: gave the user a summary and recommended next steps
Related skills
FAQ
What triggers debug-generated-project?
debug-generated-project activates when users report Tuist generation failures, compile errors after tuist generate, or unexpected runtime behavior, guiding reproduction with mise tuist@latest and optional Tuist source builds.
How does debug-generated-project classify issues?
debug-generated-project triages outcomes as Tuist bugs warranting PRs with reproduction.zip fixtures, user misconfigurations with corrected manifest snippets, or unclear cases referred to github.com/tuist/tuist/issues with investigation notes.
Does debug-generated-project test runtime crashes?
Yes—for runtime reports debug-generated-project boots a simulator, installs the built app, launches with xcrun simctl launch --console-pty, and reads ~/Library/Logs/DiagnosticReports crash logs when console output is insufficient.