godmode

Use when starting any conversation - establishes how to locate and invoke skills, mandating Skill tool usage before ANY response including clarifying questions

Use when building ANY website, web app, landing page, or web-based UI - searches real template marketplaces for professionally designed layouts in the user's industry or niche, then extracts layout structure, color palettes, typography choices, and section sequences as the design blueprint instead of generating from assumptions

Use when about to build any feature, library, or system - searches GitHub and package registries for existing implementations to study, harvest patterns from, or use directly instead of building from scratch

Use when starting any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation.

Use when making technology, hosting, or infrastructure decisions — recommends services, databases, and deployment strategies based on project requirements and what the user actually has available

Use when starting a session, running shell commands, installing packages, or diagnosing platform-specific failures - detects OS, shell, runtime, package manager, and toolchain before any command execution

Use when a task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research, multi-module features, cross-layer changes, or competing hypothesis debugging. Not for simple independent tasks (use parallel-execution) or sequential tasks (use delegated-execution).

Use when repeated fix attempts fail, the agent appears stuck in a loop, or complexity is increasing without progress

Use when a user requests new work - features, components, integrations, or additions - to challenge assumptions, evaluate effort, surface alternatives, and ensure the work is worth doing before committing to it

Use when building ANY feature within an existing project - search the current codebase for existing patterns, conventions, similar implementations, and established approaches before writing new code

Use when implementing any substantial feature, multi-file modification, or architectural change - produces a plain-language walkthrough of every alteration so the developer can verify genuine understanding before committing, preventing the accumulation of cognitive debt where code ships faster than comprehension

Use when operating in a codebase that employs an existing design system (shadcn/ui, Material UI, Ant Design, Chakra, etc.), when you need to identify which system a project uses, or when setting up a design system for a project that lacks one

Use when completing any meaningful task - distill patterns, lessons, and insights from the interaction and persist them for future sessions

Use when contributing code to an existing project - guarantees that every new line mirrors the established conventions, naming schemes, architectural layering, directory layout, and stylistic choices already present in the codebase rather than drifting toward generic AI defaults

Use when performance is a concern - sluggish pages, slow queries, bloated bundles, high-latency APIs, or whenever someone says "optimize" or "make it faster"

Use when launching a new project, initializing a repository, or building a codebase from the ground up - addresses directory structure, tooling configuration, linting, testing infrastructure, CI/CD pipelines, and version control setup

Use when building ANYTHING - the universal reference-first system that routes every task to proven reference implementations instead of generating from assumptions. Covers API design, database schemas, testing strategies, CI/CD pipelines, code patterns, DevOps, and any other domain where professional reference implementations exist

Use when writing code that processes user input, manages authentication or authorization, constructs database queries, handles file operations, interacts with external data, exposes API endpoints, or manages secrets - any code that crosses a trust boundary

Use when building any feature, API, module, or system before writing implementation code - produces a structured behavior specification defining inputs, outputs, constraints, edge cases, and acceptance criteria as the authoritative artifact

Use when constructing frontend components, selecting layout strategies, orchestrating state, or assembling interactive UI - spans component architecture, responsive adaptation, accessibility compliance, and rendering performance across any frontend framework

Use when building ANY user interface - web app, game, CLI, dashboard, landing page, or component - ensures all UI output references documented UX patterns instead of generating from assumptions, preventing the amateur look of AI-generated UI

Use when dispatching subagents, composing prompts for teammates, structuring handoff reports, or managing context boundaries between agents. Covers both subagent prompts and team-level messaging.

Use when executing implementation plans with independent tasks in the current session

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when creating new protocols, editing existing protocols, or validating protocols work before deployment

Use when finishing tasks, shipping significant features, or before landing changes to ensure work meets standards through automated review

Use when you have a spec or requirements for a multi-step task, before touching code

Use when starting feature work that needs isolation from the current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

Use when about to declare work done, fixed, or passing, before committing or opening PRs - demands executing verification commands and reading their output before making any success assertions; evidence precedes claims always

Use when implementation is finished, tests are green, and you need to decide how to land the work - presents structured integration paths for local merge, pull request, deferral, or abandonment

Use when facing 2+ tasks that share no state and have no sequential dependencies - enables concurrent investigation or implementation by dispatching one agent per isolated problem domain

Use when preparing code for commit, PR, or merge - covers linting, type safety, bundle budgets, coverage thresholds, complexity limits, dependency audit, and dead code detection

Use when processing code review feedback before making changes, particularly when suggestions are ambiguous, technically suspect, or span multiple interdependent items - demands verification and technical rigor over compliance theater

Use when making technology or structural decisions - selecting databases, APIs, auth strategies, caching layers, file organization, or weighing monolith against services

Use when you have a written implementation plan to execute in a separate session with review checkpoints

Use when implementing any feature or bugfix, before writing implementation code