ratemyserver

name

ratemyserver

description

Use this skill to rate, audit, stress-test, red-team, or issue a ship/no-ship verdict on a concrete API, worker, realtime service, data pipeline, backend repository, or server deployment. Use for server-side authorization and tenant isolation; HTTP/RPC/job contracts; transactions, idempotency, concurrency, queues, caches, timeouts, retries, backpressure, graceful shutdown, migrations, observability, deployment, rollback, backup, restore, and real-money reliability. Trigger for rate my server/backend/API, can this service survive production, backend 上线前挑刺, 这个后端扛得住吗, API 能收真钱吗, or equivalent product-level server review intent, even before an artifact is attached. Resolve an actual service artifact or runtime evidence before settings or audit. Do not use for isolated snippets, routine debugging or fixes, frontend review, generic architecture advice, cloud product shopping, interview prep, or fundamentals teaching unless judging the built service itself.

RateMyServer

Judge whether a real service can preserve its promises under traffic, retries, concurrency, dependency failure, restart, and operator intervention. Review observable behavior and server-enforced invariants, not framework reputation or textbook completeness.

Read references/review-contract.md for every review. It is the single source of truth for evidence, findings, gates, decisions, the opening issue list, and re-review identity.

Stable server invariants

Invariant	Required behavior
Authority	Authenticate the caller and enforce role, ownership, and tenant policy on the server for every reachable operation.
Effect identity	Give each consequential operation a stable identity so retry, redelivery, replay, or resume cannot silently duplicate it.
State integrity	Keep authoritative state and externally visible effects consistent across concurrency, partial failure, and restart.
Bounded work	Bound admission, queues, fan-out, retries, memory, connections, execution time, and cancellation.
Truthful completion	Report success only after the promised durable state or effect is established, or expose an honest pending state.
Recoverability	Preserve enough durable state, checkpoints, backups, and procedures to resume or restore without inventing progress.
Operability	Make saturation, failure, retry storms, data drift, and recovery visible and attributable to an immutable release.

Resolve the two review settings

Server type	Route
API or request/response service	api; read references/service-types.md → API
Worker, consumer, scheduler, or job processor	worker; read references/service-types.md → Worker
Realtime, streaming, WebSocket, or event service	realtime; read references/service-types.md → Realtime
Data pipeline, ETL, ingestion, or batch system	data-pipeline; read references/service-types.md → Data pipeline
Full backend or several coupled server components	full-backend; read every applicable section of references/service-types.md

Review degree	Decision target
Quick check — highest-yield local check	local-smoke
Strict review — team or staging use	team-staging
Launch gate — public production	public-production
Real stakes — money, private data, or privileged effects	real-money
Life-or-death — critical or regulated service	critical-service

ReviewSettings = {
  server_type: api | worker | realtime | data-pipeline | full-backend,
  degree: quick-check | strict-review | launch-gate | real-stakes | life-or-death
}

Treat both fields as required; never infer a missing type or degree. First perform only the artifact gate below. After it passes, extract settings from the request or a cited prior report. Ask only for missing fields, in the user's language, with server type first and degree second. When both are missing, ask both in one message. Wait before inspecting contents, executing, inventorying evidence, or scoring.

Workflow

0. Resolve the artifact gate

Perform only the minimum read-only target-presence check. Resolve a user-supplied path, repository, deployment, API specification, trace set, metrics export, prior report, or the names and basic metadata in the current workspace. Do not inspect contents or run anything yet.

The gate passes only when one coherent service is identifiable from at least one actual artifact or concrete runtime-evidence surface. A repository, deployment, logs, metrics, schema, and runbook may be linked surfaces of one service.

• If none exists, say no auditable server artifact was found; ask for a path, repository, deployment, API specification, trace/metrics export, or attachment; stop before settings or verdict.
• If several independent services are plausible, name them, ask which one to review, and stop.
• If a named target is missing or inaccessible, state the exact gap and ask for an accessible reference; stop.

Passing this gate proves only that a target exists. An existing service that cannot run continues later as a limited static review.

1. Establish the contract and evidence inventory

After settings resolve, read references/service-types.md, references/operations-and-failure.md, and the shared review contract. Identify the entrypoints, callers, trust boundaries, authoritative stores, effects, dependencies, deployment topology, concurrency model, and one to three critical journeys. State what “accepted,” “complete,” “cancelled,” and “recovered” mean.

Name the exact source/build/deployment as an immutable release_ref. Inventory the five evidence lanes from references/review-contract.md; never let a green lane substitute for another.

2. Inspect behavior before internals

When safely runnable, use disposable local or staging state and synthetic identities/effects:

1. Complete one golden request, job, stream, or batch.
2. Submit an invalid or unauthorized operation and cross one applicable ownership or tenant boundary.
3. Repeat and concurrently burst one consequential operation with the same logical identity; inspect durable state and external effects.
4. Inject one timeout at the commit boundary, then retry; distinguish “not attempted,” “committed,” and “unknown.”
5. Fail one dependency and observe backoff, queue growth, partial state, and recovery.
6. Restart or request graceful shutdown while work is in flight; verify resume, drain, or explicit abandonment.
7. For recovery-dependent targets, restore or replay into an isolated destination and verify business invariants rather than trusting “backup succeeded.”

Inspect executable paths before running them. Never load-test, fault-inject, delete, charge, message, deploy, or restart production without explicit authorization and a safe limit. A clean burst is not proof of safety: locate the durable constraint, idempotency record, transaction, lease, sequence rule, or compensating reconciliation.

3. Trace implementation and operations

Trace observed failures and high-impact hypotheses through reachable handlers, authorization, storage, transactions, queues, caches, retry/timeout policy, lifecycle hooks, migrations, deployment configuration, telemetry, alerts, runbooks, and restore procedures. Search for compensating controls before confirming a finding.

Do not demand queues, caches, microservices, distributed locks, Kubernetes, or event sourcing unless the product contract and reachable failure require them. Prefer “this accepted operation can execute twice after this timeout” to “the author does not understand idempotency.”

4. Deliver the verdict

Render the canonical verdict from references/review-contract.md. Begin with the complete, uncapped, severity-sorted one-line issue list in the user's language. Each line states what fails and why it matters. Follow it with pending verification, the five evidence lanes, requested target, maximum safe target, decision, detailed findings and unknowns, no more than three priority actions, and a retest plan.

When no issue is confirmed, state what was exercised and what remains unknown. Do not manufacture criticism.

5. Score only on request

Only when the user explicitly requests a number, grade, comparison, or score delta, read references/numeric-scoring.md, create its scorecard, and run:

python3 <skill-directory>/scripts/score_review.py path/to/scorecard.json

Resolve the script relative to this SKILL.md. If execution or JSON creation is forbidden, give qualitative dimension grades and say no numeric score was computed. Never estimate a substitute number.

6. Choose the next action

After the complete verdict, follow any already requested next action. Otherwise offer report-only, fix-prompts, or fix-and-retest; do not make this a third upfront setting. Begin read-only. Edit code or durable external state only with explicit bounded authorization.

For fixes, preserve finding IDs and the prior release identity, change one authorized root-cause batch, compute a new identity, then use a fresh context or independent reviewer to repeat the original reproduction and adjacent checks. A plausible diff is not proof. Do not compare scores across changed server type, degree, target, dimensions, weights, or rubric fingerprint.

Resource index

• references/review-contract.md — always-load evidence levels, lanes, findings, gates, decisions, and re-review rules.
• references/service-types.md — type-specific contracts and failure probes for APIs, workers, realtime systems, pipelines, and full backends.
• references/operations-and-failure.md — traffic, timeout, retry, overload, shutdown, migration, rollback, backup, restore, and observability evidence.
• references/numeric-scoring.md — on-demand weights, scorecard interface, evidence caps, and deterministic scorer rules.
• scripts/score_review.py — on-demand, dependency-free scorecard validator and decision calculator.