TomUviandClaude Opus 5 542dd925d0 Record being wrong about which change broke a test
A UI test went red in the same run that adopted three new APIs. The one
touching that screen was reverted; the test still failed. A modifier
order was corrected; still failed. Simulator data was wiped; still
failed. Running it against a clean checkout — which should have been the
first move, not the fourth — it failed there too, with none of the work
present.

The scrolling entry had already been rewritten to explain the fault in
confident detail. That write-up was fiction, so it now says what actually
happened: the API was convicted on circumstance and remains unproven
here, and the one claim that survives is about its two-way binding
costing invalidations.

xcode-practice gets the general lesson, since it will outlive this
particular test: stash and rerun before reasoning about which edit did
it, and a note recording a false cause is worse than no note, because
the next person believes it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-17 01:04:24 +02:00

claude-plugins

PDAT's Claude Code plugin marketplace. One plugin so far, covering Apple platform work; the marketplace is named pdat rather than after a platform so the rest can join it later without a second one.

What is here

pdat-swift-practice — two skills.

apple-findings is a curated file of APIs worth adopting that we found elsewhere: what each one is, what it would replace in our code, whether it is genuinely a step forward, and where we read about it. Written in our own words with sources named — see Sourcing.

xcode-practice is the opposite direction: practices for SwiftUI, Core Data, XcodeGen and Swift Testing that came out of shipping apps: work that must not happen in a view body, blobs that must stay off the main thread, derived collections computed once, Keychain access outside view init, keeping every target of a multi-platform project building, and reading test output correctly.

It deliberately does not restate Apple's own guidance. Where the two overlap, Apple wins.

bin/export-apple-skills.sh — Xcode ships its own skills, written by the framework teams. They are Apple's material, so this repository carries a script to export them rather than a copy of them. Everyone exports from the Xcode they have, which keeps the guidance matched to their SDK.

bin/export-apple-skills.sh .claude/skills

Xcode must be running or the export hangs.

Install

/plugin marketplace add https://git.pda.cz/PDAT/claude-plugins.git
/plugin install pdat-swift-practice@pdat

The repository is public, so the HTTPS URL clones without credentials. Use it rather than the SSH one: /plugin marketplace add rejects an ssh://host:port/... URL, and SSH's shorter git@host:path form has nowhere to put our non-standard port 2222. Pushing here still goes over SSH as usual.

Install at user scope and it applies to every project, including ones that do not exist yet.

To hand it to a team through a repository instead, put this in that project's .claude/settings.json:

{
  "extraKnownMarketplaces": {
    "pdat": {
      "source": { "source": "git", "url": "https://git.pda.cz/PDAT/claude-plugins.git" }
    }
  },
  "enabledPlugins": { "pdat-swift-practice@pdat": true }
}

Two different things are called a source, and they take different types:

  • Marketplace source — where the catalogue itself comes from. That is the block above, and for a git repository the type is git. It is what /plugin marketplace add writes into known_marketplaces.json.
  • Plugin source — where an individual plugin listed in marketplace.json comes from: github, url, git-subdir, npm, archive or command. Ours is a relative path into this repository, so it needs none of them.

Anyone who clones that project gets the skill without installing anything.

Updating

Push a change, bump version in both .claude-plugin/marketplace.json and pdat-swift-practice/.claude-plugin/plugin.json, then /plugin marketplace update locally. Without the version bump, installs will not notice.

Sourcing

apple-findings collects other people's discoveries, so it follows rules that keep it honest and lawful:

  • Write the entry yourself. An API signature is a fact and facts are free to restate. The paragraph explaining it is the author's work, and crediting them does not make copying it acceptable — attribution answers plagiarism, not copyright.
  • Name the source — author, title, publication, date — and link it. Partly courtesy, partly so a stale entry can be checked against the original later.
  • Say what it replaces in our code. This is the half no external article can write, and the reason the file is worth keeping at all.
  • Prefer the vendor's own material where it exists. When Apple's shipped skills cover the same API, defer to them and keep only the "what of ours does this replace" note.

Adding to xcode-practice

The bar is deliberately high: something that actually went wrong, more than once, and whose fix is not obvious from the framework documentation. A rule nobody has been burned by is a rule nobody will follow.

S
Description
No description provided
Readme MIT
67 KiB
0 Stars 9 Watchers 0 Forks
Languages
Shell 100%