ios-feature-implementation

Files (1)

• SKILL.md

SKILL.md (first lines)

# iOS Feature Implementation

A disciplined inspect → explain → implement → verify loop for feature work
in an existing codebase. Do not skip straight to editing files.

## 0. Expected request shape

A well-formed feature request names, at minimum:

- **What to build** — the feature/behavior in plain language.
- **Existing context** — the specific screen(s), ViewModel(s), API(s),
  and model(s) already involved, by name.
- **Requirements** — the specific behaviors the finished feature must have.
- **Constraints** — minimum iOS version, dependency policy, "follow
  existing architecture", "reuse existing components", "don't touch
  unrelated files".

If a request is missing this (e.g. "add a favorites feature" with nothing
else), ask for the specific existing files involved before inspecting —
guessing which ViewModel or API is "the" relevant one wastes the
inspection step below.

## 1. Inspect before touching anything

Read, in this order, before writing a single line:

1. **The existing feature/screen this touches.** Read the actual current
   implementation, not a description of it — a stale comment or README is
   not the source of truth (if the codebase is undocumented or you can't
   tell what's current, use `ios-legacy-auditor` first).
2. **The existing business logic it must integrate with or not break.**
   Trace what the current ViewModel/service actually does with the data
   today — validation rules, edge cases already handled, state machines,
   pricing/eligibility logic, anything with branching. New code that
   duplicates or silently diverges from existing business rules is a
   correctness bug even when it compiles and looks clean.
3. **The API/model layer** it will call into or extend — actual current
   signatures and types, not remembered ones.
4. **Nearby reusable components** — check for an existing view, view
   modifier, or helper before writing a new one; constraints usually say
   "reuse existing components" for a reason.
5. **Existing API/networking behavior on this path** — the actual
   current auth-header handling, retry/timeout policy, offline/error
   handling, and response caching for the endpoint(s) involved. New code
   that silently drops an existing retry or error-mapping behavior is a
   regression even if the happy path works.
6. **Existing security posture for this data path** — how any
   credential, token, or sensitive field involved is stored and
   transmitted today (Keychain vs. `UserDefaults`, TLS/ATS settings,
   whether it's ever logged elsewhere). Carry the existing posture
   forward; don't introduce a weaker one for convenience (e.g. caching a
   token in `UserDefaults` because it's easier than reusing the existing
   Keychain wrapper).

Do not modify files during this step.

## 2. Explain before implementing

Present, in this order, before writing implementation code:

1. **Existing architecture** — the pattern actually in use in the touched
   area (may not match what the rest of the app does — say so if not).
2. **Files that need modification** — exact paths, and for each, what
   changes and why.
3. **Proposed implementation** — concrete enough to review: new
   types/methods with real signatures, not just prose.
4. **Potential risks** — what could break, what's ambiguous in the
   requirements, anything the constraints make harder (e.g. "no new
   dependencies" ruling out the obvious library for this).

If the codebase's current architecture is unclear or looks like it may
not match assumptions, use `ios-architect` for the structural judgment
call before proposing an approach.

## 3. Implement

- Match the existing architecture and style in the touched files —
  this is not the place to introduce a different pattern, even a better
  one, unless the request explicitly asks for a refactor.
- Respect every stated constraint literally: if minimum iOS is 14, don't
  use an iOS 15+ API without an availability check; if "no new
  dependencies", don't add one even for a one-line convenience.
- Touch only the files identified in step 2. If implementation reveals
  that another file must change too, say so explicitly rather than
  silently expanding scope.
- Follow `ios-testing-strategy` for any new tests this feature needs.

## 4. Verify

Run and report on each of the following — don't skip one because it
seems obviously fine:

1. **Build** — the project actually compiles. If the `ios-simulator`
   MCP server is configured (see this repo's `.mcp.json` and README),
   `build_project` gives a structured result instead of parsing raw
   `xcodebuild` output; otherwise run `xcodebuild` directly.
2. **Tests** — run the relevant test target(s), report pass/fail counts
   (`run_tests` via `ios-simulator-mcp`, or `xcodebuild test` directly).
3. **API availability** — every API used is available at the stated
   minimum iOS version, or is properly `#available`-guarded. If the
   `ios-agent` MCP server is configured, `mcp__ios-agent__check_availability_guards`
   also catches the less obvious mistake: a guard set to a *higher* iOS
   version than the API actually requires, which silently drops support
   for every device between the true minimum and the guard's version.
4. **Retain cycles** — see the Memory & Performance Review below.
5. **Concurrency** — new `async`/actor-isolated code doesn't introduce a
   data race or an accidental main-thread block; existing concurrency
   model in the touched files is preserved, not mixed with a new one.
6. **Memory implications** — see the Memory & Performance Review below.
7. **Performance implications** — no new unbounded main-thread work
   (image decode, JSON parsing, file I/O) introduced on a hot path.
8. **Security** — see the Security Review below.
9. **Review the diff** — read your own changes once, end to end, before
   reporting done; look for anything outside the files named in step 2.

## Memory & Performance Review

For any feature involving images, networking, WebViews, large
collections, caching, Core Data, PDF, or media, check all of the

From apexbymanish/claude-ai-agents-ios, MIT.

More from apexbymanish/claude-ai-agents-ios