tyler-skills

Strip the tells that make copy read as AI-generated or look cheap. Use when writing or editing any prose, UI copy, headings, commit or PR text, or video text, and before shipping copy review it against this list.

Sequence new product or feature work as a headless "prove" phase that validates the core value on real inputs before any UI, microservices, or scaling. Use at the start of a new product or feature, or once a core engine exists and the user is about to add UI or infrastructure.

Creates precise, modern AWS architecture diagrams as PNGs or Mermaid, grounded in source code, infrastructure code, and current AWS guidance. Use when a user asks for an AWS architecture diagram, cloud topology, runtime or deployment view, failure or recovery flow, AWS service visualization, implementation handoff graphic, or a clean Figma/Linear-style 16:9 diagram with AWS icons.

Make every loading state structurally match its own route's real content so there is zero perceived layout shift. Use when building or reviewing any loading.tsx, skeleton, Suspense fallback, or first-sync/import progress UI. Covers per-route fidelity, accessibility, and never showing "done" or stale data while work is still running.

Decide what to build from real pain and market research, not guesses. Use when the user asks for feature ideas, "what to build next", "wow factor", latent demand, a roadmap, or a competitive gap analysis. Covers researching real pain, the painkiller-not-vitamin test, competitor gap-mapping, and filing the prioritized results as tracked issues.

Applies Linear's UI/UX and product philosophy (design as product judgment, not decoration) when designing, building, or reviewing interfaces and making product decisions. Use when framing a product problem, planning a redesign, deciding scope, reducing visual noise, designing AI/agent interfaces, debating customization vs opinionated defaults, or setting up product process (handoffs, OKRs, A/B testing, design reviews). Triggers on "Linear style," "calm interface," "opinionated software," "is this the right problem," "should we add a setting," "feature request vs need," "redesign strategy," "should this be reversible/undo," "is chat the right AI interface," "novelty vs familiarity." Peer-aware: where Linear's opinions have limits (platforms, APIs as contracts, metrics vs taste, keyboard vs discoverability) it names the boundary and which peer answer applies. Not for cloning the Linear visual look (dark mode, gradients, minimalist landing pages); this is about product method, not the look.

Orchestrate a multi-agent implementation: decompose a task, fan out subagents to implement each piece in parallel, and brief each one with the context it needs plus a mandate to pull fresh docs via Context7. Use when the user wants to "use subagents", "fan out", "parallelize implementation", "orchestrate agents", spin up workers, or build a feature that splits into independent workstreams. Covers Claude Code subagents, Claude Code dynamic workflows, and Codex subagents.

Push the current changes to a pull request, then launch a dynamic workflow that reviews the PR diff, adversarially verifies each finding, and fixes the confirmed ones, pushing the fixes back to the PR. Use when the user wants to "push to a PR and review", "open a PR then review and fix findings", "ship and review", or run a multi-agent review-and-fix pass over a branch. Pairs with orchestrating-subagents (which implements the change first).

Ground implementation work in a high-quality reference repo instead of inventing patterns from scratch. Use when starting work in a framework (TanStack Start, Effect-TS, Next.js) or going for a specific design/style, when the user says "look at how X does it", "use Y as a reference", "match this repo's patterns", or when about to scaffold a feature in an unfamiliar stack. Pairs with grounding-with-context7: docs tell you the API, an exemplar repo shows you how good code actually composes it.

Ground any work with a library, framework, or SDK in current docs via Context7 MCP instead of training data. Use when writing or changing code that touches a package, when verifying existing usage is correct, when auditing whether a tool is being fully leveraged, and when the user says "use context7", "ground with context7", "confirm with context7", or "are we fully leveraging X".