Ship Clean

The bloatware problem is not a download problem. It is a philosophy problem.

CCleaner has a business model. CleanMyMac has a subscription tier. Every tool that wants to live inside your filesystem long enough to charge you monthly has learned to make itself indispensable through complexity. Features you didn't ask for. Dashboard panels for things that were never broken. Upsell modals on Tuesday mornings. You run them because the alternative felt like doing it yourself.

The alternative is doing it yourself. It's faster than you think.

This is not about one app. This is about a workflow for shipping clean, functional, open-source tools across any stack — Swift, Python, JavaScript, Dart, whatever you're holding — using AI as the build partner. One session, one release, one README that doesn't lie.

---

The philosophy first, because everything downstream depends on it.

If a feature isn't built, it isn't in the UI. If a label isn't true, it doesn't exist. If a doc references something that doesn't work, delete the doc. Users who trust you enough to run your code on their machine are extending credit. Don't spend it on theater.

The bloat that kills open-source reputation isn't malware. It's aspirational scaffolding left in production — status bars that say ENCRYPTION: AES-256 because someone thought it looked serious, settings tabs wired to nothing, YOUR_TEAM_ID still sitting in a config file that shipped anyway. These things communicate one thing: the builder didn't review their own work before they handed it to you.

Review your own work.

---

The prompts are the method. Here are several ways to run the same workflow depending on what you're building.

For a Mac app (Swift/Xcode):

Audit this repo against the README. Flag anything documented but not built. Flag dead code, unfinished UI tabs, and labels that aren't functionally true. Delete from the root: internal dev notes, placeholder configs, build artifacts. Add .gitignore covering build/, DMGs, DerivedData, .DS_Store. Wire the provided 1024x1024 PNG into Assets.xcassets as AppIcon.appiconset and a named AppLogo imageset. Implement a lightweight GitHub releases API checker — no Sparkle, no dependencies, ~60 lines — silent check 3 seconds after launch, "Check for Updates..." in the app menu. Rewrite README: icon at top, one-liner, feature table, install steps, privacy statement. BUILD.md short and accurate only. Write make_dmg.sh. Tag v1.0.0.

For a Python CLI tool:

Audit this repo. Does the README match what the code actually does? Cut anything that doesn't. Add .gitignore for pycache, .env, dist/, *.egg-info. Write a clean README: what it does in one sentence, install via pip or pipx, usage with real examples, no aspirational features. Add a --version flag that reads from a VERSION file. Write a build script that produces a standalone binary via PyInstaller if applicable. Footer: built by [your brand], link to the article.

For a JavaScript/web tool:

Audit package.json — remove unused dependencies. Check that every script in the scripts block actually runs. Add .gitignore for node_modules, .env, dist/. Write README: icon, one-liner, npm install, usage, no marketing copy. If it's a browser extension, write the store description while you're there. If it's a CLI, wire a --version flag. Keep it honest.

For a game:

Audit this repo. Remove internal build notes, placeholder assets with temp names, TODO comments in production code. Write README: what the game is, how to play, how to build from source, platform requirements. Screenshot the title screen and one gameplay moment — those are your README images. One-paragraph itch.io description while you're at it.

The icon prompt that works across everything:

[describe the core identity of the tool in 5 words — what it IS, not what it does] rendered as a flat vector app icon, 1024x1024, dark navy background, minimal, bold, no text, centered composition, slightly menacing but clean. Style: modern macOS meets [hacker / brutalist / retrofuturist / noir].

The icon is not decoration. It is the first thing a recruiter, a user, or a peer sees on GitHub. A strong icon communicates something specific about what kind of tool this is and who built it. A generic gear icon communicates that you used the default.

---

The release itself is one command.

./make_dmg.sh 1.0.0

Builds Release, wraps it in a DMG with an Applications shortcut. You attach it to a GitHub Release tagged v1.0.0. Update checking hits the GitHub releases API — when you push v1.1.0, every existing install prompts on next launch. No Sparkle. No certificate authority beyond what Apple gives you free. No phone home.

Right-click → Open on first launch, once, and macOS remembers. That's the entire distribution model for an unsigned open-source tool. Document it in one line. Move on.

---

The make_dmg.sh script itself:

#!/bin/bash
VERSION=${1:-"1.0.0"}
APP_NAME="YourApp"
BUILD_DIR="$(pwd)/build"

xcodebuild \
  -project ${APP_NAME}.xcodeproj \
  -scheme ${APP_NAME} \
  -configuration Release \
  CONFIGURATION_BUILD_DIR="${BUILD_DIR}" \
  build

STAGING="${BUILD_DIR}/dmg_staging"
mkdir -p "${STAGING}"
cp -R "${BUILD_DIR}/${APP_NAME}.app" "${STAGING}/"
ln -s /Applications "${STAGING}/Applications"

hdiutil create \
  -volname "${APP_NAME} ${VERSION}" \
  -srcfolder "${STAGING}" \
  -ov -format UDZO \
  "${BUILD_DIR}/${APP_NAME}-${VERSION}.dmg"

echo "Done: ${BUILD_DIR}/${APP_NAME}-${VERSION}.dmg"

Swap the app name, run it with a version number, attach the output to the GitHub release. That's the whole pipeline.

---

The discipline that makes this fast is not the AI. The AI is fast regardless. The discipline is knowing what to cut before anyone sees it.

Every repo has scaffolding that made sense during development and has no business in production. The App Store prep checklist nobody deleted. The shareware pricing recommendations in BUILD.md from a template someone grabbed in 2022. The launch script sitting in the root next to the real app. The docs/ folder full of implementation summaries that were useful for one hour and will confuse everyone who forks the repo forever.

Cut it. Not because it's embarrassing. Because it's noise in a signal environment. People who download your tools are trying to understand what you built. Make that easy.

One more prompt, the one that runs before everything else on any repo you're about to publish:

Scan this entire repo as a stranger seeing it for the first time. What looks unfinished? What looks dishonest? What's in the root that shouldn't be? What's in the docs that no longer applies? What does the README promise that the code doesn't deliver? Report everything. Then fix it.

Run that before you tag. Every time.

---

GhostInThePrompt.com // The bloat isn't malware. It's aspirational scaffolding left in production. Ship clean or don't ship.