workflow-audit
A 5-layer audit of SwiftUI user flows. Enumerates entry points, traces critical paths, detects 32 categories of workflow bug, evaluates UX impact, and verifies data wiring.
workflow-audit and pattern-based linters are complementary, not competitive: linters find single-file pattern violations cheaply, workflow-audit finds connection bugs across files at higher cost. A thorough audit uses both.
Built while shipping Stuffolio, an iOS/macOS app currently at build 33. Free, open source, Apache 2.0.
~6 min read · scan the TL;DR if you only have 30 seconds
Newer to Claude Code?
A skill is a markdown file Claude Code knows how to run. When you type /workflow-audit, Claude follows the instructions in this skill, walks your SwiftUI codebase across five layers, and writes you a markdown report with file:line citations. You don't have to memorize anything — the skill tells Claude what to do, you read the report.
TL;DR
- What: 5-layer audit of SwiftUI user flows (Discovery → Flow Tracing → Issue Detection → Semantic Evaluation → Data Wiring). 32 issue categories.
- Why: Catches a class of bug that has no code signature to search for — orphan features (the view exists but no entry point reaches it) and unwired data (declared, populated, displayed, but the populator and displayer don't share a path).
- Install: Two
/plugin commands in Claude Code; then /workflow-audit is available in any project.
- Try first:
/workflow-audit layer1 runs the cheapest layer (entry-point inventory) and gives you a real report in ~10 minutes.
- Example output: a real 5-layer audit report on Stuffolio's codebase.
- Portable: methodology works in Cursor, Windsurf, or any AI tool that reads files — see "Using without Claude Code" below.
- Maturity: Used through real App Store submission cycles on a 600-file SwiftUI codebase; CHANGELOG tracks every release.
What workflow-audit is for vs what linters are for
Pattern-based linters (SwiftLint, custom rule sets) check individual files against a catalog — force unwraps, missing @MainActor, deprecated APIs. Fast, run on every save, catch single-file violations cheaply.
workflow-audit enumerates everything that should be connected (routing cases, model properties, notification observers) and verifies which ones actually are. It catches orphan features (the view exists but no entry point reaches it) and unwired data (declared, populated, displayed, but the populator and the displayer don't share a path). Each file is fine in isolation; the bug lives in the absence of a connection.
You don't find these with grep. You find them by enumerating what should connect and then verifying which ones do, across five layers.
| What linters do better | What workflow-audit does better |
|---|
| Run on every save (cheap, fast) | Run before release (deeper, slower) |
| Catch style and pattern violations | Catch connection and data-wiring bugs |
| Single-file context | Multi-file enumeration + verification |
| Hundreds of well-understood rules | Domain-specific workflow categories |
| Mature ecosystem | Newer approach, narrower scope |
If your project already uses SwiftLint or another pattern-based audit, keep it. workflow-audit layers on top.
The five layers
Each layer can be invoked individually or chained as a full pipeline.
