The Computomatix Times

I've been building iOS and macOS apps with Codex and Claude Code since last year. One thing I've learned: agents need simple systems that produce reliable results.
Without the right skills, agents write deprecated code, create compiler errors, and waste your time debugging their mistakes. These 5 skill packs fix that. Each one comes from a developer who's been shipping real apps with agents.
1. Paul Hudson: The Swift Foundation

If you've learned Swift online, you've probably read Paul Hudson's work (@twostraws). His agent skills come from a decade of teaching Swift through Hacking with Swift — and his SwiftUI rules help correct common mistakes with agents.
I met Paul at try! Swift in NYC and we spent some time together in the SwiftUI labs at WWDC 2019. He's a prolific writer and digs in deep so you can understand what works.

These skills will jumpstart your agents:
SwiftUI Pro: modern SwiftUI APIs, view composition, state management
Swift Concurrency Pro: async/await, actors, Sendable, Swift 6 migration
Swift Testing Pro: Test macros, parameterized tests, XCTest migration
SwiftData Pro: models, queries, migrations, CloudKit sync
He also maintains the canonical directory of every community Swift skill.
2. Antoine van der Lee: SwiftLee

Antoine van der Lee (@twannl) runs SwiftLee — one of the most widely read Swift blogs. He has 5 skill repos, each with detailed reference docs. His Xcode Build Optimization skill stands out — 6 sub-skills for build settings and compilation times to make your code build faster.
SwiftUI Expert: state management, view composition, performance, Liquid Glass
Swift Concurrency: actors, Sendable, data race safety, Swift 6 migration
Swift Testing Expert: modern testing patterns, XCTest migration, parameterized tests
Core Data Expert: stack setup, fetch requests, background contexts, migrations
Xcode Build Optimization: 6 sub-skills for build settings, compilation times, project config
The Xcode Build Optimization skill is a powerful tool that can make both you and your agents more productive. And if you want a better workflow with the iOS Simulator, check out his developer app: @rocketsim_app
3. Thomas Ricouard: Codex Expert

Thomas Ricouard (@Dimillian) built Codex Monitor — the open source macOS app for managing multiple Codex agents — and then joined OpenAI's Developer Experience team.
His skills now ship as the official Codex Build iOS App and Build Mac App plugins. These automatically update with each new release of the Codex app or Codex CLI.
Build iOS Apps plugin
SwiftUI Liquid Glass: iOS 26+ Liquid Glass APIs, modifier ordering, fallbacks
SwiftUI UI Patterns: navigation, sheets, app wiring, reusable components
SwiftUI Performance Audit: invalidation storms, identity churn, layout thrash
SwiftUI View Refactor: smaller subviews, MV-style data flow, Observation
iOS Debugger Agent: simulator build/run/debug with XcodeBuildMCP
iOS App Intents: Siri, Shortcuts, widget integration
Build macOS Apps plugin adds AppKit interop, packaging/notarization, signing/entitlements, window management, and SwiftPM workflows.
You can dig into the source for both of these plugins at the Official OpenAI Plugins repo,
4. Krzysztof Zabłocki: Advanced Swift + Tooling

Krzysztof Zabłocki (@merowing_) created Sourcery — the Swift metaprogramming tool used by 40,000+ apps including Airbnb and The New York Times. His open source tools power over 80,000 apps total.
His approach to agent skills is completely different. Instead of individual skill files, he built a rules-based system over 3 years of daily LLM use — 12 domain-specific rule files with a smart loader that uses LLM self-reflection to decide which rules to apply based on context. The system is tool-agnostic: same rules work in Cursor, Claude Code, and Codex.
What I like about his approach: he has a progressive documentation reading CLI tool to offload search and make it agent-friendly. He also created Inject for hot Swift reloading — useful for fast prototyping when you want to see UI changes without rebuilding.
Read his guide: Stop Getting Average Code from Your LLM
You can grab two agent friendly files that follow his coding philosophy:
general.md: primary directive and coding standards
rule-loading.md: smart loader that selects rules by context
The full 12-file set covering dependency injection, SwiftUI architecture, ViewModel coordination, and Swift Testing is part of his Swifty Stack course.
5. AppCreator: Agent-Friendly Build Tools
None of the skills above matter if your agent can't build and test your code.
Xcode build output is verbose. Test output is worse. We're juggling XCTest and Swift Testing with two different build systems. Agents choke on this.
I built AppCreator to solve that problem. It scaffolds Xcode projects with agent-friendly defaults. I created it to quickly prototype new app ideas that used the same workflow as my existing projects.
Adopt the skill for your existing apps and it will help your agent make a build … continue on X ↗

I'm a VC in the middle of a fundraise, sitting on boards, helping portfolio companies, and angel investing on the side. I've worked with great human EAs and chiefs of staff over the years, so I know what high-leverage support actually looks like. When the first AI APIs came out, I tried to build an AI version of that as a product and couldn't make it work.
When OpenClaw launched I went deep immediately and haven't stopped. I have helped a number of friends set it up and each of them have asked what I have done to configure it and super power it. @ryancarson's post (link in the comments) about how he built his OpenClaw assistant was also great to see, and the response to it convinced me to finally write up what I've been building.
What I have now is more capable than any human chief of staff I've ever worked with. It never forgets a commitment, it handles the small stuff without being asked, flags the important stuff without being told, and it gets better every week. Plus it never sleeps and it never tires. There are still some bumps, but less and less each week.
If any of this is interesting, let me know. If there's enough interest I'll package the whole system up and open source it.
What makes a great chief of staff?
Before I walk through what I've built, it's worth thinking about what a great chief of staff actually does. Not the job description, the real leverage. The best ones I've worked with filtered the noise so only the right things reached me, made sure I walked into every meeting prepared and that nothing fell through after, kept the full picture of what was in flight and flagged what was slipping, tracked relationships and knew where things stood with every important person, and created the daily and weekly rhythm that kept everything moving.
Her name is Stella. She handles all of these, and I'll walk through each one below. But the two things that make my setup genuinely different from other OpenClaw builds are the memory layer underneath it all and the continuous improvement loop that makes the system get better every week. I want to start there because they're what make everything else compound.
Memory: the foundation
Session memory is a lie. Any assistant that treats conversation history as its working context will fail you at the most frustrating moments.
I built two layers. The first is daily notes: one markdown file per day (memory/YYYY-MM-DD.md) serving as a raw log of everything that happened. Meetings attended, decisions made, tasks added and completed, context that came up in conversation. A script called pulls from my sessions throughout the day and writes these automatically.
The second is long-term memory in MEMORY.md, curated by Stella herself. Key people, active projects, lessons learned, decisions made. She periodically synthesizes this from the daily notes, and it's what she reads on startup to orient herself on what matters right now.
Every meeting processed, every email triaged, and every task tracked feeds back into this picture continuously. Without this layer you have a capable assistant with amnesia. With it you have something closer to a person who's been working alongside you for months and never forgets anything.
I've also come to really value that all of this lives in flat markdown files rather than a database. I can open any memory file, read it, edit it if something's wrong, and understand exactly what the assistant knows. I can back the whole thing up to git and restore anything instantly. There's no abstraction layer between me and the assistant's understanding of my world, which means I trust it more and fix things faster when they're off.
Here's where the layers really come together. I'm managing a fundraise involving 100+ LP contacts across multiple countries. Stella tracks the full pipeline, keeps context on each LP and contact, and knows where every relationship stands. For first meetings, I've created a rule that she researches the fund and any recent content they or their partners have published, then preps me with what she found, how it maps to our thesis, and tailored talking points as part of the pre-meeting brief. For ongoing relationships, she knows exactly where they are in the pipeline, what was discussed and committed in our last meeting, and what the key issues are. You can't automate something as critical as a fundraise, but having this kind of structure underneath it means I'm spending my time on the conversations themselves rather than managing the process around them.
Kaizen: the system improves itself
This might be my favorite part, and the thing that makes it feel genuinely different from any assistant I've worked with, human or AI.
Every Friday, a cron job runs research. Stella scans the OpenClaw community, checks for new patterns, looks at what other builders are doing, and saves findings to `memory/kaizen-research-YYYY-MM-DD.md`. On Sunday morning we review it together. She summarizes the week's research, surfaces the top ideas worth tryi… continue on X ↗

Do you want to build iOS or macOS apps with Codex?

I have a new Agent Skill that will help you make apps. Without this skill you're going to waste a lot of time. Let me explain.
I was building a Dangerous Spider app with Codex when I noticed the agent kept missing its own build and test failures. It was looking at the wrong status codes. It genuinely couldn't find the error and would say everything worked (when it didn't).
Xcode compiler build output is extremely verbose. Actual errors get buried in thousands of lines of text. Trying to find an error in Xcode build output is like finding a needle in a haystack.

When you layer in agents, you're wasting time and context by asking them to find the errors.
Agents need to know what worked and what didn't work. It needs to be pass/fail, so I created an agent-designed workflow to do just that.
Here's the 7-step workflow I use every day:
1. Make Xcode Projects Agent Friendly with AppCreator
I built an Agent Skill called AppCreator. Run it once, and it scaffolds a new Xcode project or retrofits an existing one. Now your project is agent-ready.

At the heart of it: a `Makefile` wraps the CLI `xcodebuild` commands using xcbeautify. Clean, readable output from Xcode app builds and tests. The agent sees what failed, fixes it, and moves on. No verbose output to search. It works for iPhone and Mac apps.
Download and install the AppCreator Skill to make your app project agent-friendly.
2. make Is the Only Build Command I Use
The skill is designed so that one command builds and runs your app:
make

Your agent knows how to work with Makefiles, so this is just the starting point. You can extend it however you want.
I ask agents to set the default action to "build-and-run", and to use special build scripts so the freshly built app is always relaunched, just like Xcode.
In Codex CLI, type "make" to check the agent's work.
In the Codex app, set up a custom run action: Click on the Play button and set it to: make.

Finding the setting later requires a few more steps: Go to Environments → Project → View → Edit Local Actions → Actions → Set Action Script to `make`.

With a Makefile, you have a fast, repeatable way to build and run your apps (via the up-arrow on the CLI or the Run button in the Codex app).
3. Just Talk to It
If you want to get good results, you need to actively steer your agent.
Agents are good, but they'll do things you don't want, and the only way to prevent that is to steer the ship as they work.
I frequently double-check the work and redirect when I see agents doing the wrong thing.
I use Wispr Flow to talk out loud — describe what I want, how it should behave, what needs to change. After an agent hands back work, I start Wispr Flow as I play-test the new changes. This gives me the chance to talk through what works and what doesn't, and then, when I'm done, I can paste the transcript directly into the Codex app.
Plan mode is helpful for sparking thoughts about how features and edge cases. However, I have found that the plan mode isn't good enough.

Instead, I would use plan mode to help you think through the feature as a starting point. Use it to spark discussion so you can refine which features you actually build.
Software is nuanced, and if you take it feature by feature, you're going to get better software in the end.
4. Tests Keeps Agents Accountable
Without tests, agents can get sloppy. Tests allow agents to catch their own mistakes.
Ask Codex to write unit tests as it builds. Your goal is fast tests. UI tests are helpful for verification, but they can be annoying and slow to run. I like to have agents use UI tests to catch errors that are impossible to test with unit tests alone.

My recommendation is that you separate your tests into at least two targets:
make test
make ui-test
When an agent runs UI tests, it takes over your machine, which can be disruptive if you need to do anything else (This is where having a second Mac can be useful).
UI tests will slow everything down, so it's best to test them only at hand-off points. When your agent has wrapped up one task or several tasks. Don't do full regression testing for incremental work; instead, ask the agent to test only the smallest subset to verify their work and remain fast.
Have your agents read this article from Peter Steinberger, @steipete: Running UI Tests on iOS With Ludicrous Speed. Using that, you can help keep your test suite from becoming a bottleneck.
5. Log Runtime Results
Another indispensable tool is the use of logs and app artifacts. Have your agent add logging to your app. This gives it another tool for seeing what went wrong in real time.
Agents can stream development logs to a file or read them in real time to fix problems that are not immediately obvious.

When my agent repeatedly fails to complete a task properly, I know it's time to introduce more detailed logs.
Just ask your agent:
Please add verbose logs around XYZ so that you can see what is happening and fix the… continue on X ↗