Плагин godmode

Designs and runs reproducible evaluations for AI agents, prompts, tools, skills, and model-backed workflows using realistic datasets, isolated baselines, objective assertions, rubric grading, trajectory analysis, cost/latency tracking, and regression comparison. Use when measuring agent quality, optimizing skill triggering, comparing prompts or models, or gating an AI feature release. Not for ordinary deterministic unit tests.

Designs or reviews HTTP, REST, GraphQL, RPC, CLI, webhook, event, and service interfaces with explicit inputs, outputs, errors, compatibility, idempotency, pagination, authentication, versioning, and observability. Use when introducing or changing an API or cross-component contract. Not for internal implementation details with no boundary or for debugging one API failure; use root-cause-debugging there.

Reviews an existing codebase for structural friction, unclear ownership, leaky or shallow interfaces, excessive coupling, misplaced state, poor testability, and risky dependency direction, then prioritizes evidence-backed improvement candidates. Use for architecture audits, modularization, modernization, or recurring cross-cutting change pain. Not for designing one new interface, simplifying a local function, or fixing a reproduced bug.

Validates a running application, CLI, API, service, or generated artifact as a user or operator against a prewritten observable behavior contract while remaining source-blind. Use for acceptance checks, runtime proof, anti-fake probes, release smoke tests, or an independent companion to code review. Not for source-quality findings, root-cause diagnosis, or visual design judgment outside the contract.

Closes a completed development branch by checking the final diff and proof, presenting merge, pull-request, keep, or discard options, and cleaning up only after the user or repository workflow chooses a path. Use when feature work is complete and the branch must be integrated or retired. Not for claiming a feature is complete before verification.

Tests a real web user flow with a browser by asserting semantic behavior, network and loading states, keyboard access, responsive layouts, and stable visual evidence. Use for browser bugs, end-to-end UI behavior, responsive or accessibility checks, and screenshot baselines. Not for static source review without a browser or for backend-only tests.

Simplifies recently changed or explicitly scoped code while preserving observable behavior, error semantics, side effects, ordering, and public contracts. Use for readability cleanup, dead-code removal, reducing nesting, eliminating redundant wrappers, or making an implementation easier to maintain. Not for architecture redesign, new behavior, speculative cleanup, or a refactor without an adequate safety net.

Maps an unfamiliar or large codebase before implementation by locating entry points, ownership, execution paths, conventions, tests, dependencies, change hotspots, and unresolved questions. Use when onboarding to a repository, scoping a cross-cutting change, preparing a handoff or reusable CodeTour, explaining a subsystem, or when the agent is guessing where behavior lives. Not for diagnosing one reproduced failure or designing a new architecture before the current system is understood.

Verifies a completion, fix, passing, compatibility, release, or readiness claim with fresh task-specific evidence mapped to the actual requirements. Use before saying a change is done, before merge, after review fixes, and at release gates. Not a substitute for diagnosing the cause of a failing check.

Designs or reviews relational, document, key-value, graph, or search data models with ownership, invariants, access paths, migrations, consistency, retention, privacy, and recovery behavior. Use for schema changes, new data stores, indexes, migrations, persistence boundaries, or query-driven design. Not for a query-only bug without a model change or for API contract design.

Splits a coding task into independent parallel agent workstreams with disjoint write sets, explicit inputs and outputs, dependency ordering, and a merge/review plan. Use when several subtasks can proceed without shared mutable state. Not for tightly coupled edits, one failing root cause, or parallel changes to the same files.

Writes or updates engineering documentation and architecture decision records from repository facts, explicit assumptions, trade-offs, and verification links. Use for README changes, design docs, runbooks, ADRs, migration notes, and contributor documentation. Not for implementation planning alone or for copying external documentation without provenance.

Designs, builds, or refactors user-facing web or application interfaces with deliberate visual direction, typography, color and spacing tokens, content hierarchy, responsive behavior, accessible interaction states, and real rendered-surface verification. Use for pages, components, dashboards, landing pages, design systems, and frontend polish. Not for backend logic, API-only work, or visual claims that cannot be rendered or inspected.

Writes a detailed, executable implementation plan from an approved design or multi-step requirement, including exact files, interfaces, tests, commands, checkpoints, and rollback considerations. Use before touching code for a substantial feature, migration, refactor, or cross-cutting change. Not for a one-file bounded fix or for executing a plan that already exists.

Coordinates an active production incident by establishing command, reducing blast radius, preserving evidence, communicating verified impact, restoring service, validating recovery, and creating owned follow-up actions. Use for outages, severe degradation, security or data-integrity events, failed releases, and urgent operational triage. Not for a normal local bug, routine alert tuning, or a postmortem after the incident is already closed.

Designs or reviews logs, metrics, traces, alerts, correlation, dashboards, and diagnostic instrumentation so failures and performance changes can be detected and explained at component boundaries. Use for observability work, incident readiness, instrumentation, or production diagnostics. Not for fixing a specific incident before reproducing it or for adding noisy logging without an operational question.

Diagnoses and improves measured latency, throughput, memory, CPU, bundle, rendering, query, or resource performance by defining a target, profiling a representative workload, locating the bottleneck, making one change at a time, and comparing before/after evidence. Use for performance work or regressions. Not for guessing optimizations without a reproducible workload or for generic refactoring.

Executes an existing implementation plan task by task, preserving its interfaces and constraints, running focused checks after each slice, and stopping when the repository differs from the plan. Use when a written plan or approved checklist already exists. Not for inventing the plan, debugging an unexplained failure, or broad unscoped cleanup.

Reviews a GitHub pull request or focused branch diff for correctness, regressions, security, compatibility, test gaps, and maintainability. Use when an implementation needs an independent source-aware review before merge. Produces prioritized findings with evidence and actionable fixes. Not for architecture-only audits, formatting preferences, or processing existing review feedback.

Processes code review feedback by classifying each finding, reproducing or validating it against the real contract, applying the smallest in-scope fix, and re-running focused proof. Use after comments arrive on a diff, pull request, design, or implementation. Not for requesting a first review or debugging an unrelated failure.

Prepares and controls software releases with risk classification, CI quality gates, artifact provenance, feature flags, staged rollout, measurable promotion and rollback thresholds, post-deploy verification, and cleanup. Use for deployment pipelines, launch readiness, canaries, production rollout, release automation, or rollback planning. Not for merely merging a completed development branch or proving one local change.

Prepares a focused code review request for a branch, commit, pull request, or substantial working-tree diff by defining the review boundary, contract, risk areas, evidence, and questions for an independent reviewer. Use before merge or when another agent needs to review an implementation. Not for processing feedback already received or for claiming runtime correctness.

Investigates a bug, failing test, build error, regression, flaky behavior, performance symptom, or unexpected result by reproducing it, minimizing the case, testing ranked hypotheses, tracing the first incorrect state, and locking the root cause with a regression check. Use before proposing a fix. Not for planning a new feature or reviewing a healthy diff.

Designs and executes compatibility-preserving migrations across APIs, schemas, frameworks, dependencies, protocols, storage, and infrastructure with baselines, coexistence, staged cutover, rollback or forward-fix paths, and explicit removal criteria. Use for deprecations, upgrades, data moves, contract changes, and replacing live implementations. Not for a local refactor with no external state or compatibility boundary.

Threat-models and hardens an application, API, data flow, dependency, or deployment against authentication and authorization flaws, injection, secrets exposure, unsafe deserialization, SSRF, abuse, privacy loss, and supply-chain risk. Use for security review, threat modeling, hardening, or sensitive changes. Not for generic code style review or an unexplained bug without a security hypothesis.

Explores ambiguous product or engineering intent before implementation, clarifies users, constraints, alternatives, risks, and acceptance criteria, and turns the result into an approved design direction. Use for a new feature, subsystem, creative UI, architecture change, or unclear request. Not for an already-scoped bug fix, an existing implementation plan, or a narrow code review.

Executes an approved implementation plan through fresh implementer and reviewer agents for each task, with explicit handoffs, focused tests, and task-by-task integration. Use for multi-task work where independent agent context improves implementation and review quality. Not for a single small edit, an unresolved design, or a failure that still needs root-cause analysis.

Grounds version-sensitive engineering decisions in authoritative current sources by detecting the installed stack, retrieving official documentation or source, reconciling conflicts, and recording citations and confidence. Use for framework APIs, dependency behavior, standards, compatibility, migrations, or technical recommendations that may have changed. Not for stable project-local logic or broad product discovery.

Implements behavior changes with a test-first red-green-refactor loop: write one meaningful failing test, watch it fail for the intended reason, make the smallest change, then refactor while green. Use for new behavior, bug fixes, refactors with preserved contracts, and regression tests. Not required for disposable prototypes, generated files, or documentation-only edits.

Plans risk-based test coverage for a feature, service, release, or system by mapping user and business risk to test levels, environments, data, failure paths, automation, exploratory checks, and release gates. Use when choosing what to test or how much evidence is enough. Not for writing one test case, applying TDD to a single behavior, or debugging a failing test.

Audits an existing rendered interface or frontend diff for hierarchy, content clarity, interaction states, accessibility, responsive behavior, visual consistency, performance-sensitive UI patterns, and anti-generic design defects. Use for a UI/UX review, redesign audit, screenshot review, pre-release visual check, or design-system consistency pass. Not for building a new interface from scratch or for backend-only review.

Creates and manages isolated Git worktrees for parallel agents, risky experiments, or long-running feature work while preserving the user's current checkout. Use before concurrent branch edits or when isolation makes rollback safer. Not for a trivial one-file change that is already isolated.

Selects and composes the Godmode skills for a coding task, explains the activation boundary, keeps workflow skills from being skipped when they materially reduce risk, and identifies the task's current engineering lifecycle state. Use when starting a task with Godmode installed, deciding which skill to invoke, recovering a task after context loss, or checking whether a workflow applies. Not a replacement for the selected skill's instructions or for repository-local rules.

Creates or improves an Agent Skill by defining a precise trigger boundary, concise procedural instructions, progressive-disclosure references, deterministic helpers, routing evals, and validation evidence. Use when authoring or reviewing SKILL.md, skill metadata, bundled references, or skill packaging. Not for ordinary project documentation or application code.

В файле нет описания.