cupertino

Plugin cupertino from marketplace werkstoff in Anselmoo/werkstoff. Commands read from the repo's manifest — 11 days ago.

Skills (16)

• cupertino-backwards

  Use FIRST, before cupertino-focus or any other cupertino technique, whenever customer experience and technology choices are both still undecided for a new feature or project scope. This is a pre-architecture gate: it establishes what experience actually matters before any technology direction is cho

• cupertino-cannibalize

  USER-INVOKED ONLY — never automatic, never run as part of cupertino-review's pipeline or any other automatic stage. Use only when the user explicitly asks, on a deliberate post-ship cadence, whether to replace a currently-successful, load-bearing thing with a better successor built in-house — the iP

• cupertino-council

  Use at UI/frontend build-time, before writing any code, whenever a user-facing interface or screen is being designed. Trigger on 'design this screen', 'build this UI', 'make this feel premium', 'this feels generic', or any request to design or implement a user-facing surface. Applies to any stack (H

• cupertino-elevate

  Use at build-time, ONLY when a low-status commodity feature already in scope for the current build — error messages, logs, config, settings, onboarding, migrations, loading states, empty states, backups, status output — could be transfigured into something beloved, the way Apple turned boring backup

• cupertino-focus

  Use immediately after cupertino-backwards has established the customer experience, to reduce a sprawling portfolio of shipped and planned products, feature lines, modes, or variants down to the smallest focused set before architecture work commits effort. Trigger on requests like 'we have too many m

• cupertino-handbook-apply

  Use before starting new work in a domain that already has a drafted handbook, to pull in only the constraints and exceptions relevant to the upcoming task rather than dumping the whole document. Trigger on 'what does our handbook say about this', 'apply our code standards to this task', or naturally

• cupertino-handbook-check

  Use when the user wants to compare new or changed work against an existing domain handbook at .cupertino/DOMAIN-handbook.md (one file per domain) to find divergence. Trigger on 'does this comply with our handbook', 'audit these files against the code handbook', 'check this against the code handbook'

• cupertino-handbook-draft

  Use when the user wants to create and persist a durable handbook for one domain — design, code, testing, or documentation — capturing the project's actual conventions (or honest scaffolded defaults where none exist) as a checkable rule per dimension. Trigger on 'write a code handbook', 'draft our de

• cupertino-handbook-fix

  Use only when the user has explicitly enabled fix mode for a domain, to apply the mechanical findings from a prior cupertino-handbook-check pass. Trigger only on explicit requests like 'fix the mechanical handbook findings' AFTER the user has turned on fix mode — never infer consent from a check rep

• cupertino-integrate

  Use at architecture-decision time, together with cupertino-longevity, to decide whether one specific seam — a boundary between layers, APIs, or ownership — is worth owning tightly versus delegating to a vendor or framework. Trigger on 'should we build or buy this', 'own vs delegate', 'vendor this pi

• cupertino-longevity

  Use at architecture-decision time, together with cupertino-integrate, to evaluate whether an architecture, API surface, or codebase structure can evolve incrementally or will force a future rewrite. Trigger on 'will this scale', 'future-proof this', 'API versioning strategy', 'will I regret this arc

• cupertino-prototype

  Use at build-time, parallel to cupertino-council, whenever a specific empirical uncertainty needs settling by actually building and running a throwaway version rather than debating it in the abstract. Trigger on 'not sure if this approach will actually work', 'let's spike this', 'will this library e

• cupertino-repair

  Use when something that already exists must be changed without breaking it -- fix, repair, adjust, extend, add to, or delete part of an existing dashboard, page, UI, CLI, library, build, kernel or platform. Trigger on 'fix this dashboard', 'this layout is broken on mobile', 'repair this', 'make X wo

• cupertino-reveal

  Use at ship-time, as the last automatic step for a finished feature, module, tool, or API, to deliver exactly one non-obvious, high-leverage addition in a keynote 'and one more thing' structure. Trigger on 'what's missing here', 'is there anything else this needs before shipping', or automatically a

• cupertino-review

  Use when a project spans multiple lifecycle moments and the user wants the whole cupertino discipline applied end-to-end in one pass — 'give this the full cupertino treatment', 'review this like Apple would', 'run the whole design lifecycle on this'. Composes the plugin's other techniques as fixed,

• cupertino-unbox

  Use at build/finishing-time, after core feature work has produced something worth a new user's first five minutes, to redesign the actual first-run, onboarding, or install flow. Trigger on 'improve onboarding', 'first-run experience', 'unboxing', 'install flow', 'first five minutes'. Scope is strict

Subagents (4)

• handbook-dimension-analyst

  Use when dispatched by cupertino-handbook-draft to analyze a project for exactly one named handbook dimension and propose a single concrete, enforceable rule with real file:line evidence or an honestly-labeled scaffolded default. Also used, given an already-proposed candidate, to independently re-de

• handbook-drift-auditor

  Use when dispatched by cupertino-handbook-check to check a specific set of target files against exactly one named handbook rule, reporting every divergence with file:line evidence. Also used to independently re-open one already-proposed candidate finding's exact file:line and confirm it is real, not

• handbook-remediator

  Use when dispatched by cupertino-handbook-fix to apply one already-verified mechanical:true design-handbook finding's exact rewrite at its cited location, and nothing else. Findings originate only from cupertino-handbook-check's design/UI handbook rules — not for language-idiom or modernization rewr

• handbook-verifier

  Use immediately after handbook-remediator applies a fix, to independently judge whether the file now satisfies the handbook rule the original finding cited. Deliberately blind to the remediator's own output: the dispatch prompt contains only the handbook rule text, the original pre-fix violation evi

Hooks (1)

• PreToolUse

  python3 -B "${CLAUDE_PLUGIN_ROOT}/hooks/pretooluse_guard.py"

Similar plugins