pavel-d/ai-skills

Design, implement, or review interfaces for iOS, iPadOS, macOS, watchOS, tvOS, and visionOS using Apple's Human Interface Guidelines, including foundations, patterns, components, inputs, and system integrations. Use for Apple platform UX decisions and HIG reviews; not for generic web styling, backend architecture, or API implementation without a design question.

Review code against Clean Architecture and Domain-Driven Design rulebooks and report violations. Use when reviewing a diff, branch, pull request, or module for boundary violations, dependency-direction problems, framework or persistence leakage into the domain, anemic domain models, primitive obsession, bad aggregate boundaries, god services, layer bypass, or bounded-context leakage — and before merging a change that adds or reshapes layers, aggregates, repositories, or integrations. Do not use for style, formatting, performance, or security review, or for codebases that have deliberately chosen a different architectural style.

Carry a code change or GitHub pull request through its authorized delivery stage, including review, CI, merge, image publication, automatic deployment, and live verification when requested. Use for implementation, fixes, refactors, and PR delivery; not for read-only questions, status lookups, or unrelated work.

Apply Robert C. Martin's Clean Architecture when writing, placing, reviewing, or refactoring application code — the dependency rule, layer responsibilities, use-case boundaries, ports and adapters, and keeping frameworks, databases, and UI as replaceable details. Use when adding a feature to a layered codebase, deciding which layer new code belongs in, designing module or package structure, introducing an interface for an external dependency, reviewing a diff for boundary violations, or breaking up a god service. Do not use for throwaway scripts, one-file prototypes, config-only edits, or codebases that have deliberately chosen a different architectural style.

Apply Eric Evans' Domain-Driven Design when modeling a business domain — ubiquitous language, bounded contexts, entities vs value objects, aggregate boundaries, repositories, factories, specifications, and anti-corruption layers. Use when naming domain concepts, deciding whether something is an entity or a value object, drawing aggregate or transaction boundaries, integrating with another system's model, replacing primitives that carry business meaning, extracting rules from repeated conditionals, or reviewing code for a passive/anemic domain model. Do not use for CRUD-only supporting subdomains, technical infrastructure with no business rules, or codebases where the domain is genuinely trivial.

Orchestrate an authorized penetration test by fanning work out to parallel subagents — reconnaissance, API/auth mapping, web/API/cloud/auth/business-logic testing, and synthesis. Use when the engagement is authorized in writing, scope is locked in a scope.json, and you are coordinating a multi-agent pentest (recon fan-out, Phase A foundation → Phase B fan-out → synthesis). Do not use without a signed/authorized scope, for testing assets you do not own or control, or for any destructive, DoS, social-engineering, physical, or real-PII-exfiltration activity.