| name | swift-feature-implementation |
| description | Use for implementing a non-trivial Swift 6.3 feature, bug fix, or refactor. It coordinates repository inspection, relevant domain skills, implementation, and proof; it does not authorize unrelated cleanup. |
Swift feature implementation
Own the requested behavior from baseline to proof. Route domain knowledge only when the task needs it.
Workflow
- Read repository instructions, inspect the affected targets and call sites, and state the user-visible behavior and invariant.
- Establish a baseline: reproduce the bug, run focused tests, or record the current behavior. Identify existing edits and preserve them.
- Select the smallest relevant domain skills from the routing map; do not load the entire suite. Identify a design that fits existing ownership, isolation, and boundary conventions.
- Write or update a failing focused test when behavior is missing. Implement the smallest coherent change, keeping unsafe/effectful code at its boundary.
- Run formatter/linter, focused tests, target tests, and the repository's real gate. Add adversarial cases for malformed input, errors, cancellation, lifetime, and compatibility when relevant.
- Review the diff for scope, API, ownership, concurrency, performance claims, and test quality. Report failures as code, infrastructure, or unavailable platform evidence.
Read references/implementation-checklist.md when the task spans multiple targets or has a release boundary.
Guardrails
- Do not weaken strict concurrency, remove tests, broaden public API, or add compatibility shims to make the change easier.
- Do not call a focused pass a full repository gate.
- Do not claim hardware/private-API behavior from a host-only test.
Completion contract
Summarize behavior, invariant, files changed, checks run and their scope, manual evidence, and any remaining proof gap.
