kodekateam/superior-skills

Review or implement interface accessibility for semantics, keyboard operation, focus, contrast, status communication, zoom, and assistive technology. Use when accessibility is explicitly requested, required by the product contract, or a changed interaction creates substantial accessibility risk. Do not activate for every visual edit or use it as a generic design audit.

Implement, harden, or review defensive security controls for REST APIs, including authentication and authorization boundaries, validation, rate limiting, abuse prevention, resource limits, SSRF defenses, safe errors, logging, and security tests. Use when API security, endpoint hardening, threat review, rate limiting, token handling, or sensitive business-flow protection is an explicit concern. Do not use for ordinary endpoint logic without meaningful security scope or for offensive exploitation.

Review a code change, diff, commit, branch, or pull request for actionable defects, regressions, security risks, compatibility breaks, and missing verification. Use when code review is the primary requested outcome. Keep the review read-only unless the user explicitly asks to implement fixes; do not use as a substitute for implementation or a specialized visual audit.

Add, revise, or remove source-code comments while preserving executable behavior. Use for comment-only cleanup, documentation comments, TODO quality, and reducing narration. Do not use when the requested change modifies logic.

Write or revise user-facing product and marketing copy with a specific voice, verifiable claims, natural rhythm, and useful actions. Use for interface labels, onboarding, landing pages, help text, and product messaging. Do not use for code comments or neutral technical documentation unless tone editing is requested.

Design, implement, review, or repair database schemas, queries, indexes, transactions, migrations, and backfills with explicit integrity and rollout constraints. Use when the datastore behavior or data lifecycle is a primary part of the task. Do not use for routine persistence calls whose schema and consistency contracts are unchanged.

Diagnose and repair reproducible, intermittent, environment-specific, or production-observed software failures by tracing evidence to a root cause. Use when a symptom exists but its cause is uncertain or when a proposed fix needs causal validation. Do not use for feature implementation, speculative cleanup, or a general review without a concrete failure.

Design, implement, review, or repair CI/CD pipelines, release artifacts, environment promotion, deployment rollout, verification, and rollback workflows. Use when software delivery or release safety is a primary part of the task. Do not use merely to run an existing local build or to deploy without explicit authorization for the target environment.

Create, reconstruct, synchronize, or automatically record durable repository documentation from current code, configuration, tests, existing docs, and Git history. Use for project context, architecture, decisions, implementation change records, timelines, build and distribution guides, maintenance handoffs, or cross-session continuity. After verified material implementation work, record the outcome by default unless the user explicitly opts out. Do not use for incidental comments or non-material edits.

Simplify coding implementations and reviews by reusing existing capabilities and removing unjustified abstractions, dependencies, configuration, and duplication. Use when implementation complexity or over-engineering is in scope. Do not use to weaken required behavior, safety, accessibility, or compatibility.

Implement or review application behavior, APIs, state transitions, data flow, and business rules with explicit contracts and failure handling. Use for logic-bearing changes across frontend or backend systems. Do not use for visual-only or copy-only work.

Investigate, optimize, or review software performance using representative measurements, profiles, budgets, and regression evidence. Use when latency, throughput, resource use, loading, rendering, bundle cost, or scalability is a primary concern. Do not use for speculative micro-optimization without a symptom, target, or demonstrated bottleneck.

Design, implement, review, or improve operational reliability through service objectives, failure isolation, graceful degradation, recovery, observability, and incident readiness. Use when availability, resilience, dependency failure, disaster recovery, or operability is a primary concern. Do not use for ordinary error handling, a single unexplained bug, or speculative distributed-systems machinery.

Design, implement, or repair responsive web and app layouts across narrow, wide, zoomed, and touch-oriented viewports. Use for mobile and desktop composition variants, reflow, overflow, adaptive navigation, content-driven breakpoints, and mobile interaction layout. Do not use for purely visual styling with no responsive impact.

Design, implement, repair, or review automated tests for observable behavior, regressions, contracts, stateful boundaries, and flaky failures. Use when testing is a primary part of the request or when choosing test levels, isolation, fixtures, or reliability requires dedicated judgment. Do not use merely to run existing checks after an ordinary implementation.

Build, redesign, or visually refine product interfaces using project evidence, real content, functional states, and deliberate composition. Use for implementation work on websites, apps, dashboards, landing pages, or component systems. Do not use for read-only audits or logic-only changes.

Perform a read-only audit of an existing product interface, prove UI findings from governing design evidence and runtime paths, and prepare implementation-ready recommendations or plans. Use for review and design-system drift analysis; do not use when the user asks to implement fixes directly.