everyone-pack

Plugin everyone-pack from marketplace agent-ops-kit in Samaara-Das/agent-ops-kit. Commands read from the repo's manifest — 1 month ago.

Skills (27)

• a11y-pass

  Use before opening a PR on any UI change, or when asked whether a screen is accessible. Runs a WCAG-oriented pass on a specific screen or component and returns ranked, fixable findings rather than a generic lecture.

• abuse-review

  Use when reviewing any change that touches identity, authorization, money, personal data, or an externally reachable surface. Runs the abuse-path pass rather than a generic security lecture.

• bug-report

  Use when raising a defect, or when a reported bug can't be reproduced. Produces a report a developer can act on immediately, and stops the two-day round trip of "works on my machine".

• change-safety

  Use before applying any infrastructure, pipeline, config or environment change — terraform, kubernetes, CI config, DNS, IAM, scaling, secrets rotation. Forces blast radius and rollback to be stated before the apply, not after.

• component-conventions

  Use when creating a new React/Next component, page or screen, or when refactoring an existing one. Applies the team's design-system, state and data-fetching rules so you stop re-explaining them and stop reviewing them by hand.

• data-handling-check

  Use when a change touches customer data, logs, analytics, exports, third-party services, or AI/LLM calls. Checks what data goes where against the classification the organisation actually requires.

• dependency-and-secrets-scan

  Use before a release, when adding or upgrading a dependency, or when reviewing a diff for anything credential-shaped. A practical scan that produces action rather than a 400-line advisory dump.

• design-to-code

  Use when implementing from a Figma file, a mockup, a screenshot, or a design review comment. Translates a design into the team's components rather than pixel-pushing a one-off, and lists what the design didn't specify.

• endpoint-conventions

  Use when adding or changing an API endpoint, service method or route handler. Applies the team's error envelope, auth scoping, validation and idempotency rules so reviewers stop catching the same four things.

• metric-definition

  Use when defining a new metric or KPI, when two reports disagree on the same number, or when someone asks "why does this dashboard say something different". Pins down a definition precisely enough that two people compute the same value.

• migration-check

  Use when writing, reviewing or deploying a database migration, or when changing a schema, index or column. Catches the migrations that pass locally and lock a production table.

• money-path-check

  Use for any change that touches balances, ledgers, transfers, fees, limits, approvals or settlement. The strictest checklist in the set — apply it even when the change looks small.

• offline-and-sync

  Use when a mobile feature reads or writes data that must survive a bad connection — transfers, forms, drafts, queued actions, cached balances. Forces the failure modes that only appear on a real network.

• partner-integration

  Use when integrating a third-party or partner API — payment rails, card schemes, KYC vendors, core banking, any external service. Forces the questions that are cheap before the integration and expensive after go-live.

• pipeline-and-jobs-audit

  Use when a scheduled job, cron, CI stage or alert seems fine but you're not certain, when adding a new one, or during any incident where something "should have" caught the problem. Finds the jobs that have never run and the alerts that report failure as normal.

• pipeline-check

  Use when building, changing or debugging a data pipeline, ETL job, scheduled export or feed. Catches silent partial failures, which are the characteristic failure of this discipline.

• pr-review

  Use when reviewing a pull request, when asked to look over someone's changes, before approving a PR, or when opening your own PR and wanting a self-check first. Runs the team's review checklist so you stop holding it in your head.

• query-review

  Use when writing or reviewing a SQL query, report, dashboard metric or extract — especially one that will drive a decision or be shown to a customer or regulator. Catches the query that runs fine and answers the wrong question.

• reconciliation-check

  Use when building or debugging reconciliation between systems — ledger vs partner statement, internal balances vs core banking, settlement files. Also use when a break is reported and the cause is unclear.

• regression-triage

  Use when a test suite goes red, when a flaky test appears, or when deciding whether a failure blocks a release. Separates real regressions from pre-existing failures and environment noise.

• release-readiness

  Use before submitting a mobile build to a store, cutting a release branch, or handing a build to QA. Catches the things that are cheap now and expensive after review.

• release-runbook

  Use when preparing, executing or reviewing a release or deployment. Produces the runbook rather than relying on the one in someone's head, and makes the rollback concrete before it's needed.

• screen-conventions

  Use when building or changing a mobile screen, widget or navigation flow. Applies the team's layout, state and platform rules, and forces the states and device sizes that get skipped.

• session-handoff

  Use when a working session is ending, when you're switching tasks, at end of day, or when handing something to a colleague or a fresh AI session. Writes down state so nobody — including future you — has to reconstruct it from memory.

• test-plan

  Use when a ticket or build arrives for testing, when writing test cases, or when deciding what to regression-test around a change. Produces a risk-ordered plan instead of an exhaustive list nobody finishes.

• ticket-to-plan

  Use when picking up a Jira/Linear ticket, when a task description is vague, or before starting any work that isn't a one-line change. Turns a ticket into a concrete plan with acceptance criteria, and surfaces the questions worth asking before you write code rather than after.

• webhook-hardening

  Use when building or reviewing a webhook receiver, callback endpoint or async notification handler from any partner. These endpoints are externally reachable and are a standard source of incidents.

Similar plugins