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 apply the Swift fundamentals consistently. 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 worker, including the QA Reviewer. Task-scoped guidance is composed beside the selected standards for assignments that need Apple-platform, tool-use, or image-input expertise. 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.

Keeps Swift fundamentals sound

Chooses narrow types and protocol boundaries, owns mutable state and tasks, avoids crashes and leaks, protects secrets, 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 to keep one owner for each running task 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. The Tested Changes rule controls implementation order: use the smallest relevant test selector to see the expected failure, make it pass, and keep that behavior covered. It does not increase validation breadth. TDD alone is not a reason to run every suite, sweep the UI, repeat the flow, or add a device matrix; the Validation settings and explicit repository gates decide that scope.

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

​
Swift basics and Apple development skills

Eight Swift basics rules only apply to Apple projects; FlowDeck leaves them out of the prompt when the project is not an Apple project. They cover type and API design, protocol boundaries, state and task ownership, strings, crash safety, memory, sensitive data, and meaningful tests. 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, unbounded caches, and tasks that outlive their owner. Sensitive data. Secure storage for secrets; no credentials in source or personal data in logs. Framework and UI topics such as SwiftUI state updates, previews, animation, accessibility, adaptive layout, StoreKit, and platform security APIs live in FlowDeck Apple Development Skills. The separate FlowDeck CLI Skill owns build, run, test, simulator, device, and UI automation workflows.
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 enabled rule adds its text to the system prompt. The eight Swift basics rules 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.