swe-all

Plugin swe-all from marketplace skills-map in shreyansh-jain/agent-maxxing. Commands read from the repo's manifest — 1 month ago.

Skills (53)

• assessing-complexity

  Principal-engineer triage that scores a piece of work on risk dimensions and picks the process track and skills it needs. Use when starting any non-trivial task, feature, project or product, when asked how big or risky something is, or when unsure how much design, review and rollout rigor a change d

• auditing-security

  Evidence-based security audit of code, a diff, or a system surface, reporting only findings with a concrete attack path. Use when asked for a security review or audit, before a release or pentest, when code touches auth, payments, uploads, webhooks, secrets, CI pipelines or agent tools, or when a sc

• authoring-skills

  Test-first authoring and security vetting of Agent Skills (SKILL.md). Use when creating a new skill, editing or tightening an existing one, a skill fails to trigger or triggers on the wrong requests, agents ignore a skill's instructions, or a third-party skill is about to be installed or copied.

• building-accessible-interfaces

  WCAG 2.2 AA accessibility for web UIs, from semantic markup to keyboard, focus, forms and screen readers. Use when building or reviewing UI components, pages or forms, fixing an axe or Lighthouse accessibility report, or when keyboard or screen reader users report problems.

• building-llm-features

  Engineering discipline for product features that call an LLM: evals, prompts, structured output, tools, injection defense, cost. Use when adding or changing an LLM-powered feature, chatbot, agent, RAG pipeline, summarizer or classifier, or when one gives bad or unsafe output.

• clarifying-intent

  Intent-discovery interview before building anything new or changing behavior. Use when a request names a thing to build but not who it is for, why, or what done means, when the user asks to be grilled or to stress-test an idea, or before any feature, component, or behavior change whose purpose and s

• controlling-cloud-costs

  Measure-first cloud cost reduction and cost-aware design. Use when a cloud bill jumps or is too high, when asked to cut spend, find waste or idle resources, set budgets and anomaly alerts, compute unit cost per request or tenant, or weigh the cost of a design.

• debugging-systematically

  Root-cause debugging discipline for bugs, failures and regressions. Use when a test fails, something throws or crashes, output is wrong, behavior changed after a deploy or upgrade, a performance regression appears, or a previous fix did not hold.

• designing-data-models

  Access-pattern-driven schema design covering keys, types, constraints, indexes, tenancy and store choice. Use when designing or reviewing tables or collections, choosing relational vs document vs key-value, or when integrity or tenancy keeps breaking.

• designing-interfaces

  Interface and module design for APIs, public functions, module boundaries and service contracts. Use when designing a new API or endpoint, choosing what a module exposes, deciding where a seam belongs, changing a contract other code depends on, or when code is hard to test or call.

• designing-resilient-systems

  Failure-mode design for distributed calls: timeouts, retries, idempotency, breakers, bulkheads, backpressure. Use when a path calls networks, queues or third parties, or after cascading failures, retry storms, duplicate processing or lost messages.

• designing-system-architecture

  System-level architecture design for new products, services and major re-platforms, driven by quality attributes and explicit trade-offs. Use when choosing how components, services, data stores and integrations fit together, or when splitting, merging or re-platforming a system.

• dispatching-subagents

  Delegation discipline for handing work to subagents, parallel agents, or background workers. Use when two or more independent tasks could run at once, a plan has tasks to farm out, a broad search would flood the main context, or a fresh-context reviewer is wanted for finished work.

• documenting-decisions

  Architecture decision records and keeping project docs in step with shipped code. Use when a hard-to-reverse technical choice is made or revisited, when asked to write or supersede an ADR, when a change adds or alters public surface (API, CLI flag, config, env var), or when asked to update or audit

• engineering-products-end-to-end

  Principal-engineer playbook that takes a product or platform from problem to operated system through gated phases. Use when building a new product, platform or multi-quarter initiative, when work is assessed as C4, or when asked to lead, architect or plan a product end to end.

• estimating-capacity

  Back-of-envelope estimation of traffic, storage, bandwidth, concurrency, latency and cost. Use when sizing a new system or feature, checking a design against peak or 10x load, setting latency budgets, or asking how many servers or how much storage.

• fixing-ci-failures

  Triage and repair of failing CI checks and pipelines. Use when a pull request has red checks, a GitHub Actions / GitLab CI / CircleCI / Buildkite job fails, main went red after a merge, a build passes locally but fails in CI, or a pipeline config needs fixing.

• grounding-in-official-docs

  Version-accurate use of frameworks, libraries, SDKs, CLIs and cloud APIs, checked against primary sources instead of memory. Use when writing or reviewing code that depends on a specific library version, when an API may have changed since training, when a flag or config key is uncertain, or when the

• handing-off-sessions

  Session handoff documents that let a fresh agent or a later session resume work without the original conversation. Use when context is running out, work must pause and resume later, a task moves to another agent or teammate, or the user asks to save progress, checkpoint, or write up where things sta

• handling-personal-data

  Engineering practice for collecting, storing, using and deleting personal data. Use when a feature touches PII, health, payment or location data, analytics or tracking, identifiers in logs, retention, deletion or export requests, or GDPR, CCPA or HIPAA concerns.

• implementing-incrementally

  Discipline for building features in thin, verified slices, executing a plan task by task, and keeping the codebase working between steps. Use when executing an implementation plan or tickets, when implementing a feature or change that touches more than one file, when about to write a large amount of

• instrumenting-observability

  Vendor-neutral logging, metrics, tracing, SLO and alerting practice built on OpenTelemetry. Use when adding logs, metrics or spans to a feature, shipping something that runs in production, defining SLOs or alerts, fixing noisy or missing alerts, or when a production problem cannot be explained from

• managing-feature-flags

  Feature flag lifecycle from creation through rollout to removal, including safe defaults, targeting and flag-debt cleanup. Use when adding a feature flag or kill switch, gating a release, doing a percentage rollout, or removing stale flags and dead code paths.

• managing-technical-debt

  Finding, recording, prioritizing and paying down technical debt so it is visible to product decisions. Use when code slows the team down, when asked what to refactor first or for a debt backlog, when justifying cleanup, or when deciding whether to take a shortcut.

• measuring-product-outcomes

  Defining success metrics, product analytics events and A/B experiments so a feature's impact can be proven. Use when adding analytics or tracking events, choosing a success metric or KPI, designing or reading an A/B test, or asked whether a shipped feature worked.

• migrating-databases-safely

  Zero-downtime schema and data migration discipline for production databases. Use when adding, renaming, dropping or retyping a column or table, adding an index or constraint, backfilling rows, or writing any migration that will run against a live database with traffic.

• modeling-domains

  Domain modeling with a shared glossary, bounded contexts, aggregates and invariants. Use when business terms are ambiguous, entities and rules are being defined for a new domain, a model is anemic or tangled, or domain boundaries are unclear.

• modeling-threats

  Design-time threat modeling of a system, feature or architecture change. Use when designing anything handling auth, money, personal or multi-tenant data, uploads, webhooks or LLM agents with tools, or when asked how an attacker could abuse it or for STRIDE.

• onboarding-to-codebases

  Structured orientation in an unfamiliar repository, service or subsystem, ending in an evidence-backed map. Use when starting work in a codebase for the first time, when asked how a feature or flow works end to end, before planning a change in code nobody on hand understands, or when the user asks f

• optimizing-performance

  Measure-first performance work across backend services, databases and frontends. Use when an endpoint, query, job, page or build is slow, latency or memory regressed, Core Web Vitals or a performance budget is failing, costs rise with load, or someone wants to optimize code before measuring it.

• planning-implementation

  Implementation plan built from an approved spec or clear requirements, as ordered vertical-slice tasks with exact files, interfaces, tests, and verification commands. Use when a spec or ticket is approved and work is about to start, when a task feels too big to begin, when work must be split into ti

• planning-test-strategy

  Risk-based test strategy for a feature, service or system. Use when deciding what to test and at which level, planning tests for a new feature or rewrite, auditing a slow or untrustworthy suite, or setting coverage, flake and CI-gate policy.

• receiving-code-review

  Discipline for acting on code review feedback from people, bots or other agents. Use when review comments arrive on a PR, a reviewer subagent returns findings, a user relays feedback to address, or a suggestion looks wrong, unclear or out of scope.

• refactoring-legacy-code

  Safe change of untested or poorly understood code using characterization tests, seams and small reversible steps. Use when code must change but has little or no test coverage, when behavior is known only by what it does today, when a large module or rewrite is being considered, or when the user call

• resolving-merge-conflicts

  Resolving git merge, rebase, and cherry-pick conflicts by reconstructing what each side intended. Use when git reports CONFLICT, a rebase or merge stops partway, conflict markers appear in files, or a lockfile or generated file conflicts after pulling the base branch.

• responding-to-incidents

  Production incident response, mitigation-first, through to a blameless postmortem. Use when production is down, degraded, erroring or losing data right now, an alert or page has fired, a deploy just broke users, or when writing the postmortem or on-call handoff afterwards.

• reviewing-code

  Multi-axis review of a diff, branch or pull request for spec fit, correctness and repo standards, with confidence-filtered findings. Use when asked to review a PR, branch, commit range or pasted diff, before merging or landing a change, after an agent or teammate finishes a task, or when asked to fi

• reviewing-plans

  Engineering review of a plan, spec, or design before implementation starts, covering scope, architecture, failure modes, tests, and performance. Use when the user asks to review, critique, sanity-check or poke holes in a plan or design doc, before committing a team to an approach, or when a plan tou

• scoping-product-increments

  Scoping a product problem down to the smallest valuable increment worth building next. Use when an idea, roadmap item or feature request is too big or vague to start, when deciding an MVP, cutting scope to a deadline, or choosing what to build first.

• setting-up-ci-pipelines

  Design and hardening of CI pipelines for fast feedback, reproducibility and least privilege. Use when creating a new CI workflow, adding jobs or gates, speeding up slow CI, adding caching or matrices, or securing workflows (tokens, secrets, fork PRs, pinned actions).

• shipping-changes

  End-to-end discipline for taking finished work from a branch to merged and released, including pre-merge verification, integration choice, staged rollout and rollback. Use when implementation is done and the user wants to ship, land, merge, release or deploy a branch, open it for review, cut a relea

• simplifying-code

  Behavior-preserving cleanup of working code for readability, duplication and needless complexity. Use when code works but is hard to read, after a feature lands and the diff feels heavy, when the user asks to clean up, tidy, simplify or de-duplicate, or when a review flags nesting, long functions, d

• test-driven-development

  Test-first development discipline (red, green, refactor) for features, bug fixes and behavior changes. Use when implementing new behavior, fixing a reported bug, changing existing behavior, or when the user mentions TDD, test-first, or red-green-refactor.

• testing-end-to-end

  Reliable browser and API end-to-end tests for critical user journeys. Use when writing or fixing Playwright, Cypress or similar E2E tests, adding a journey test for a feature, or when E2E tests are slow, brittle, or break on unrelated UI changes.

• triaging-flaky-tests

  Diagnosis discipline for non-deterministic tests. Use when a test passes and fails without code changes, fails only on CI or only in the full suite, fails depending on run order, time of day, timezone or machine load, or someone proposes adding a retry or a sleep to make it pass.

• upgrading-dependencies

  Safe, incremental dependency and framework upgrade practice, from a single package to a monorepo-wide major bump. Use when bumping a library, framework, language runtime or toolchain version, handling Dependabot or Renovate PRs, fixing a deprecated or end-of-life dependency, resolving a vulnerable-d

• using-git-worktrees

  Isolated git worktree workspaces for parallel or risky work. Use when starting feature work that should not disturb the current checkout, running several agents or branches at once, before executing an implementation plan, or when asked to set up, list, or clean up worktrees.

• verifying-before-completion

  Evidence gate before any claim that work is done, fixed, passing, or ready. Use when about to report success, mark a task complete, say tests or builds pass, hand work back to the user, open a PR, or trust a subagent's report that something works.

• writing-agent-context-files

  Short, verified AGENTS.md and CLAUDE.md files that give coding agents a repo's non-obvious facts. Use when asked to create, update, audit, or trim AGENTS.md, CLAUDE.md, GEMINI.md, copilot-instructions.md, or Cursor rules, or when agents in a repo keep making the same avoidable mistake.

• writing-commits-and-prs

  Commit messages, commit splitting, and pull request titles and descriptions that follow the repository's own conventions. Use when asked to commit, draft a commit message, split a messy working tree into commits, open or update a PR, or rewrite a PR description after new commits.

• writing-design-docs

  Technical design documents and RFCs that decide how a system or change will be built. Use when asked for a design doc, RFC, tech spec or architecture proposal, or when a change spans services or teams, is hard to reverse, or needs alternatives weighed first.

• writing-infrastructure-as-code

  Safe authoring and change of infrastructure as code (Terraform/OpenTofu, Pulumi, CDK) and container images. Use when writing, refactoring or reviewing IaC modules, state, environments or Dockerfiles, or before any plan, apply, import or destroy.

• writing-specs

  Written specification for a feature, subsystem, or significant change, produced from an agreed intent and the current code. Use when the user asks for a spec, PRD, requirements or design doc, when an architectural change has confirmed intent but nothing written down, or when vague requirements need

Similar plugins