CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

passkit

Integrate Apple Pay payments and Wallet passes using PassKit. Use when adding Apple Pay buttons, creating payment requests, handling payment authorization, adding passes to Wallet, configuring merchant capabilities, managing shipping/contact fields, or working with PKPaymentRequest, PKPaymentAuthorizationController, PKPaymentButton, AddPassToWalletButton, PKPass, PKAddPassesViewController, PKPassLibrary, Wallet pass distribution, or Apple Pay checkout flows for physical goods, real-world services, donations, and eligible recurring payments.

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Medium

Suggest reviewing before use

The canonical home for this skill is dpearson2699/swift-ios-skills

SKILL.md
Quality
Evals
Security

Quality

Content

85%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, code-first skill: clear sequenced workflow with validation gates, appropriate offloading of advanced patterns to a one-level reference, and a useful review checklist. The only deductions are minor — some repeated scope phrasing, one meta-sentence, and a few code placeholders for app-specific helpers.

Suggestions

State the "physical goods, real-world services, donations, and eligible recurring payments" scope once (e.g., in the intro or Common Mistakes) and reference it from the checklist instead of repeating it verbatim three times.

Remove or rewrite the meta-sentence "Name invalid-data and invalid-signature failures explicitly instead of hiding them behind a bare try? in review guidance" as user-facing guidance (e.g., "Surface invalid-data and invalid-signature errors to the user rather than swallowing them with try?"), and drop the try? usage in the SwiftUI wallet example accordingly.

Flesh out the code examples that rely on undefined helpers — show the paymentService.process call as a clearly-marked stub comment, and place the addPassToWallet example inside a view-controller context so present() is unambiguous.

DimensionReasoningScore

Conciseness

The body is dominated by executable code with terse, non-obvious domain guidance (e.g., "PassKit amount APIs take NSDecimalNumber, not Double"; "The last item in paymentSummaryItems is treated as the total"), fitting the 4 anchor ("Efficient; minor instances of over-explanation that could be trimmed"). It is not a 5 because the scope phrase "physical goods, real-world services, donations, and eligible recurring payments" is repeated three times (intro, Common Mistakes, checklist), and the sentence "Name invalid-data and invalid-signature failures explicitly instead of hiding them behind a bare try? in review guidance" is meta-commentary about the skill itself rather than user-facing instruction.

4 / 5

Actionability

Concrete, mostly copy-paste-ready Swift covers all common cases (availability check, both button APIs, request construction, presentation with delegate retention, authorization, shipping updates, pass adding, pass library), matching the 4 anchor. It falls short of 5 because several examples invoke undefined helpers — `paymentService.process(payment.token)`, `recalculateItems(with:)`, `showRecoverablePassError(error)`, and a bare `present(addController, animated: true)` with no enclosing view-controller context — leaving minor gaps the reader must fill.

4 / 5

Workflow Clarity

The sections form a coherent build sequence (Setup → availability check → button → payment request → present sheet → authorization/shipping → wallet passes) with explicit validation checkpoints (canMakePayments before showing UI, canAddPasses before add-pass UI, present completion handling, catch-and-surface for invalid pass data) and a full Review Checklist, matching the 5 anchor's "clear sequence with explicit validation steps ... checklists for complex processes". It is not a 4 because the key checkpoints are explicit rather than implicit.

5 / 5

Progressive Disclosure

The bundle structure matches the 5 anchor: SKILL.md holds the common flows inline, while advanced material (recurring/deferred payments, coupons, multi-merchant, pass bundles, pass update web services) is split into a single one-level-deep file that is clearly signaled twice ("read references/wallet-passes.md" in Checking Pass Library, and again in References) and verified to exist with no nested references. A Contents TOC plus per-section headings make navigation easy; the reference file itself is self-contained with its own internal TOC.

5 / 5

Total

18

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is exemplary: a concrete 'what' statement followed by an explicit 'Use when' clause enumerating both natural-language triggers and API names, with scope qualifiers that distinguish it from adjacent skills. It is dense but every element is a concrete trigger rather than padded fluff.

DimensionReasoningScore

Specificity

The description lists multiple specific concrete actions — "adding Apple Pay buttons, creating payment requests, handling payment authorization, adding passes to Wallet, configuring merchant capabilities, managing shipping/contact fields" — giving comprehensive coverage of the skill's capabilities. This matches the 5 anchor ("Lists multiple specific concrete actions; comprehensive coverage"); it is not a 4 because coverage has no minor gaps, and not below 5 because every action is concrete rather than generic.

5 / 5

Completeness

It explicitly answers both questions: what ("Integrate Apple Pay payments and Wallet passes using PassKit") and when ("Use when adding Apple Pay buttons, ... or Apple Pay checkout flows for physical goods, real-world services, donations, and eligible recurring payments"). This is the 5 anchor verbatim in structure — clear what plus an explicit 'Use when' with concrete trigger phrases — so the 4 anchor ('when' could be more explicit/specific) does not apply.

5 / 5

Trigger Term Quality

Natural user phrases ("Apple Pay", "Apple Pay buttons", "checkout flows", "passes to Wallet", "shipping/contact fields") are combined with API-name synonyms users would surface ("PKPaymentRequest, PKPaymentAuthorizationController, PKPaymentButton, ... PKPassLibrary"), matching the 5 anchor's comprehensive coverage including synonyms. It exceeds the 4 anchor, where natural terms would be missing, and shows no jargon-only or generic phrasing that would place it at 3 or below.

5 / 5

Distinctiveness Conflict Risk

It carves a clear niche (PassKit/Apple Pay/Wallet) with distinct triggers — API class names plus the scope qualifier "for physical goods, real-world services, donations, and eligible recurring payments", which explicitly separates it from a StoreKit/in-app-purchase skill. Minimal conflict risk per the 5 anchor; it is not a 4 because there is no meaningful overlap risk with closely related skills given the framework-specific triggers.

5 / 5

Total

20

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

dpearson2699/swift-ios-skills

Path

skills/passkit/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.