ozerohax
76 verified skills2,356 total stars
templates/skills/coder/frontend/design
--- name: coder-frontend-design description: Frontend design system practices: tokens, typography, color, layout, and component consistency. --- <when_to_use> <trigger>Creating or updating a design system for web UI</trigger> <trigger>Defining visual foundations before implementation</trigger> <trigger>Aligning design decisions between design and engineering</trigger> <trigger>Reviewing UI consistency and scalability risks</trigger> </when_to_use> <input_requirements> <required>Produ
development31
coder-system-design-external-api
Reliable and secure external API integration patterns for production-grade services.
development31
coder-system-design-testable-code
Testability-first design rules for modular, deterministic, and verifiable systems.
development31
docs-diagram-gen
Mermaid diagram generation for architecture, flows, and scenarios
documentation31
docs-project-research-summary
Documentation of research results and their impact on project decisions
testing31
docs-project-use-case
Use-case documents with traceability to PRD
documentation31
templates/skills/planning/approach-selection
--- name: planning-approach-selection description: Implementation approach selection: compare options and justify the decision --- <purpose> <item>Compare 1-3 realistic approaches and pick the best by explicit criteria</item> </purpose> <inputs> <required>Goal/requirements + constraints</required> <optional>Risks and process constraints (releases, windows, SLA)</optional> </inputs> <method> <step>Define 3-6 selection criteria (risk, speed, cost, maintainability, compatibility)</step>
development31
planning-base
Apply shared planning baseline (format, verifiability, assumptions) before creating any concrete change plan
development31
planning-impact-analysis
Identify affected systems, contracts, and data plus regression hotspots; not file-level edit inventory
data-ai31
templates/skills/planning/monitoring-checks
--- name: planning-monitoring-checks description: Observability: metrics, alerts, dashboards, post-change observation windows --- <purpose> <item>Define the signals that tell whether "everything is OK" or "we must stop/roll back"</item> </purpose> <inputs> <required>Change goal + critical user scenarios</required> <optional>SLA/SLO, existing metrics/alerts</optional> <optional>Risks (especially high-impact)</optional> </inputs> <method> <step>Define 3-7 key signals: errors, latency,
development31
templates/skills/planning/requirements-extraction
--- name: planning-requirements-extraction description: Extract requirements from a request: behavior, AC, constraints; for bugs - repro --- <purpose> <item>Convert the original request into verifiable requirements and acceptance signals</item> </purpose> <inputs> <required>Task description</required> <optional>For a bug: repro steps, environment, logs/stacktrace</optional> <optional>For a feature: user goal, constraints, desired UX</optional> </inputs> <method> <step>State the goal
development31
templates/skills/planning/rollout-strategy
--- name: planning-rollout-strategy description: Rollout strategy: stages, audiences, enablement mechanics, stop points --- <purpose> <item>Reduce rollout degradation risk and keep enablement controllable</item> </purpose> <inputs> <required>Change description + risks/criticality</required> <optional>Available mechanisms (feature flags, canary, blue-green)</optional> <optional>Release/window constraints</optional> </inputs> <method> <step>Select a rollout mechanism (flag/canary/blue
data-ai31
project-discovery-mode-selector
Choose fast or standard planning mode based on complexity, risk, and unknowns before any project artifacts
tools31
project-fast-proto-spec
Create a compact fast-flow spec for one iteration (AC, architecture skeleton, and verification gate) before decomposition
tools31
project-fast-pulse-scan
Run a timeboxed research scan after fast-init to confirm critical constraints and escalation triggers
data-ai31
project-fast-task-blast
Decompose fast proto-spec into an ordered MVP task list with AC links, dependencies, and DoD
testing31
task-use-research-web-strategy
Use for external web research with primary sources and links; not for local repository analysis
development31
testing-mobile
Mobile testing (native/hybrid/web, gestures, offline, interruptions)
development31
shared-docs-paths
Project documentation map. Must be loaded before any work
documentation31
coder-rules-clean-code
Clean code execution rules for coding agents with verifiable quality gates.
development31
coder-rules-debug-requirements
Debugging requirements protocol from reproducible issue to verified fix and regression protection.
development31
coder-rules-requirements
Requirement quality rules for coding tasks with traceable MUST/SHOULD and verifiable acceptance criteria.
development31
coder-system-design-db-schema
Database schema design and migration safety rules for production systems.
development31
coder-system-design-perf-patterns
System-level performance pattern selection with measurable tradeoffs and SLO alignment.
development31
coder-system-design-security
Security-by-design baseline for architecture decisions, controls, and verification.
development31
docs-dev-plan
Development plan document for implementation changes
development31
docs-project-brief
Initial project brief and MVP boundaries
documentation31
docs-project-status
status.json as the single tracker of project stage and readiness
documentation31
docs-project-task
Implementation task description ready for delivery and validation
documentation31
docs-report-bug-reporting
Bug report with reproducibility and impact assessment
testing31
docs-report-test-reporting
Test report with functional and regression verification results
testing31
planning-change-inventory
Enumerate concrete files/components and intended edits tied to AC; not broad cross-system impact analysis
research31
planning-scope-definition
Define task boundaries (in/out), assumptions, and non-goals
development31
templates/skills/planning/migration-strategy
--- name: planning-migration-strategy description: Migration strategy for data/schemas/contracts: compatibility, phases, verification --- <purpose> <item>Design a migration that preserves data integrity and compatibility</item> </purpose> <inputs> <required>What we migrate (schema/data/API) and why</required> <optional>Data volume, time windows, downtime constraints</optional> <optional>Backward-compatibility requirements</optional> </inputs> <common_patterns> <pattern>expand/contra
development31
templates/skills/planning/risk-assessment
--- name: planning-risk-assessment description: Risk assessment: likelihood/impact, mitigations, residual risk --- <purpose> <item>Identify risks, assess them, and define concrete mitigations</item> </purpose> <inputs> <required>Change description + impact areas (if available)</required> <optional>Critical business processes and SLA</optional> <optional>Release/window/process constraints</optional> </inputs> <risk_categories> <item>data</item> <item>security</item> <item>perform
development31
templates/skills/planning/rollback-mechanism
--- name: planning-rollback-mechanism description: Rollback mechanics and scenario: criteria, steps, data impact, recovery --- <purpose> <item>Create a fast and safe path to revert in case of degradation</item> </purpose> <inputs> <required>Change description + rollout strategy</required> <optional>Data/compatibility constraints (especially for migrations)</optional> <optional>Available mechanisms: revert, feature flag, blue-green</optional> </inputs> <method> <step>Define rollback
testing31
templates/skills/planning/testing-strategy
--- name: planning-testing-strategy description: Testing strategy: what to verify, test types, data needs --- <purpose> <item>Define a sufficient verification set tied to AC and risks</item> </purpose> <inputs> <required>AC/Goal + change list</required> <optional>Critical scenarios, edge cases, risks</optional> <optional>Available environments and test data</optional> </inputs> <method> <step>Map each key AC/risk to a check (unit/integration/e2e/manual)</step> <step>Define a regre
development31
project-fast-stack-pick
Fast, evidence-based technology stack selection for one-iteration planning
tools31
project-standart-decomposition
Break standard-flow epics into implementation-ready tasks with AC, DoD, sequencing, and critical-path visibility
testing31
review-arch-consistency
Review of architectural consistency of changes against principles and the current system landscape
testing31
review-code-checklist
Short quality gate for code review before merge
development31
review-code-idiom-check
Idiomatic code review for the project's language and framework
development31
templates/skills/review/code/maintain
--- name: review-code-maintain description: Maintainability and readability review: structure, clarity, and changeability --- <when_to_use> <trigger>Need to assess how easy the code is to maintain and evolve</trigger> <trigger>The PR has a lot of new logic or refactoring without functional changes</trigger> </when_to_use> <input_requirements> <required>PR/diff and a short change objective</required> <optional>Project naming rules and style guide</optional> <optional>List of known pai
development31
review-code-performance
Performance review for changes in critical paths and resource-intensive operations
development31
shared-base-rules
Mandatory baseline rules for any agent. Must be loaded before any work
data-ai31
task-use-research-code-strategy
Use for read-only codebase investigation with file/symbol evidence; not for implementation planning or code edits
development31
task-use-research-context-strategy
Use for domain rules and business-flow research with source evidence; not for low-level code tracing
development31
testing-api-manual
Manually verify API behavior with reproducible requests and response checks; not contract version compatibility governance
development31
testing-aqa
Design and maintain automated UI/API tests (framework patterns, stability, CI artifacts); not one-off manual checks
development31
testing-contract
Verify provider-consumer API contract compatibility and versioning; not ad-hoc endpoint behavior checks
development31
testing-load
Load testing (k6/JMeter scenarios, benchmarks)
testing31
testing-test-case
Design detailed reproducible test cases (Given/When/Then, one check per case); not smoke/regression checklists
testing31
templates/skills/review/doc/quality
--- name: review-doc-quality description: Documentation quality checklist: accuracy, completeness, consistency, and freshness --- <when_to_use> <trigger>A short quality gate is needed before publishing a document</trigger> <trigger>An audit of existing documentation fitness is required</trigger> </when_to_use> <input_requirements> <required>Document text or diff</required> <required>Target audience and expected reading outcome</required> <optional>Relevant links to product/interfaces
testing31
coder-system-design-api-design
API design rules for stable, observable, backward-compatible HTTP APIs.
development31
docs-project-arch
Project architecture document and technical constraints
documentation31
testing-browser-manual
Manual browser UI verification via MCP snapshots with reproducible steps and observed behavior; not automation design
tools31
task-use-creator-decomposition-strategy
Use to draft decomposition for one feature/epic with dependencies and risks; final scope and priorities stay with main agent
testing31
testing-e2e-flow
End-to-end scenarios (user paths, integration chains)
testing31
docs-project-epic
Epic definitions as value slices with requirement traceability
documentation31
templates/skills/review/arch/full-check
--- name: review-arch-full-check description: Full architecture review: decisions, trade-offs, NFRs, risks, and rollback plan --- <when_to_use> <trigger>Major changes to architecture or public contracts</trigger> <trigger>High risk in reliability, security, or scalability</trigger> <trigger>Before launching an initiative with long-term consequences</trigger> </when_to_use> <input_requirements> <required>ADR or equivalent document with options and selected approach</required> <require
testing31
docs-guide
How-to, guide, and ops documents for users and developers
development31
templates/skills/planning/estimation
--- name: planning-estimation description: Time/effort estimation: method, range, assumptions, uncertainty --- <purpose> <item>Provide a transparent estimate tied to decomposition and risks</item> </purpose> <inputs> <required>Change inventory or work decomposition</required> <optional>Blockers/dependencies/quality/process constraints</optional> </inputs> <method> <step>Estimate by phases (analysis/implementation/tests/rollout) or by components</step> <step>Pick an estimation method
testing31
templates/skills/coder/frontend/ui-ux
--- name: coder-frontend-ui-ux description: Frontend UI/UX practices: flows, interaction states, accessibility-first UX, forms, and perceived performance. --- <when_to_use> <trigger>Designing or refining user flows and screen behavior</trigger> <trigger>Improving usability, accessibility, and interaction quality</trigger> <trigger>Defining loading/error/empty states for key journeys</trigger> <trigger>Reviewing UX regressions in feature delivery</trigger> </when_to_use> <input_requirem
development31
project-standart-usecases
Designing use cases and user flows with PRD traceability
content-media31
testing-visual-regression
Visual regression (baseline diffs, UI stabilization)
testing31
project-fast-init
Quick project planning kickoff in one iteration (scope, goal, artifacts)
development31
project-standart-personas
Creating and validating project personas for requirement prioritization
tools31
docs-project-prd
Product Requirements Document with FR/NFR and testable acceptance criteria
testing31
project-standart-prd
Produce full standard-flow PRD with FR/NFR and testable AC after brief/research and before architecture
testing31
project-standart-research
Run targeted evidence-based research in standard flow to close critical unknowns before architecture decisions
testing31
templates/skills/planning/scope-minimization
--- name: planning-scope-minimization description: Minimize changes for bugs/incidents: the smallest safe fix --- <purpose> <item>Narrow the plan to the minimal change that fixes the bug and reduces regression risk</item> </purpose> <inputs> <required>Bug description + observed vs expected</required> <optional>Repro steps, environment, logs/stacktrace</optional> <optional>Criticality (SLA, incident) and deadline</optional> </inputs> <method> <step>Define the minimal "fixed" criterio
testing31
templates/skills/review/code/strategy
--- name: review-code-strategy description: Code review strategy: PR review flow, risk prioritization, and merge blocking rules --- <when_to_use> <trigger>Need to review a pull request before merge</trigger> <trigger>There is disagreement on comment strictness and blocking criteria</trigger> <trigger>Need to align a unified review process across the team</trigger> </when_to_use> <input_requirements> <required>PR link or diff</required> <required>Task context and expected behavior</re
development31
testing-a11y
Accessibility testing (WCAG, keyboard, screen reader)
testing31
docs-changelog
Changelog document for tasks and releases
documentation31
docs-project-personals
User personas and scenarios for requirement prioritization
documentation31
planning-task-classifier
Classify a task (bug/feature/refactor/migration) and what the plan must emphasize
development31