
Claude Skills by conectlens
github.com/conectlensReview Supabase RPC/PostgREST API contracts for DTO correctness, response consistency, validation quality, and backward-compatibility risk. Use when changing libs/api/*, shared response types, or API-facing behavior.
Review, modify, and improve the LenserFight CLI at apps/cli/. Covers citty commands, API client integration, output formatting, TUI, and configuration.
Review consistency between API contracts, DTOs, domain types, and consumer expectations. Use for payload design, serialization issues, nullable mismatch, naming drift, and transport/domain boundary checks.
Review PostgreSQL schema design for integrity, performance, and migration safety. Use when modifying supabase/migrations/* or supabase/functions/*.
Perform rigorous, architecture-aware code review focused on subtle correctness bugs, race conditions, performance regressions, type-safety holes, security issues, and maintainability flaws that surface-level review misses. Use when the user asks for comprehensive or deep review, requests design critique, wants edge-case or concurrency analysis, needs production-readiness feedback, or is reviewing critical paths, complex services, transaction handlers, auth flows, infrastructure code, or other...
Create or refine compact technical documentation, READMEs, public docs, and contribution guides. Use for OSS-facing docs, internal docs cleanup, navigation design, and converting implementation details into concise Claude-style markdown.
Decide where new behavior belongs across apps, features, domain, data, api, ui, infra, and utils. Use before implementing a feature, refactor, or cross-layer change in the LenserFight monorepo.
Read GitHub issues, triage them, solve them using GRASP/OOAD principles, run or add tests, commit, push, open a PR linked to the issue, merge into development, and close the issue only after merge. Use when the user says /github-issue-solver, "solve issue #N", "fix GitHub issue", or "work on issue".
Review design decisions using GRASP, OOAD responsibility assignment, and standard refactoring rules. Use when code placement, object responsibility, coupling, cohesion, or refactoring direction is unclear.
Add or localize LenserFight for a new language or locale. Use when asked to add, implement, port, or support translations for feature-owned locale bundles in libs/features, the forum app runtime locale controller, docs, or language preference flows.
Assess Supabase/Postgres migration blast radius, rollback difficulty, data loss risk, permission regression risk, and rollout safety. Use before applying migrations to shared environments or bundling schema changes into a release.
Deprecated alias for the canonical `mobile-ruleset` mobile workspace rules.
Use when designing or refining Expo Go React Native screens in apps/mobile, with separate iOS and Android considerations, to keep the UI minimalist, performant, and aligned with the shared native design system.
Use when implementing new mobile features in apps/mobile or libs/* with Expo/React Native and the shared mobile design system.
Use when planning mobile app features, roadmaps, or research-backed product decisions for apps/mobile.
Use when reviewing apps/mobile or libs/* for mobile performance, security, storage, network, permissions, or render-cost risks.
Use when validating language preferences, locale resolution, onboarding localization, or in-app language settings across the current LenserFight file tree.
Shared mobile workspace rules for apps/mobile and libs/* in lenserfight. Use when navigating native UI boundaries, shared tokens, verification defaults, or the canonical mobile design ruleset.
The strategic authority for LenserFight. Translates ambiguous requests into product decisions, scope cuts, acceptance criteria, and implementation priorities.
Review whether a change set is ready for release across code, migrations, tests, docs, and rollout planning. Use before production releases, high-risk merges, or milestone sign-off.
Audit Nx monorepo structure, layer responsibilities, dependency drift, public APIs, and misplaced logic. Use for architecture review, library placement, boundary erosion, duplication, and repo health checks.
Enforce performance-safe query and rendering patterns across this Nx monorepo. Use when working on Vite freezes, Supabase overfetching, pagination, caching, CPU hotspots, memory pressure, or large seeded datasets.
Review repositories, cache behavior, data-access boundaries, and error mapping. Use when persistence code becomes leaky, caching is suspicious, or feature code reaches into transport/storage details.
Review LenserFight security for selected modules or scopes using architecture-aware, low-coupling, high-cohesion rules. Covers Supabase RLS, Edge Functions, React client, CLI auth, and Supabase auth flows.
Detect staged and unstaged git changes, classify them by type (feat/fix/refactor/docs/chore/test/style/perf), group into logical commit units, then commit each group separately with user approval. Use when the user wants to commit their current work, wants help writing a commit message, or says /commit or /smart-commit.
Review Supabase SQL functions, RPC exposure, return contracts, and API-facing database surfaces. Use for public API design, function hardening, response stability, and deciding between direct table access and RPC.
Review Postgres indexes, triggers, write amplification, and performance risk in Supabase migrations. Use for slow queries, missing indexes, trigger-heavy designs, stale propagation issues, and DB-side performance tuning.
Review Supabase RLS, grants, schema exposure, views, and SQL function privilege boundaries. Use for policy design, auth-sensitive migrations, exposed-schema review, security-definer risk, and least-privilege database hardening.
Review Supabase/Postgres schema design, table ownership, normalization, defaults, relationships, and migration coherence. Use for new tables, column design, view design, schema cleanup, and database modeling decisions.
Review Tailwind-based UI for consistency, accessibility, responsiveness, interaction states, and maintainability. Use for design system drift, component polish, UX quality, or accessibility review.
Guard shared UI contracts across web and mobile in lenserfight. Use when editing libs/ui, shared components, design tokens, hooks, or platform-specific entrypoints such as index.ts and index.native.ts.
Plan test coverage by layer, risk, and behavior. Use when adding features, fixing regressions, or deciding what to test in domain, data, UI, and integration layers.
Review and improve automated tests for NestJS modules, contracts, and critical flows. Use when changing services, controllers, guards, repositories, billing, wallet, execution, or auth behavior.
Review Vite app performance, bundle shape, route splitting, assets, rendering cost, and caching strategy. Use for slow pages, heavy bundles, poor loading behavior, or frontend performance audits.
Use when planning or coordinating implementation of profile privacy, followers/following, restricted profile access, and account lifecycle across frontend, database, and policy layers.
Use when converting ambiguous privacy, follower, deletion, and friendship product requirements into explicit platform policy and state-transition rules.
Use when designing Postgres/Supabase schema, triggers, helper functions, and query patterns for follows, follower requests, mutuals, blocks, counters, and profile access relationships.
Use when implementing RLS, account state enforcement, soft deletion, legal retention boundaries, cancellation on login, and pg_cron purge workflows in Supabase/Postgres.
Use when implementing the /lenser route, restricted profile shell, lock-state UI, follow request UX, and route-state rendering for public, private, deactivated, and deleted profiles.
Use when designing feed, discovery, recommendation, and social-graph ranking rules that depend on follows, mutuals, privacy state, and account lifecycle.
Use when validating schema migrations, privacy regressions, deletion workflows, sign-in cancellation logic, and rollout safety for social graph and profile access changes.
Define i18n and internalization rules for forum (React/i18next) and docs (VitePress locales) apps. Use when adding new UI strings, translating docs, adding new locales, checking language consistency, or setting up hreflang SEO for multilingual pages.
Link workspace packages in monorepos (npm, yarn, pnpm, bun). USE WHEN: (1) you just created or generated new packages and need to wire up their dependencies, (2) user imports from a sibling package and needs to add it as a dependency, (3) you get resolution errors for workspace packages (@org/*) like "cannot find module", "failed to resolve import", "TS2307", or "cannot resolve". DO NOT patch around with tsconfig paths or manual package.json edits - use the package manager''s workspace comman...
Monitor Nx Cloud CI pipeline and handle self-healing fixes. USE WHEN user says "monitor ci", "watch ci", "ci monitor", "watch ci for this branch", "track ci", "check ci status", wants to track CI status, or needs help with self-healing CI fixes. Prefer this skill over native CI provider tools (gh, glab, etc.) for CI monitoring — it integrates with Nx Cloud self-healing which those tools cannot access.
Generate code using nx generators. INVOKE IMMEDIATELY when user mentions scaffolding, setup, structure, creating apps/libs, or setting up project structure. Trigger words - scaffold, setup, create a ... app, create a ... lib, project structure, generate, add a new project. ALWAYS use this BEFORE calling nx_docs or exploring - this skill handles discovery internally.
Import, merge, or combine repositories into an Nx workspace using nx import. USE WHEN the user asks to adopt Nx across repos, move projects into a monorepo, or bring code/history from another repository.
Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
Explore and understand Nx workspaces. USE WHEN answering questions about the workspace, projects, or tasks. ALSO USE WHEN an nx command fails or you need to check available targets/configuration before running a task. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What depends on library Y?', 'What targets can I run?', 'Cannot find configuration for task', 'debug nx task failure'.
Review design decisions using GRASP, OOAD responsibility assignment, and standard refactoring rules. Use when code placement, object responsibility, coupling, cohesion, or refactoring direction is unclear.