Picture this: a developer closes his laptop around midnight, having typed exactly one prompt, and by the time he checks his phone the next morning there’s a working feature sitting in his Bible study app. No debugging session. No three-hour coding sprint. Just a prompt, some sleep, and a pull request waiting for review.
That’s not a fluke. The author behind Sojourn: Topical Bible Study has been running this playbook for weeks, and he’s got the receipts: 49 GitHub issues created, 45 of them closed as fully shipped features. Each one started as a single prompt. I love a good process breakdown, and this one made me rethink how much scaffolding actually goes into “one-shot” AI coding.
Why It Matters ✨
Everyone’s heard the claim that AI can write your whole app now. Fewer people show the actual machinery behind making that reliable across dozens of features instead of one lucky demo. The author isn’t describing a party trick, he’s describing a repeatable system: a home screen widget that spans 27 files and 2,466 lines of code, built from one issue and one prompt. Another feature, letting users email themselves a conversation, touched the client, the backend, and an email provider. Also one issue, one prompt.
What makes this worth stealing isn’t the AI model. It’s the prep work that happens before a single prompt gets typed.
How The One-Shot Process Works 🛠️
- Build the baseline context first. Before writing any feature, the author spent multiple days shaping the app’s UX inside Claude Design, then embedded that prototype directly into the app’s website. When he moved to Claude Code for the actual iOS build, the tool understood that functional prototype well enough that the finished app’s UX barely drifted from the original mockup. He also keeps a
CLAUDE.mdfile with product rules baked in, like a hard privacy constraint that the app never collects personally identifiable analytics. This context gets created once and reused on every feature after. - Define the feature with
/spec. Every new feature starts here. The author works through the happy path, failure modes, look and feel, architecture, and testing until the feature is fully described. Once it’s solid, the skill turns that conversation into a GitHub issue using a template, with a short title and a detailed description. This step matters because a vague spec is exactly what turns a “one-shot” prompt into five follow-up prompts. - Hand it off with
/gh-issue. This is where the actual one-shot magic happens. The author passes the issue number to the/gh-issueskill and walks away. The skill checks related issues or pull requests if they’re referenced, so two unfinished features can point at each other and get implemented in the right order. When it’s done, it opens a pull request automatically. He often kicks this off before bed and wakes up to a finished PR. - Ship it by hand, deliberately. Publishing stays manual on purpose. Scripts like
run.shfire up the simulator,deploy-to-device.shinstalls the build straight onto his iPhone, andrelease.shpushes it to App Store Connect. For other, non-App-Store projects, a/gh-prskill merges and deploys automatically. The split exists because not every feature deserves a spot on the App Store the moment it’s built, he batches releases on his own schedule instead.
Tips & Tricks From 45 Shipped Features 💡
- Automate anything you do twice. The rule the author follows: if a task happens once, it becomes a script or a skill. That’s why switching laptops recently was painless, he just moved his App Store Connect keys and kept going.
- Cross-reference issues that depend on each other. Linking two GitHub issues lets the implementation skill understand sequencing without you having to explain it again.
- Don’t confuse “can ship daily” with “should ship daily.” The real bottleneck isn’t code generation, it’s deciding what the user experience should feel like. He takes his time on that part even while the implementation moves fast.
- Big and complex still one-shots, if the spec is airtight. Neither the widget feature nor the email feature was small or boilerplate. What made them work in a single prompt was that the hard questions got settled during
/spec, not during implementation. - Know your baseline advantage. The author is upfront that decades of professional experience across design, development, and infrastructure make this workflow easier for him to steer. If you’re newer to shipping products, expect a steeper learning curve on the judgment calls, even if the typing part gets easier.
Give It A Shot 🚀
Forty five features in a few weeks isn’t about a smarter model, it’s about a spec-first habit and a couple of well-built skills doing the boring parts. If you want the full walkthrough, including screenshots of the widget and the email feature in action, the original breakdown is worth a slow read. And if scripture study apps aren’t your thing, steal the process anyway. Your next side project might thank you for it.
Sojourn for iOS Was 45 One-Shot Prompts
by u/jmathai in ChatGPTPromptGenius