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, Plan sessions, and every Team role, including the QA Reviewer and UI Designer. Every standard starts on by default. After the first substantial Swift turn in an Apple project, FlowDeck presents that recommendation with the full set enabled. Turn its switch off to opt out, or fine-tune the set later in Settings.

​
Where to change them

Settings ▸ AI Workflows ▸ Coding Standards. 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 no separate baseline engineering-rules block underneath your selection. 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. The first time an agent does real Swift work in an Apple project, meaning a couple of files and a diff worth reading, FlowDeck recommends the standards with one switch. That is the only time it interrupts you. The switch starts on and saves immediately; turn it off to opt out. The choice takes effect from your next session, so 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, tests observable outcomes instead of private implementation, 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 remain in control of the set. A standard that argues with your codebase is worse than no standard, and every rule can be disabled in Settings.

​
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

Seventeen 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.