Skip to main content
A capable model already writes reasonable code. What it does not do reliably is stay inside the change you asked for, ship the test with it, keep your docs honest, or avoid the handful of Apple mistakes that only show up on a slow device. Coding Standards are the rules FlowDeck can add to the instructions of every agent session in the app, so you stop repeating them in chat. They apply to code sessions and Plan sessions alike, whichever agent is behind them. They are off until you turn them on. The first time an agent does real Swift work in an Apple project, FlowDeck offers them with a single switch, and Settings is where you fine-tune or switch them on later.

​
Where to change them

Settings ▸ AI Workflows ▸ Coding Standards. There are 29 rules, in five sections: Every rule has its own switch and an info button showing the exact text FlowDeck adds to the agent’s instructions. Nothing is hidden from you, and turning one off removes it from the prompt entirely. There is an All standards switch at the top of the page, and each section has its own, so you can turn off a whole category in one click. A section switch reads as on only when every rule in it is on, so a half-enabled section’s next click turns the rest on rather than quietly switching off what you already had. The first time an agent does real Swift work in an Apple project, meaning a couple of files and a diff worth reading, FlowDeck marks the moment and offers the standards with one switch. That is the only time it interrupts you. Turning the switch on takes effect from your next session; sessions already running are not changed.

​
What they cover

Works the way you asked

Changes only what you asked for, debugs from evidence instead of guesses, and tells you honestly what it changed and what it actually verified.

Writes changes you can trust

Ships tests with behavior changes, keeps refactors behavior-preserving, justifies new dependencies, and leaves your commits, comments, and docs clean.

Avoids the classic Apple mistakes

Never publishes state during a view update, keeps continuous animation off the view graph, owns every task it starts, labels controls, and writes tests that can actually fail.

​
Why these and not others

Every rule in the catalog has to clear two bars. It has to change something. A rule that restates what a current model already does is not included, because it would cost context on every session and change nothing. Telling an agent to write clear code is wasted breath; telling it not to publish state during a SwiftUI view update is not. It has to be a principle, not a preference. These are written to be things a working engineer would agree with regardless of how their team operates. Where a genuine choice exists — test-first or implementation-first, coordinators or native navigation, one composition root or a container — the standards defer to what your project already does rather than picking for you. That matters because you are choosing to switch them on. A standard that argues with your codebase is worse than no standard, and nothing is applied until you ask for it.

​
If you already keep your own rules

If you maintain a detailed CLAUDE.md, AGENTS.md, or a skill, expect some overlap. These standards stay general precisely so they sit underneath your own instructions rather than fighting them, but on a specific enough setup a contradiction is possible. When that happens, turn the offending rule off in Settings. Your own file should win, and switching one off removes it from the prompt completely.

​
The Apple rules

Fifteen of the rules only apply to Apple projects, and FlowDeck leaves them out of the prompt entirely when the session’s project is not one. They are the highest-value part of the catalog, because they cover what a model is good at skipping — the work that has no effect on whether the demo runs, and every effect on whether the app survives contact with a real device. Crash safety. Force unwraps, force casts, and try! are how a model gets past a compiler complaint, and how your app dies in someone’s hand. Memory and lifetime. Retain cycles from escaping closures, full-resolution images in a scrolling list, unbounded caches, tasks that outlive the screen that started them. Every state, not just the happy path. Loading, empty, failure, offline, permission denied, and content longer than the test data. A screen built for the successful case is finished for the demo, not for the user. Sensitive data. Tokens in the Keychain rather than UserDefaults, no secrets in source, nothing personal in logs, and permission prompts asked at a moment that makes sense. Layout that survives real devices. Dynamic Type, dark mode, safe areas, the keyboard, tap-target sizes, and translated strings that are twice as long as yours. SwiftUI correctness. Never publishing state during a view update, keeping continuous animation off the view graph, and tests that can actually fail.
Switching an Apple rule on in a Rust or TypeScript repository costs nothing and changes nothing. The gate is the project, not the setting.

​
What they cost

Each rule adds its text to the system prompt of every session. The Apple rules — the larger half of the catalog — are only spent in Apple projects. If you want that back, turn off the ones you do not need. The catalog is deliberately small for this reason: everything in it earns its place, or it would not be there.

​
When changes take effect

The prompt is composed when a session starts or is restored, so a change applies to your next session rather than one already running. Start a new session to pick it up immediately.