My-CODEX-Configuration: Skill for Codex

If this skill is used,say:SKILL_SWIFTUI_CODE_STYLE_LOADED

Goal

Apply reusable SwiftUI code-style rules and protect existing behavior when editing, improving, or optimizing Swift code logic.

This skill is for local code editing discipline. Project behavior, platform targeting, repository layout, state-management policy, build behavior, and anti-patterns belong in AGENTS.md.

Inputs

• Current Swift files being edited
• Direct callers, references, and related types
• Existing project formatting style
• Existing AGENTS.md instructions
• User request and any stated behavior change
• Existing tests, previews, or validation commands if relevant

Required sections

When relevant, apply these rule groups:

• Code logic editing restrictions
• MARK comments
• Spacing and indentation
• SwiftUI modifier chains
• SwiftUI previews
• Output summary rules

Steps

1. Read the full file being edited before changing it.
2. Read direct callers, call sites, bindings, persistence references, and API references before changing logic.
3. Decide whether the task is formatting-only, behavior-changing, logic improvement, or optimization.
4. Preserve runtime behavior by default.
5. Keep the diff small and directly related to the user request.
6. Separate formatting cleanup from behavior changes where practical.
7. Apply the project’s existing naming, indentation, spacing, and preview style first.
8. Use the rules below only when they fit the existing project style.
9. Make any intentional behavior change explicit in the final summary.
10. Call out uncertainty when behavior cannot be confirmed from the available code.

Code logic editing restrictions

Use these rules when changing, improving, or optimizing existing code logic.

• Treat behavior preservation as the default. A style, formatting, or cleanup task must not change runtime behavior.
• Do not change business rules, validation rules, navigation flow, persistence behavior, networking behavior, error handling, sorting, filtering, authorization, timing, or platform behavior unless the task explicitly requires it.
• Before editing logic, read the full function/type and its direct callers or call sites. Do not optimize code that is not understood.
• Prefer the smallest logic change that solves the requested problem. Avoid broad rewrites, speculative refactors, and unrelated cleanup.
• Do not combine behavior changes with formatting-only changes in the same edit unless unavoidable. Keep the behavioral diff easy to review.
• Preserve public APIs, stored property names, Codable keys, persistence model fields, user defaults keys, localization keys, asset names, and notification names unless the task explicitly asks to rename or migrate them.
• Do not remove apparently redundant checks, guards, delays, retries, cache invalidation, logging, fallback paths, or compatibility paths unless their purpose is confirmed from context.
• Do not replace explicit error handling with try?, forced unwraps, silent returns, or broad catch {} blocks.
• Do not introduce caching, memoization, debouncing, throttling, parallel execution, detached tasks, or lazy loading unless correctness, invalidation, cancellation, and actor isolation are clear.
• Do not change @MainActor, actor isolation, async task lifetime, cancellation behavior, or thread-safety boundaries only for convenience.
• Do not optimize by making code less readable unless there is a measured or obvious performance problem. Readability wins over micro-optimization.
• Do not change numeric precision, date/time handling, locale behavior, unit conversion, ordering stability, equality semantics, or identifier generation without an explicit reason.
• Do not introduce new dependencies, frameworks, global state, singletons, or hidden shared mutable state for an optimization.
• When improving logic, keep inputs, outputs, side effects, and failure paths explicit.
• When a behavior change is intentional, make it visible in the final summary and mention the reason.