Collect findings from other people's writing, with sources

The skill so far only held what we broke ourselves. Most of what is worth
knowing about a new SDK is found rather than suffered — release notes,
other people's articles — and that deserves a place too, on terms that
stay fair to whoever wrote it.

So: entries in our own words, source named and linked, and the one thing
no external article can supply — what it would replace in our code and
whether it is genuinely a step forward. Attribution answers plagiarism,
not copyright, so nothing is pasted; an API signature is a fact, the
paragraph explaining it is not ours to take.

First four entries come from Natalia Panferova's writing at nilcoalescing
.com: the close button role and concentric corners, both of which replace
things we hand-built; ScrollPosition, which replaces one wrapper view;
and the iOS 27 toolbar APIs, which we cannot use at our deployment target
but which would delete a workaround the day we can.

A LICENSE was overdue and now says plainly what is ours, what is Apple's
and stays out of the repository, and what belongs to the authors we cite.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

pdat-swift-practice/skills/apple-findings/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: apple-findings
+description: A curated file of Apple platform APIs worth adopting, each with where we found it and what it would replace in our code — iOS 26 UI affordances (close button role, concentric corners), modern scrolling APIs, and things noted for a later deployment target. Use when reviewing SwiftUI code for outdated patterns, when a hand-built control might have a system equivalent, or when deciding whether a newly published API is worth adopting.
+---
+
+# Findings
+
+Things worth adopting that we found elsewhere — release notes, other
+people's writing, conference talks — written up in our own words with the
+source named, and with the part nobody else can write for us: what it
+would replace in our code and whether it is actually a step forward.
+
+Read `references/` for the individual entries.
+
+| File | Covers |
+|---|---|
+| `references/ios26-ui.md` | `Button(role: .close)`, concentric corners |
+| `references/scrolling.md` | `ScrollPosition` and friends |
+| `references/waiting-on-target.md` | Known, not yet usable at our deployment target |
+
+## How to add an entry
+
+**Write it yourself.** Do not paste someone else's prose or their longer
+code examples. An API signature is a fact and facts are free; a paragraph
+explaining it is their work. Name the source and link it — that is
+courtesy and it lets the next person check whether the entry has aged.
+
+Every entry answers four things:
+
+1. **What it is** — the API, in one or two sentences.
+2. **What it replaces** — the hand-built thing in our code, with the file
+   if we know it. An entry without this is a bookmark, not a finding.
+3. **Whether it is a step forward** — sometimes the honest answer is "no,
+   ours is fine", and that is worth recording so nobody re-litigates it.
+4. **Source** — author, title, link, date read.
+
+If an entry turns out to be wrong or the API changes, fix it in place and
+say so. A stale finding is worse than no finding, because it is quoted
+with confidence.