AI Marketplaces Leaderboard

Agent Skills

ChatGPT plugin

Engineering agent workflows

View in ChatGPT directory
Featured
No

not on the featured shelf

Movement

From our daily snapshots over the last 30 days.

Rank by placement

#4894of 6,02261places down24h—7d
#4,742#5,016#5,290#5,564Sep 13Sep 19Sep 25Oct 1Oct 7Oct 12

Rank in Developer tools

#357of 53723places down24h—7d
#318#368#418#468Sep 13Sep 19Sep 25Oct 1Oct 7Oct 12

In its category

How this plugin compares with others in the same category. Positions are counted within the category, not across the whole directory.

Developer tools357th of 537 by placement
#PluginPosition7d
354Matt Pocock Skills#4879—
355SQL Expert#4883—
356Fallow Code Analysis#4893—
357Agent SkillsThis page#4894—
358Code Assistant#4899—
359stark AI Developer#4904—
360Proxyman#4908—

All 537 Developer tools plugins

Provides reusable engineering workflows for planning, coding, reviewing, testing, and shipping software with coding agents.

Example prompts

  • “Plan this engineering task using Agent Skills”
  • “Review this implementation using the relevant Agent Skills”
  • “Choose the right Agent Skill for this coding task”

Skills

  • api-and-interface-design

    Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

  • browser-testing-with-devtools

    Use when a browser-based application needs real runtime inspection, DOM verification, console or network debugging, performance profiling, screenshots, or end-to-end browser testing.

  • ci-cd-and-automation

    Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.

  • code-review-and-quality

    Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

  • code-simplification

    Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.

  • constraint-driven-development

    Use when a project needs an explicit quality bar, enforceable standards, coverage or performance thresholds, or safeguards against agents weakening checks to get green.

  • context-engineering

    Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.

  • debugging-and-error-recovery

    Use when tests fail, builds break, something that worked yesterday broke, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need to figure out what broke and why — a systematic approach to finding and fixing the root cause rather than guessing.

  • deprecation-and-migration

    Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when migrating a database schema in production, such as renaming or dropping a column without downtime (expand/contract). Use when deciding whether to maintain or sunset existing code.

  • documentation-and-adrs

    Use when you need to document an architecture decision (ADR) or the reasoning behind a design choice, when changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.

  • doubt-driven-development

    Use when a plan or implementation needs adversarial scrutiny because assumptions are uncertain, stakes are high, or correctness matters more than speed.

  • frontend-ui-engineering

    Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated.

Show all 25
  • git-workflow-and-versioning

    Use when making any code change. Use when committing, branching, resolving conflicts, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog.

  • idea-refine

    Use when an idea is vague, alternatives need expanding, assumptions need stress-testing, or the user wants to refine an idea before committing to a plan.

  • incremental-implementation

    Use when implementing any feature or change that touches more than one file, or when picking up the next task from a plan. Use when rolling a change out behind a feature flag, when you're about to write a large amount of code at once, or when a task feels too big to land in one step.

  • interview-me

    Use when a request is underspecified, important requirements are ambiguous, or the user asks to be interviewed or grilled before planning or implementation.

  • observability-and-instrumentation

    Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.

  • performance-optimization

    Use when an application has performance requirements, regressions, slow pages or queries, poor Core Web Vitals, N+1 patterns, or measured bottlenecks that need optimization.

  • planning-and-task-breakdown

    Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.

  • security-and-hardening

    Use when code handles untrusted input, authentication, sessions, sensitive data, external integrations, dependency vulnerabilities, or needs a security review against common attack classes.

  • shipping-and-launch

    Use when preparing to deploy to production, or when asking what needs to be in place before shipping. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.

  • source-driven-development

    Use when you want to verify an approach against the official docs before implementing it, or when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.

  • spec-driven-development

    Use when starting a new project, feature, or significant change and no specification exists yet. Use when drafting a PRD or requirements document with objectives and scope, or when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.

  • test-driven-development

    Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.

  • using-agent-skills

    Use when starting a session, or when you need to decide which skill or workflow applies to the piece of work at hand. This is the meta-skill that governs how all other skills are discovered and invoked.

Categories
Made by
RONALD FERRARI SOARES
Sign-in
On Install
Capabilities
Planning, Implementation guidance, Testing and review
Availability
Available
Version
0.6.10
Keywords
software-engineering, planning, testing, review, shipping
Created
September 20, 2026