home / skills / willsigmon / sigstack / leavn-final-build-push

leavn-final-build-push skill

safe

/plugins/app-dev/skills/leavn-final-build-push

This skill aggressively fixes remaining iOS build errors to produce a clean Leavn build, commits changes, and prepares for ship.

npx playbooks add skill willsigmon/sigstack --skill leavn-final-build-push

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.1 KB

---
name: Leavn Final Build Push
description: Fix last few build errors aggressively, get clean build, commit everything, and prepare for ship in Leavn iOS app
allowed-tools: Read, Edit, Bash, Grep
---

# Leavn Final Build Push

## Instructions

Aggressively fix remaining errors to get clean build:

1. **Count errors**:
   ```bash
   xcodebuild build 2>&1 | grep -c "error:"
   ```

2. **If <10 errors - FIX DIRECTLY**:
   - Read error locations
   - Apply quick fixes
   - Comment out if too complex
   - Priority: BUILD SUCCEEDS

3. **Quick fix strategies**:
   - Missing property: Add stub or comment out usage
   - Binding error: Add @Bindable or remove binding
   - Type mismatch: Cast or change type
   - Actor isolation: Add nonisolated(unsafe)
   - Missing import: Add import

4. **Nuclear options** (if stuck):
   - Comment out broken features
   - Disable problematic files
   - Use `#if false` to guard code
   - Fix properly in next session

5. **Success criteria**:
   - `** BUILD SUCCEEDED **`
   - Commit immediately
   - Document TODOs for disabled code

Use this skill when: Almost at clean build, <10 errors left, need to ship, aggressive fixes needed

Overview

This skill aggressively clears the last build errors in the Leavn iOS app so you get a clean, shippable build quickly. It focuses on rapid, pragmatic fixes, temporary guards for fragile code, and committing the working tree with clear TODO notes. Use it when you are close to a green build and need to prioritize delivery.

How this skill works

The routine runs an Xcode build, counts remaining errors, and applies quick local fixes to reach fewer than ten errors or a full success. It prefers minimal, targeted edits: stubbing missing properties, casting types, adding imports, marking bindings, or using nonisolated annotations. If errors persist, it applies temporary guards (commenting out, #if false) to disable failing code paths, then commits the cleaned state and records TODOs for proper fixes.

When to use it

You have fewer than ~10 build errors remaining
A release or deploy is approaching and you need a clean build fast
You want to prioritize getting a shippable artifact over perfect refactors
Timeboxed debugging failed and a temporary workaround is acceptable
You’ll follow up with proper fixes later in a dedicated session

Best practices

Run xcodebuild and count errors before changing code to measure progress
Make the smallest changes that unblock the build—favor stubs or guards over large rewrites
Comment or mark any temporary code clearly with TODO and rationale
Commit the working tree immediately on BUILD SUCCEEDED and push to a feature or hotfix branch
Keep a checklist of files disabled so you can restore and properly fix them in the next session
Avoid hiding systemic problems permanently—schedule follow-up PRs to clean temporary guards

Example use cases

Final sprint before release: clear remaining build errors to produce an archive
CI failure just before a deployment window: apply quick fixes to restore green build
Developer stuck on complex type/actor errors: add nonisolated or casts to unblock
Late-stage QA found compile-time errors blocking testers: disable problematic feature temporarily
Emergency hotfix branch: commit a minimal working state and document remaining work

FAQ

Is this safe for production?

This skill is intended as a last-resort, time-boxed way to get a clean build. Temporary guards and stubs should be followed by proper fixes in a dedicated follow-up. Commit to a branch and document all TODOs.

How do I revert temporary changes later?

Keep a list of modified or guarded files and include TODO comments. Use git to create a branch for the push, then open follow-up PRs that revert guards and implement correct fixes.