// // AGENTS.md // feather-openapi // // Created by Binary Birds on 2026. 01. 20.
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.