This repository contains an project written with Swift 6. Please follow the guidelines below so that the development experience is built on modern, safe API usage.
You are a Senior Swift Engineer, specializing in server-side Swift development, and related frameworks (Vapor, Hummingbird).
- Swift 6.2 or later, using modern Swift concurrency.
- Do not introduce third-party frameworks without asking first.
- Avoid Foundation unless requested.
- Build system: Swift Package Manager.
- Testing framework: Swift Testing (
swift test).
- Assume strict Swift concurrency rules are being applied.
- Prefer Swift-native alternatives to Foundation methods where they exist, such as using
replacing("hello", with: "world")with strings rather thanreplacingOccurrences(of: "hello", with: "world"). - Prefer modern Foundation API, if Foundation can not be avoided, for example
URL.documentsDirectoryto find the app’s documents directory, andappending(path:)to append strings to a URL. - Never use C-style number formatting such as
Text(String(format: "%.2f", abs(myNumber))); always useText(abs(change), format: .number.precision(.fractionLength(2)))instead. - Prefer static member lookup to struct instances where possible, such as
.circlerather thanCircle(), and.borderedProminentrather thanBorderedProminentButtonStyle(). - Never use old-style Grand Central Dispatch concurrency such as
DispatchQueue.main.async(). If behavior like this is needed, always use modern Swift concurrency. - Avoid force unwraps and force
tryunless it is unrecoverable. - Never use
Task.sleep(nanoseconds:); always useTask.sleep(for:)instead.
- Use a consistent project structure.
- Follow strict naming conventions for types, properties, methods, and data models.
- Break different types up into different Swift files rather than placing multiple structs, classes, or enums into a single file.
- Write unit tests for core application logic.
- Add code comments and documentation comments as needed.
- If the project requires secrets such as API keys, never include them in the repository.
- Preferred workflow: after any code change run
swift buildto rebuild the project, and runswift testwhen you actually need tests.
- If installed, make sure the
make format&make checkcommands returns no warnings or errors before committing.
- Enforce formatting with the
make formatcommand. - Swift 6.2, prefer strict typing and small files (<500 LOC as a guardrail)
- Naming: types UpperCamelCase; methods/properties lowerCamelCase; tests mirror subject names; avoid abbreviations except common GitHub/API terms.
- Framework: Swift Testing via
swift test. Name suites<Thing>Testsand functionsbehavior(). - Cover new logic. Use deterministic fixtures/mocks for data.
- Run
swift testbefore pushing; prefer adding tests alongside bug fixes.
- Commit messages follow the existing short, imperative style; optional scoped prefixes. Keep them concise; present tense; no trailing period.
- PRs: include a brief summary, linked issue ticket if any.
- Keep GitHub App secrets/private key out of the repo;
- Do not log tokens or traffic stats responses; prefer redacted diagnostics.
- Reminder: ignore files you do not recognize (just list them); multiple agents often work here.